Yesterday, someone stumbled into the #kvm channel and mentioned that VirtualBox has gone OpenSource.

After some frantic questions and listening to the #vbox channel, it became apparent that there are some benefits and limitations of VirtualBox worth noting.

VirtualBox can use Intel/VT or AMD-V/SVM if available, but does not require it. Much like VMWare, which take the same hybrid software/hardware approach to virtualization. For 32bit guests, this can be much faster than pure VT/SVM.

VirtualBox (herein referred to as VBox) is similar to VMWare workstation or VMWare server, in that it has a ring0 kernel driver for a linux host.

This ring0 requirement means that it is not compatible with a Xen paravirtualized domU (and that includes dom0).

VBox leverages QEMU heavily for software emulation of real-mode and other critical code sections, as well as for hardware emulation.

QEMU has a closed source kernel module, kqemu, and a somewhat alpha quality opensource equivalent, qvm86, that do the software code-scanning method of virtualization. They do not require or recognize VT/SVM.

VBox's primary competitor is the kvm project, which provides QEMU based VT/SVM guests. The downside of kvm, of course, is the requirement for VT/SVM support from your CPU. VirtualBox has no such limitation.

VBox only supports 32bit host kernels and 32bit guest images. There is no 64bit support for either running under a 64bit Linux host kernel, or running a 64bit guest OS. The website does mention that 64bit support is under active development, however.

VBox has yet another virtual bus of virtual devices, akin to Xen's paravirtualized XenBus devices (or Virtual Iron's NexBus). While hardware devices are available (PCNet32, etc) using QEMU hardware emulation, VBox also has some excellent video/network/disk drivers that eliminate the hardware chipset emulation overhead.

VMWare tried to make VMI a standard for paravirtualized bus devices. The Linux kernel developer community initially balked, but VMI support lives on in Rusty's paravirt-ops patches. Recently, Ingo has been making great strides with paravirtualized kvm support.

One oddity is that VBox uses .VDI files for its disk images. Not QEMU's QCOW format, not VMWare's VMDK format, and not RAW disk image format.

And for the n00bs that keep popping in and asking about 3d support. No, VBox doesn't proxy 3d. No, QEMU doesn't proxy 3d. Yes, you can use a 3d card with a Xen paravirtualized domain (NOT with an HVM domain).

The only virtualization platform that supports 3d for Windows guests, that I am aware of, is VMWare 5.0 and later which have a somewhat crashy "beta" DirectX 3d support. (Simply add "mks.enable3d = TRUE" to your .vmx file by hand, for more info try googling for "mks.enable3d").

Parallels has promised 3d guests for 4th quarter of this year. If they deliver it, I will be pleasantly suprised.

If you really need 3d gaming for Windows games on a non-Windows platform, consider Transgaming's Cedega product line. Yes, it is Wine. Yes, there is a 50% overhead for the emulation. No, you're not going to do much better without running windows bare iron.

Where does this leave me? In limbo, mostly. I have a 32bit farm of Xen hosts moving toward a 64bit Xen hosting platform at the moment. Xen appears to be crawling while other tech like kvm and virtualbox keep popping up to challenge it. Xen's "maturity" is only really a year at best with its HVM support (quite a lead in tech terms), I can see l-hype/kvm and virtualbox quickly overshadowing Xen in the near future.

Eventually, VMI/paravirt-ops is going to level the playing field with standardized guest device drivers, regardless of hosting platform. Until then, we continue to craft guests based on the virtualization platform under which they will be run.