Review of VirtualBox 4.1.14 under Windows Server 2012 beta

VirtualBox has been my main desktop virtualization solution for the past 3-4 years. VirtualBox started out as a kind of weaker version of VMware Workstation, but VirtualBox has really improved (branched snapshots etc.) over the past few years so I really can't complain especially since it has a liberal evaluation license.

VirtualBox is pretty friendly for desktop users, and is a so-called Type 2 hypervisor, so I wondered how it would fare in terms of performance relative to Hyper-V or ESXi. Turns out not too bad.

As I mentioned, I had trouble installing VirtualBox 4.1.14 on the newly released Ubuntu 12.04. The problem could well be "user error", but I figured I could see how VirtualBox performs on Windows Server 2012 (beta). This would also give me a chance to compare Windows Server 2012 with Windows Server 2008 R2.

Installation

Installation of Virtual Box 4.1.14 was easy enough on Windows Server 2012. I choose to install Windows 2012 Server with a GUI, although it's nice that you now can install without the overhead of a GUI.

VM Creation

When I used the VirtualBox wizard to create my guest image (64-bit Lubuntu 12.04) it seemed like VB wanted me to create a 32-bit guest. I didn't see an option to force VB to choose 64 bit. I pointed to an .iso with 64-bit Lubuntu, and set the RAM to 1024 MB. Upon boot, I received an error about 32/64 bit mismatch.

I saw the following tips from http://www.virtualbox.org/manual/ch03.html :

On any host, you should enable the I/O APIC for virtual machines that you intend to use in 64-bit mode. This is especially true for 64-bit Windows VMs.
...
If you use the "Create VM" wizard of the VirtualBox graphical user interface (see the section called “Creating your first virtual machine”), VirtualBox will automatically use the correct settings for each selected 64-bit operating system type.

I'm not sure about the automatic selection. Didn't work for me. To force 64-bit, I choose 5120 MB RAM for the guest, and then the VM was created properly. I later dialed back the memory to 1024 MB.

However, when I booted the VM in VirtualBox I received this error : "AMD-V is not available".

Looks like this, not unsurprisingly, arises when you have Hyper-V turned on with Windows Server (reference). When I installed Windows Server 2012, I installed Hyper-V. Uninstalling Hyper-V (and rebooting) enabled me to boot the VirtualBox guest without this error.

Performance

Running my "favorite" tests from the Phoronix Test Suite lead to fairly expected results. I found that VirtualBox performance was within 10 percent of ESXi and Hyper-V guests, with a couple notes.

First, my initial VirtualBox guest used Microsoft's .vhd disk format. Normally I use VirtualBox' native .vdi disk format, but I thought I'd experiment a bit and see how interchangeable the .vhd format might be between VirtualBox and Hyper-V.

I never got around to trying the resulting .vhd disk image under Hyper-V, but I did observe that using the .vhd format resulted in reducing the performance of VirtualBox relative to using the native .vdi format. So, when creating VirtualBox guests, use the native .vdi disk format.

The second performance note was the improvement you'd see if you ran the VBox guest headless. I found the following on launching VBox guests headless :

http://johnmee.com/2011/05/start-headless-vbox-on-windows-2/

Running VBox headless improved the performance of my tests by about 5 percent, so in this case the VBox results were virtually the same as Hyper-V and within a few percent of ESXi guests.

However, running headless had it's downside. I had to use my router to determine the VM's IP address. I could start up the VBox manager to see which machines were running, but the overall experience seemed a bit odd. For my purposes, I'll have the better user experience of seeing my guests and giving up a few percent in performance.

I was also pleased to see that when running three VirtualBox VMs concurrently, performance didn't fall off a cliff.

VDI vs. VHD Disk Performance

When creating the virtual disks, VirtualBox offered to create the disk in VDI (VirtualBox), VMDK (VMware), VHD (Hyper-V) or HDD (Parallels) format. Since I was testing on a Windows 2012 Server, I initially created in VHD format with the thought that I might be able to reuse the image later for Hyper-V testing.
I also created an image in VirtualBox' native VDI format.

I found that, not surprisingly, VirtualBox' native VDI disk format gave better performance than VHD. For file compression tests (7-zip, bzip), the VDI format improved performance by 5-10 percent.

VirtualBox Headless Performance

Normally one launches, monitors and maintains VirtualBox VMs through a GUI "Manager" application. When launching a given VM, you're also given a window which provides "console" access to the VM.

However, it's possible to launch VirtualBox VMs in a "headless" manner whereby the "Manager" window doesn't open and you don't have a console window open either. Presumable, headless operation should give better performance.

I found that running a VirtualBox VM in a headless manner improved performance by maybe 4 percent. However, I liked the dashboard-like feedback that the "Manager" window provided, and it also was nice to have a console window open at times. For my purposes, running a VirtualBox VM headless wasn't worth the cost in convenience.

Categories: 

There is 1 Comment

When running a VirtualBox VM in headless mode, you can still setup an RDP listener port for the VM, and then use an RDP client (such as Microsoft's mstsc) to open a UI to the VM.

This allows you all the capabilities of accessing the VM's "real console", though I don't know how it will affect performance of the VM (I would guess it wouldn't be much of a change compared to the non-rdp headless mode).

Additionally, if you want to know what IP your guest received, and you're not using VirtualBox's bridged networking mode, then you can easily see the IP address from the VirtualBox manager's UI.

Also, regarding my previous comment about spam filtering the comments - it seems that your spam filter had a problem with me putting a URL in the "homepage" field of the comment form. Removing the home page URL got the comment in. This seems to me a bit broken...