Synopsis #
OpenBSD can run as a guest under several third-party hypervisors. The installation procedure remains the standard OpenBSD procedure, but the hypervisor controls firmware, virtual disks, network adapters, consoles, power events, and snapshot behavior.
This guide covers virtual hardware selection and checks inside the guest. Use the hypervisor’s documentation for its setup interface. Confirm the current OpenBSD release and the selected virtual devices before relying on a guest for production work.
Record the Virtual Hardware #
Before creating the guest, record:
- the OpenBSD architecture;
- BIOS or UEFI firmware mode;
- virtual CPU count and memory;
- disk controller and disk size;
- network adapter model and network attachment;
- graphical, serial, or provider-console access;
- the recovery-media attachment procedure.
Prefer simple virtual devices documented by current OpenBSD section 4 manual pages. virtio(4) documents the paravirtual device framework used by many hypervisors. Availability and behavior depend on the host product and its configured device model.
Create the Guest #
Use conservative initial resources and one disk. Attach the verified OpenBSD installation ISO for the selected architecture. Do not enable optional acceleration, nested virtualization, unusual storage caching, or several network adapters until the basic guest boots and installs reliably.
Connect the first virtual network adapter to a network that provides either DHCP or recorded static settings. Maintain console access until SSH connectivity has been tested after a reboot.
Install OpenBSD #
Boot the installation media and follow the installation chapter . The installer should display the virtual disk and network adapter in its kernel messages. Stop and correct the virtual hardware configuration if the intended disk or network interface is absent.
Use the automatic disk layout unless the workload requires a documented alternative. Install all sets for a general-purpose guest. Eject or detach the installation media before the first disk boot.
Verify Devices in the Installed Guest #
After the first boot, record the virtual devices with dmesg(8) , disklabel(8) , and ifconfig(8) .
dmesg
# Confirm the firmware, storage, network, clock, and console devices
disklabel sd0
# Confirm the installed disk and OpenBSD partition layout
ifconfig
# Confirm the virtual network interface and address
Replace sd0 when the installed disk uses another name. Device names must be discovered from the guest’s own kernel messages.
Complete the first 30 minutes , then reboot again. Confirm that the guest starts from its virtual disk, obtains the expected network configuration, and remains accessible from the hypervisor console.
Configure Console and Shutdown Paths #
A graphical console is enough for installation, but a serial console can improve headless recovery when the hypervisor exposes one. Configure it only after confirming the architecture-specific boot(8) and ttys(5) requirements. Keep the known-working console until the serial path has been tested across a reboot.
Test a normal in-guest shutdown with shutdown(8) :
doas shutdown -p now
Confirm that the host recognizes the powered-off state. Do not treat an abrupt hypervisor power-off as a normal shutdown procedure.
Treat Snapshots as a Recovery Aid #
A hypervisor snapshot captures virtual-disk state at a point chosen by the host. It does not automatically guarantee filesystem or application consistency. Before a planned snapshot, stop applications that write important data, or pause their writes, and let pending filesystem writes finish.
Snapshots usually share the guest’s storage and administrator access, so a storage failure or compromised account can affect both. Keep an independent backup. Maintain a guest-aware backup and test restoration separately.
Before a base-system upgrade, confirm all three recovery paths:
- hypervisor console access;
- verified installation or ramdisk media;
- an independent backup of configuration and application data.
The virtualization chapter covers OpenBSD as a virtualization host. It is distinct from running OpenBSD as a guest under another hypervisor.