Virtual Mac Test Lab

The Apple platform has recently become an active part of our software development platform.  I set out to build a virtualized Mac test and development environment in the same way that we have been doing for the Windows and Linux world for some time now.  One of things I have quickly discovered is that although we have had some wins on this approach, the industry isn’t quite ready for enterprise Mac virtualization yet.  Here’s the details:

We ordered a high-end Apple XServe with 8 Cores and 16 GB of RAM.  I decided to go with VMware’s Fusion for the hypervisor for several reasons.  First of all the cost was substantially less than other products available, such as Parallels Server ($79.99 vs. $1248.75) for the same relevant feature set.  Secondly, it provides easy conversion with the rest of the VMware platforms that we already use.

Although Fusion is inherently designed to be a desktop virtualization platform (kin to VMware Workstation), it has some features below the surface that make it usable as a virtual server platform for Mac machines (from the Power Users Guide to VMware Fusion):

Scriptability

Fusion 2.0 supports ‘vmrun’ which is a way to interact with virtual machines through the command line. It is located in “/Library/Application Support/VMware Fusion/vmrun.”  You can also set Fusion to take action on certain signals by adding these option to the .vmx (for that VM only) or ‘~/Library/Preferences/VMware Fusion/config’ (for all VMs):

signal.suspendOnHUP = "TRUE"
signal.powerOffOnTERM = "TRUE"

You can also use VMware Tools to run scripts on the guest in response to certain actions (ie. Power On, Shutdown, suspend, etc.)

fluxcapacitor (running headless)

VMware has split off the GUI process and the VMX process allowing you to leave machines running regardless of the GUI state.  You can, of course, “Force Quit” the GUI to prevent it from invoking suspension on the running VM’s.

Or, in Fusion 2.0 you can engage the fluxcapacitor! Just run the following command in a Terminal Window:

defaults write com.vmware.fusion fluxCapacitor -bool YES

You will now see a new menu item in the ‘View’ menu: “Headless”.  You will probably always want to use the signal config options mentioned above to allow you to safely shut down the physical machine without having to reconnect to the VM.

And most importantly VNC Server

Like Workstation, Fusion also has a built-in VNC server. This allows you to connect to the guest without having a VNC server installed on the guest.  This gives you the “console” functionality that you have on server based products.  This is ideal for “headless” mode and racking your XServe.
The VNC server is set up on a per-VM basis, and is disabled by default. To enable it, add the following lines to the .vmx:

RemoteDisplay.vnc.enabled = "TRUE"
RemoteDisplay.vnc.port = "5901"

You will, obviously, need to dedicate (and remember) a port number for each VM you are running a VNC server for.

Using the above methodology we have been able to successfully create Mac based environments.  However, Apple has only officially allowed support for virtualizing its OS X Server platforms, which works well “right out of the box.”  We have been able to get Leopard (client) to work, but it involves a bit of a “hack” which will technically involve violating your license agreement.  Here is a completely theoretical and academic explanation of how to make it work…

When you try to install the Leopard Client as a guest you get this error: “The guest operating system is not Mac OS X Server.”

1. Create an ISO/CDR image from your Leopard install DVD.
2. Mount the image.
3. Run in terminal: touch “/Volumes/Mac OS X Install DVD/System/Library/CoreServices/ServerVersion.plist”
4. Unmount the image and you will be able to use that image to install Leopard Client in Fusion with no complaints.
5. When the install comletes, reboot the guest from the install DVD ISO image once again.
6. Run Terminal and execute: touch “/Volumes/Macintosh HD/System/Library/CoreServices/ServerVersion.plist”
7. Finally, reboot from the HD.

We have also found some academic research on how to get Tiger VM’s to work as well, although thus far have not gotten it work successfully.  There is a great step–by-step guide here: http://www.macosxhints.com/article.php?story=20081031054054546

In summary, there are a lot of valuable tools out there for integrating the Macintosh world into your virtual fabric.  However, it’s far from easy and seemless.  I would put the challenge out there for Apple and hypervisor vendors alike to work together to find ways to make enterprise Mac virtualization a reality.  The current stumbling block as I understand it, is that Apple has not relaxed the reins on their license agreement for client OS’s.  One reason for this that I have heard discussed was that Apple’s OS does not have the same need to be virtualized that Windows does.  The claim is that it is so much better engineered, that it is capable of juggline multi-tasking better on the same machine.  Thus, there is no case for making more seperate machines.  This argument has some validity, however, it is only taking the performance vector into consideration.  In my specific case, I am looking for the convenience and managability of a test lab environment for our software development process.  Of course, Apple could easily make a counter-argument for hardware sales.  They exist in a slightly different space than the rest of the players, since they produce both a hardware and software solution.  Either way, there is a need out there and if Apple wants to enhance its developer community, giving its blessing to setting up virtual environments would be a great step.