Virtualizing OpenBSD

The OpenBSD developers are pretty clear on virtualization. OpenBSD is written for real hardware. Virtual hardware is not real hardware. While it can be very similar, it’s not exactly the same.

This approach has a number of implications, the most problematic of which is that not all virtualization software can run OpenBSD. As I write this, Oracle’s VirtualBox can’t cleanly run either i386 or amd64 OpenBSD. (Some people report being able to boot some versions of VirtualBox and/or OpenBSD, but OpenBSD software crashes all over the place.) This is not an OpenBSD bug. VirtualBox doesn’t sufficiently emulate real hardware.

That said, OpenBSD does run well on some virtual machines. VMware works well enough that OpenBSD includes specific drivers for VMware integration, including a VMware Tools driver in the kernel. KVM virtualization also works, although KVM requires some tweaks depending on the exact combination of KVM and OpenBSD you’re using. Microsoft’s virtualization mostly works, although Virtual PC has some commercially motivated limitations.

The main problem with virtualization is that a compromise of the virtualization platform automatically gives an intruder hardware-level access to all virtual machines, and OpenBSD cannot possibly secure you against that kind of attack. In fact, no operating system can. And it does you no good to run your database on OpenBSD when any script kiddie can compromise the underlying virtualization server.

In my experience, OpenBSD virtual machines are excellent for experimentation and reference. I used them to document the installation process for this book, and I always test software configurations on virtual machines before rolling them out to production. (The real benefit of virtualization might be that there’s no longer any excuse for not testing changes.) But when I want a server that’s actually secure, I put OpenBSD on real hardware.