Sunday, February 07, 2010

Pitfalls in hardware assisted virtualisation

Cloud computing is upon us, so the industry would have us believe.

Thanks to a plethora of advancements on the virtualisation front, it really does look like cloud computing will be the next tech revolution. What with Intel's VT-x and AMD's AMD-V virtualisation extensions to provide "hardware acceleration" to virtual machines in the same way GPUs did to 3D rendering plus the multicore revolution well under way, who's to say otherwise?

My recent upgrade to a AMD quad core system was also partly motivated by the need for more virtualisation horsepower. Running Windows in a virtual machine under Ubuntu was generally tolerable but there's always this feeling of "lag" with the VM that I just can't stand. Single core really does feel a little stuffy once you throw in a curve ball like virtualisation into the mix. Hence, the need for a better solution.

Sounds so good, so far.

Too bad there's been some hiccups along the way.

I make use of VirtualBox for my virtualisation needs. It's quite frankly the best solution I've used to far. Granted I've only ever tried Qemu, libvirt with Qemu-KVM backend, VirtualBox and VirtualPC (on Windows) but then I'm limited to open source or free closed source options.

A bug in VirtualBox 3.1 pretty much limits me to using 3.0 for now. Apparently even the latest BIOS on my ECS A780GM-A doesn't properly support AMD-V. Or, maybe it's just KVM not playing nice.

Virtual Machine Manager apparently doesn't like to share resources with between host and guest OSes. My sound device got screwed up once a guest started up which required a reboot to "fix". It also doesn't seem to support USB virtualisation, which means VirtualBox is essentially the only available option.

To sum things up, I need USB controller support in the VM, AMD-V support, and no hardware hogging from my VM solution. VirtualBox fits nicely. If I ever go back to Windows VirtualBox is also available while KVM and Qemu are pretty much Linux-only.