Run Haiku in QEMU with NVMM on a Haiku x86

Haiku R1/beta6 introduced NVMM support for QEMU on x86_64 Haiku hosts. NVMM is NetBSD’s Virtual Machine Monitor, a host-side interface for hardware-assisted virtualization. In this workflow, Haiku is the host operating system running QEMU; the guest can be a Haiku x86 image. This is different from using QEMU on macOS, Linux, or Windows and selecting that host’s own accelerator. An option documented for Haiku’s QEMU build should not be assumed to work on another host.

The beta6 announcement describes the capability as experimental and notes x86_64 host requirements for hardware virtualization support. The release notes mention running 32-bit or 64-bit guests and SMP, but they do not turn NVMM into a universal compatibility guarantee. Results depend on CPU firmware settings, QEMU build, Haiku revision, guest image, and device model. Keep a software-emulation fallback and report failures with exact versions.

Confirm the host before installing a guest

Start with the host architecture: the documented NVMM path targets x86_64 Haiku. Confirm the processor exposes Intel VT-x or AMD-V and that firmware has not disabled the feature. Haiku’s release notes describe the support boundary; do not infer that every x86_64 machine exposes virtualization identically or that every guest architecture is hardware accelerated.

Install QEMU through a package source appropriate to the running Haiku release and check its version and available accelerator list. QEMU command-line syntax can change across releases. If -accel nvmm is rejected or not listed, do not download an arbitrary binary from an untrusted mirror; use the package/build documented for Haiku and report the mismatch.

Keep the guest image checksum and origin. The official Haiku release page provides images and release notes; record whether you are booting an anyboot ISO, disk image, or a custom installation. Do not attach a production disk to an experimental VM as a first test.

Start with a disposable guest

A minimal command shape is:

qemu-system-x86_64 \
  -machine pc \
  -accel nvmm \
  -m 2048 \
  -smp 2 \
  -cdrom /path/to/haiku-anyboot.iso \
  -boot order=d

The accelerator option is the key host-specific choice; memory, CPU count, machine type, and boot media should be adjusted to available resources and the QEMU/Haiku release. This command is an example, not a tested claim against every beta6 package. Verify the installed QEMU’s accepted option names with its own help/documentation and consult Haiku’s release notes for the supported host boundary. A disposable VM protects host data from guest installation mistakes.

After the guest reaches the desktop, install only to a new virtual disk or a disk image you can discard. Keep the ISO and guest disk separate. Do not expose shared folders or host devices until basic boot stability is established. A VM snapshot or a copy of the virtual disk makes experiments reversible, but it is not a substitute for an independent backup of important files.

Distinguish accelerator failure from guest failure

If QEMU fails before creating a window, inspect host-side QEMU diagnostics: missing NVMM support, disabled CPU virtualization, architecture mismatch, permission/module availability, or incompatible QEMU build. If QEMU starts but the guest fails to boot, compare a supported software-emulation run such as -accel tcg where available. TCG is slower but provides a useful diagnostic baseline. A guest-only failure under one accelerator may indicate an acceleration or device-model issue; it does not prove the guest image is corrupt.

Change one factor at a time. Keep the same guest image, virtual disk, memory, CPU count, and device model when comparing accelerators. Record the exact command, QEMU version, Haiku revision, CPU model, firmware virtualization setting, and failure stage. Avoid benchmarking a guest before confirming the clock, storage, and network device behavior are stable.

An accelerator controls CPU execution, not all virtual devices. Storage, graphics, networking, audio, and USB can each have separate emulation models and limitations. A guest that boots successfully may still have poor graphics performance or unsupported hardware integration. Report each device path separately rather than calling the entire VM “working” after the first desktop appears.

Keep host and guest updates separate in the test record. A new Haiku package can change QEMU while the guest disk stays constant; a new guest image can change the guest kernel while the host accelerator stays constant. Record hashes for installation media when comparing failures across machines. If an existing guest disk is valuable, copy it before a QEMU upgrade and test the copy first. Do not let two QEMU processes write the same virtual disk concurrently.

Use the QEMU monitor and command-line help only as documented for the installed build. Options such as machine type and device model affect compatibility independently of NVMM. Start with conservative defaults, then add one device at a time if the guest requires it. If a saved VM configuration works under TCG but not NVMM, preserve both command lines and the full startup logs; simplifying the device list can identify whether the difference is CPU execution or a device-model interaction.

Do not use an experimental guest to validate data durability for important files. A guest-visible successful write means QEMU and its virtual storage path reported completion; it is not an independent host backup. Keep important guest data outside the test disk until the accelerator and shutdown path have been exercised over repeated clean runs.

Resource sizing and SMP

The beta6 notes describe SMP support, but more virtual CPUs are not automatically faster. Start with a modest count and monitor host responsiveness. Oversubscribing host CPUs can increase latency for both Haiku host and guest. Memory assigned to the guest is reserved from the host’s perspective; leave sufficient memory for the desktop, QEMU, and package activity.

Change guest CPU count only after collecting a baseline. Test one vCPU, then a small SMP configuration, and compare boot, idle, and workload behavior. If instability appears only with multiple vCPUs, preserve the failing run and reduce the configuration for continued use while filing a bug. Do not describe SMP support as proof that every guest kernel or workload is free of concurrency issues.

Networking and host data boundaries

Start with QEMU’s default isolated/user-mode networking when the goal is basic guest connectivity, and consult the installed QEMU documentation for exact network options. Bridged or host network access may require additional configuration and changes the exposure of the guest. Do not forward administrative services to untrusted networks. A guest firewall and host firewall remain separate controls.

Shared folders, USB passthrough, and raw block devices expand the guest’s access to host data. Add them only when needed, and understand the host-side permissions and unmount requirements. Never pass a mounted host filesystem block device through to a guest as a writable disk. Use a dedicated virtual disk for guest storage.

Acceptance checks

The setup is accepted when QEMU identifies the NVMM accelerator, starts a disposable guest with the expected architecture, reaches the intended installer/desktop, survives a clean guest shutdown, and leaves the host responsive. Repeat the test after a host reboot to confirm no manual transient step was required. Verify guest storage is the intended virtual disk and that shared host paths are absent unless explicitly configured.

If NVMM fails, capture complete QEMU output and compare with TCG using the same disposable image. If TCG works and NVMM fails, report the host accelerator path; if both fail, inspect the guest media or virtual device configuration first. Preserve the guest image checksum and do not alter the only copy of a useful disk during experiments.

NVMM on Haiku is an important experimental capability, not a generic QEMU promise. Confirm that the host is Haiku x86_64 with hardware virtualization available, use a matching QEMU build, isolate the guest on disposable storage, and separate CPU acceleration from virtual-device compatibility. Those checks make early virtualization testing repeatable without overstating the maturity of the feature.

Related:

Sources:

Run Haiku in QEMU with NVMM on a Haiku x86_64 Host