OpenBSD released version 8.0 on October 20, adding support for up to 64 virtual CPUs per guest in its native hypervisor. The release notes give operators a reason to reassess workloads that need several processors inside one virtual machine. We haven't benchmarked the new guest support.
OpenBSD includes the vmm hypervisor and vmd management daemon, with vmctl for controlling guests. The project's virtualization FAQ describes that arrangement. Together, these components let an OpenBSD host run other operating-system instances without installing a separate virtualization stack.
More CPUs require a configuration choice
The current vm.conf manual documents a cpus setting for each guest. The default is one virtual CPU, and the maximum is 64. An operator who leaves that setting out should therefore expect a single-CPU guest, even after upgrading the host.
That distinction matters when evaluating the release. A higher supported limit gives a guest room to run parallel work, but it doesn't tell you how much faster a particular application will finish. The vmm manual cautions that guests consume host resources and that their configurations must inform capacity planning. It also requires hardware-assisted virtualization and nested or extended paging on the host CPU.
The FAQ still describes the old limitation
When checked on October 20, the virtualization FAQ still listed guest SMP, or symmetric multiprocessing, among unavailable features. That conflicts with the version-specific release notes and the current configuration manual. For the CPU limit in 8.0, the latter two documents provide the more specific evidence.
This discrepancy is worth resolving before following older setup advice. The FAQ's example creates a guest with one vCPU, which remains consistent with the documented default. Its example doesn't demonstrate the new multiprocessor support.
Plan the host upgrade separately
OpenBSD's 7.9-to-8.0 upgrade guide supports upgrades only between consecutive releases. It calls for a /usr partition at least 1.1G in size and recommends testing critical or remote machines on an identical local system first. Those checks come before changing guest CPU allocations.
The next useful evidence will be workload results showing how multiprocessor guests behave under host contention. Until then, the documented default and limit give operators a concrete starting point: choose the guest's CPU allocation deliberately, then measure the work it actually runs.