Tuesday, March 8, 2011

Virtualization solution #2: VirtualBox

So the next piece of virtualization software that I was going to try out is VirtualBox. Remember, my Linux is installed on an entirely separate hard drive pair, that I mapped into VMware Player as two drives then installed Scientific Linux 6 onto one of the RAID arrays previously configured on that drive pair for that purpose (a 20GB RAID1 pair). 'grub' handles that situation just fine, it skips the RAID header and loads the Linux kernel and does its thing. At that point, I can see the remaining 1.8 terabytes of RAID'ed LVM volumes.

So I fire up VirtualBox and go to create a virtual machine via its GUI and... err... it doesn't allow me to assign physical drives to my VM. Which is one of those "WTF?!" moments, because the underlying QEMU that VirtualBox is based upon certainly has the *capability* to add physical drives into a virtual machine, but a bit of Googling around finds that you must do some cryptic command line hacking to make VirtualBox do it. The GUI won't do it.

At that point, realizing that VMware was point and click and ridiculously easy to set up and did what I wanted it to do without said hacking, I said "F*** that" and uninstalled VirtualBox. It may be that VirtualBox could perform better than VMware Player. But my time is more valuable than any tiny increment of performance that VirtualBox could potentially give me compared to VMware Player.

Next up: I check out Windows Virtual PC and see what I can do with it. For one thing, it'll be cool to try Windows XP Mode, even if it turns out not to be useful for virtualizing Linux...

-- ELG


  1. ELG,

    I have a used macbook I recently purchased (finally!) and when I upgraded the hd I added Parallels to the purchase at 1/2 price. Compared it to VB with the same Maverick guest install on both. Parallels blew VB out every way possible both from the host and guest point-of-view. Dumped VB.


  2. I dumped Parallels for VMware Fusion several years ago on my Macbook because VMware's I/O performance was much better than that of Parallels for Linux virtual machines at the time. As for Virtualbox, my guess is that you ran into two different performance issues there. The first is that the VB GUI doesn't expose RAW files as disk drives, just QCOW2, and QCOW2 runs excruciatingly slow on any journaled filesystem (such as the default Mac HFS+ root partition on a Mac). If you select RAW for your hard drive format rather than QCOW2 via creating the disk by hand with the QEMU command line tools you can get disk performance *way* up, basically equal to Parallels, though not as good as VMware with Linux. The second issue you likely ran into is that VB doesn't have any real integration tools for Linux. Your Meercat has paravirtual hard drive and network drivers already installed into it for running as a Virtualbox guest (they're the same drivers used for KVM, because QEMU is doing the heavy lifting for both), but VB may not have configured the drive and network as Linux paravirt drivers when it created the VM and when it comes to video drivers... nuh-uh. You're going to be slow, slow, SLOW.

    Regarding Parallels and VMware Fusion on the Mac, Parallels in my testing had better graphics performance with Windows but poorer I/O performance with Linux. VMware has paravirtualized drivers for Linux and they run *fast*. VMware's graphics performance is somewhat limited by the structure of the program -- it's inherently a network-based protocol even when both pieces (VM and screen viewer) reside on the same system -- but has proven fast enough for non-game use for me, and the Unity feature works very well. It may be that Parallels has improved their Linux performance, I haven't tested the latest release. But one thing is clear -- *both* work better than the current incarnation of VirtualBox. The only thing VirtualBox has going for it on the Mac is that it's *free*, which neither Parallels nor VMware Player are. But this is a case where you get what you pay for...