This past Saturday I enjoyed the hospitality of the Tampa SQLSaturday (#32) team.  My presentation was “Clustering for Mere Mortals”.  Unlike many clustering presentations, I had demonstration content.  This resulted in the most asked question being “Do you have instructions on how you built that?”  This is the first part of those instructions.

Here is what the cluster consists of (Virtually):

One Windows 2003 R2 (x64) Server acting as Domain Controller, DNS Server, DHCP Server, File Server and iSCSI Target Server

Two Windows 2008 R2 Servers as cluster Nodes.

All this runs on a Lenovo W500 laptop with an Intel Core 2 Duo T9600 processor, 8 GB RAM and a 320 GB Internal Hard disk running Windows 7 Enterprise (x64).  The total disk footprint is slightly under 50 GB for all virtual guests.

One of the toughest decisions was choosing a virtualization platform.  I didn’t want to run Windows Server 2008 R2 on my notebook since that took away Hibernation and Sleep modes, plus getting the drivers for WiFi, Bluetooth, etc. working is a real pain.  VMWare was out since I wanted this to run Microsoft VHDs I downloaded for training as well as my new demo cluster.  Virtual PC was out since I needed 64-bit guest capability to run Windows 2008 R2 as a guest.  I found a winning candidate in VMLite.  VMLite is a Windows implementation of Sun’s VirtualBox platform.  It supports VDI, VMDK and VHD disk formats as well as 64-bit guests.  Incidentally, it is also free.

Based on prior experience with the above virtualization products, I chose to create a VM folder off of the root of my C: drive.  Below that I created a Machines folder and a HardDrives folder.  Set I then these as default locations in VMLite.  I also copied the VMLiteGuestAdditions.iso file to this location so it was easy to find later.

Like most Sun products (cough Java cough) it is semi-hostile to Windows users.  Still, this was the option with the lowest suck factor so I started building.  VMLIte does have a few quirks you have to learn to work around.  VMLite uses a UUID to identify virtual disk files to its Virtual Media Manager.  Evidently unique file names and paths are not adequate, probably because XML isn’t involved.  So if you copy a VHD file it will not allow you to “register” it with the Virtual Media Manager without a “mother may I?” step.   Many of the VHDs downloaded from Microsoft also have identical UUIDs, even ones for different training classes.  Common base OS image is the most likely explanation.  Anyway, to fix this is actually pretty simple

Open a command prompt

Change directories to the VMLite executable folder (C:\Program Files\VMLite\VMLite Workstation on my system).  Look for the VBoxManage.exe file. 

Type:  VBoxManage InternalCommands SetUUID <path\Filename to VHD>  Note:  Do not put quotes around the path and filename.

Using this technique you can now add any VHD file to the Virtual Media Manager tool in VMLite .

Interestingly enough, VMLite will not create a VHD file when you define a new Virtual Machine.  It natively will create a VDI (Sun Virtual Device) file.  You can use the Windows 7 Disk Management tool to create a VHD file with the correct characteristics and then detach it from the Host OS for use in a VM.

There are some other unexpected behaviors of VMLite (remember I did mention user-hostile?)  but no show-stoppers.  Finding them will be left as an exercise for the student. J

Start building OS base images and generally working in VMLite to get familiar with it.  At this point, you should be able to create new VMs, import existing VHDs, and generally do basic functions and navigation within VMLite.  We still have a ways to go to build a cluster, but we have a solid foundation to start on.