Development and Production Environment Review of Virtual Box 4

In summary of the details below. VirtualBox 4 up to 4.0.10 has some serious bugs on a Windows host with Linux x64 guest. No disrespect intended, but be careful. Get the full details below.

My experiences with VirtualBox first started during college as a security experimentation and an infrequently used tool. About eight months ago, we started investigating VirtualBox as a viable solution at work. In my day job in the museum industry we had more and more frequently been deploying complex server reliant solutions that were time consuming to set up and difficult to replicate in test vs production environments. Prior to Virtualbox, I had worked on a series of exhibits that the client used VMWare as their primary hosting environment, so it was easy for us to replicate production by easily spinning up their Debian VMWare images. I want to first run you through everything were running inside the Virtualbox VM, then Ill explain our experiences with it.

So in late 2010 I started work on a massive initiative at work for integrating content management into all our exhibits going forward. We relied on our old pal PHP, and decided to standardize on PostgreSQL. We went with Drupal for our content management along with a huge chunk of custom stored procedures in PostgreSQL 8.4 and PHP 5.3 for exhibit interaction. All the exhibits are done in Adobe Flash/AIR so we handled database interaction via PHP interacting with PostgreSQL and returning XML to the exhibits. Besides all that constantly going on with roughly 20 exhibits, the project required immediate synchronization with the clients website as visitors created media. I chose Java as the language to implement this functionality via Java 7.

The significance of all of that is that it was implemented inside of a VirtualBox 4 virtual machine. The host OS was Windows Server 2008 R2 64bit and the hardware was a Dell Power Edge 1U with 8 cores and 8 gigs of ram. The drives on which the virtual machine resides are 3 500GB drives in a RAID5 configuration. The guest operating system is Ubuntu 10.04 LTS 64bit.

Inside a development environment with a relatively small load, Virtualbox 4.04 preformed almost flawlessly. There was a memory leak in Windows and upgrading solved that while we were still in development. In order to back up the VM's we figured out that we could actually copy the running instance of the VM over the network to backups. This is a really neat feature that may not capture 100% the most recent VM, but it comes close.

A strange thing we noticed with versions up to 4.10 is that we couldn't allocate more than two or so cores to the VM or it would start becoming extremely unstable. We also had issues when trying to update the guest Linux OS. In 4.10 on another project we were relying on the Apache and PHP portion of the Linux VM to load image assets into a Flash based project. For some odd reason when trying to load these assets using a bridged adapter that no other activity was occurring on, we would experience a disruptive delay in simple HTTP requests into the VM. We had to abandon Virtualbox for that project due to time constraints.

In any case the VM seems to be a lot more stable since we pushed it up to Virtualbox 4.10 and upgraded Java 7 to the latest pre-realease. I'm confident that 4.10 may have stabilized the environment in our case, but I can't speak for other configurations. I guess in summary implementing VirtualBox is just like implementing any open source software, depending on the community and the attitude toward the project, you can anticipate what to expect.

On a personal note, I'll go with VirtualBox again. If you're in an environment where you have available funds, then maybe you should go with VMWare as it is a lot more stable. I really appreciate the efforts of the VirtualBox contributors and will advocate the software where possible.