Even for the most simple of network operations, having multiple servers can be a necessity. Take OmniNerd for instance. As sweet as it is on the front end, behind the scenes are multiple development machines, a code test environment and a deployment test environment amongst others. But since nobody has been making multi-million dollar cash donations to the cause, we needed to utilize virtual machines to keep costs down. I’ve been using virtualization software for almost ten years now and was pleased to know there were many options available for OS X. But how to decide? I chose the following criteria to base my assessment:

1. minimal impact on the host environment
2. ease of remotely accessibility (preferably bridged networking)
3. ability to take snapshots
4. dynamically sized virtual disks
5. price of the software

I did not care about desktop integration features. Although nice for a development environment using GNOME/X, the dominant interface to these servers would be remote terminals. At my disposal was Parallels, VirtualBox and VMware. Fortunately, factors 3 and 4 were available on all three virtualization solutions and both Parallels and VMware supported bridged networking. Each guest operating system was installed identically following a prescribed disaster recovery plan. This guaranteed that each "idling" virtual implementation was exactly the same.

I began by constructing the test platform using version 3.0 of Parallels Desktop (build 5584). While the application was very nice and featured some fancy integrations with OS X, it did have a critical flaw for hosting a test environment. When the installed system was completely idle, OS X showed the Parallels hypervisor consuming 20% of the host’s CPU cycles. A cursory Google search revealed a forum on the Parallels site where a number of users complained of the same host resource usage. When a patch was released (builds 5600 and 5608), the Parallels update indicated the host CPU usage problem was fixed. Unfortunately, when configured to optimize the host’s performance, it reports in excess of 30% CPU usage while the guest operating system was idling. After switching to boost the virtual machine’s performance, the host reported more than 40% of the CPU in use while the guest idled. This was completely unacceptable.

My next foray into constructing the test platform utilized VirtualBox version 1.6.0 released by Sun. VirtualBox comes with a clear advantage over the competition – it’s free! However the big strike out of the box was that bridged networking is not included in the OS X release. This meant I was required to configure port forwarding within the network address translation in order to make the guest visible across the Internet. I must commend VirtualBox, however, in that configuration is very easy and based on named labels instead of IP addresses which allow the guest to continue being mapped no matter what IP it was assigned. Everything seemed fantastic with this product until I walked away. At my last glance, the CPU usage was minimal when the guest was idling. Within ten minutes, though, the host CPU spiked upwards of 60% and remained as such. Figuring it must be a fluke, I reinstalled not only the virtual software but several guest environments and regularly saw this behavior. VirtualBox was now performing worse than Parallels.

My final test environment installation utilized version 1.1.3 of VMware Fusion. The features within VMware were immediately impressive, like its ability to actually use multiple processors instead of simulating only one. After installing the test platform to specification, I was pleased to notice the idling VMware hypervisor used less than 2% of the host’s CPU (optimized for host performance). When VMware was optimized for guest performance, roughly 10% of the host’s CPU cycles were used. I was not pleased with the difficulty I encountered with the networking – although I might add it does not seem to be a function of VMware. When configured in bridged networking mode, the guest was visible to all machines on my local network but the Apple Airport Extreme would only return ICMP Network Unreachable errors for anything on the external network. After that problem was resolved, VMware only exhibited one more peculiar quirk. Regardless of the performance mode chosen, VMware Fusion would cease responding to the remote terminal – although the terminal session would never timeout. The virtual machine would only respond when a new session was initiated and it would be slow to respond at first before performing quickly again.

At the end of the testing, VMware technically was the only virtualization platform that met the critical factor of not significantly imposing itself on the host system. Due to the glitch in getting VMware to "see" beyond the Apple Airport, Parallels was superior for time from installation to live configuration. VirtualBox has its virtue as well; a $0 price tag is difficult to ignore. What are your impressions with virtualization software options for the OS X platform?