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 defines provider-neutral choices and verification steps. Hypervisor product interfaces change frequently and are not reproduced here. 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 sufficient 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) :
# 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 or quiesce applications that maintain important write state and allow filesystem writes to complete.
Snapshots do not replace an independent backup because they commonly share the same storage system and administrative control plane as the guest. 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.