OpenBSD 8.0 Supports Multiple vCPUs—Why Your VM Still Has One
After the host upgrade and a higher CPU count in its configuration, the running guest still sees a single processor. What does it take for the new count to reach the VM?
- OpenBSD 8.0 adds guest multiprocessing, with up to 64 vCPUs per VM.
- The default remains one; use
cpusinvm.conffor a persistent count. vmctl start -pcan override the next boot, while reload does not reconfigure running guests.
The old single-vCPU limit no longer describes OpenBSD 8.0
OpenBSD’s built-in hypervisor can now provide multiple virtual CPUs to one guest. The 8.0 release notes, published for the October 20 release, list multiprocessing support for up to 64 vCPUs per VM.
This is a per-guest change. Running several single-CPU VMs and assigning several CPUs to one VM are different configurations. If the latter was the missing capability in your setup, the release removes that particular restriction.
It does not automatically enlarge every guest. The versioned 8.0 configuration manual still specifies a default of one CPU. Seeing one inside a guest is therefore a reason to inspect its configuration, even on an updated host.
Use cpus for persistence, or -p for the next boot
To retain a count across starts, add or update the following line inside the appropriate vm block in /etc/vm.conf. It is a setting for an already configured guest, not a complete VM definition:
cpus 4For a temporary change, vmctl’s start -p option overrides an existing VM’s configured CPU count for its next boot. For a registered, stopped VM named demo, the command would be:
vmctl start -p 4 demo| Intent | Where to set it | Scope |
|---|---|---|
| Keep using four CPUs | cpus 4 in vm.conf | Saved VM configuration. |
| Try four on the next boot | vmctl start -p 4 demo | Overrides the count for that boot. |
| Leave the count unspecified | Default configuration | One virtual CPU. |
If the temporary choice becomes your intended configuration, record it in the file. Otherwise, a later start can return to the saved count.
A running guest must stop before its configuration is reloaded
Editing the file and issuing vmctl reload does not resize a running VM. The command explicitly leaves running guests’ configurations unchanged.
Finish the guest’s work and shut it down normally. Save the desired cpus value, run vmctl reload on the host, and start the guest again. Then verify the CPU count reported inside the guest. This is a stop-and-start configuration change, not live CPU addition.
Keep the two paths separate: a saved configuration needs to be read before it is used, whereas -p supplies a count for the upcoming start. That distinction makes a temporary experiment easier to distinguish from the setting you intend to operate.
The 64-vCPU ceiling is not extra physical capacity
The vmm manual notes that guests consume host resources and that capacity planning must account for both their number and configuration. Increasing one VM’s allocation does not remove the demands of the other guests.
The host also needs hardware-assisted virtualization and nested or extended paging support. A higher guest CPU limit does not replace those prerequisites.
The practical gain is a new allocation choice. After booting with the selected count, compare the workload’s completion time and host load before retaining it. Start by specifying the count the VM needs and verifying that it took effect, rather than treating the maximum as a target.