Description:

Motivated by heavy disk costs and slow deployment processes, scripts were developed in-house to make VDI administration easier without incurring any additional costs above that which is necessary. The outcome of these scripts is two tools whose usage will be described in this document.

Our current environment is a small installation of about twenty thinclients (and associated virtual machines) that make up our student accessible lab computers. Total storage consumption is hovering around 80 GB on a single datastore with Linked Clones distributed across 2 ESX hosts. Each VM is configured with 2 vCPUs and 1 GB of memory. At the moment, standard applications like office productivity software is being used on the production VMs. A discussion to extend the application set to include engineering and graphics design oriented software is currently underway thanks to the capabilities of HP RGS.

---

Update - (1/22/2009)

An issue was found with linked clones that are joined to a Windows domain. Win2k/WinXP/Win2k3 domain members change their computer account passwords every 30 days. When linked clones have been sealed in Step 7, the computer account password generated after joining the domain is saved in the snapshot. This becomes an issue on the 30th day (or 7th day in pre-Win2k machines) when the computer account password is changed and the domain controller receives the new password. Step 8 in the procedure defines that the linked clones are reverted to their state immediately after joining the domain. On the 30th day, this causes the old computer account password of the linked clone to be in effect consequently disallowing any communication between the domain controller and the linked clone.

This problem can be solved in five ways (in order of increasing work and accessibility):

Proactive Solutions:
1) Disable machine account password changes on the domain controller as per instructions from:
http://technet.microsoft.com/en-us/library/cc785826.aspx

This can be limited to just linked clone domain members by applying the necessary group policy security setting to these domain members. This is the solution we employed. Any linked clones that are "Powered On" should be "Rebooted" or "Reverted" and then subsequently "Powered On" after updating the GPO.

2) Disable machine account password changes on the master image (before link cloning) as per instructions from:
http://support.microsoft.com/kb/154501
These instructions apply to Windows 2000 and NT. Use the Windows 2000 instructions on Windows XP. This hasn't been tested. It doesn't seem as though the domain controller will override this setting but it is up to the user to find out.

3) Retire linked clones every month which will probably happen often due to image updates.

4) Delete linked clone snapshots before password update occurs on the 30th day and resnap the clones afterwards.

Reactive Solution:
5) Delete linked clone snapshots, unjoin each linked clone from the domain, rejoin each linked clone to the domain and resnap each linked clone using my-vmware-cmd.sh. This can actually be relatively quick and effortless if scripted properly.

---

Tools and Hardware:

• ghetto-esx-linked-clones.sh
• my-vmware-cmd.sh
• VMware ESX 3.5u3
• VMware Virtual Center 2.5u3
• HP SAM (Session Allocation Manager) [VDI Connection broker]
• HP RGS Sender/Receiver
• HP BL460c
• HP EVA4400
• HP T5730 thinclients

---

Implementation:

Step 1.

Create a Master VM image with Windows XP Professional, install VMware Tools and all applications that will be available on the Linked Clone VMs (including SAM registration and RGS Sender services). Ensure that the Master VM is set to automatically obtain an IP address via DHCP and that it is on the correct network that linked clones will be operating on.

Step 2.

Shutdown Master VM image.

Step 3.

Create Linked Clones using ghetto-esx-linked-clones.sh.

Step 4.

Create DHCP reservations on Windows DHCP server from the MAC address file that "ghetto-esx(i)-linked-clones.sh" creates using a custom .vbs DHCP IP reservation script.

Step 5.

Power on all newly created Linked Clones using VIClient if resources allow it.

Step 6.

Once powered on, a custom .vbs script utilizing WMI calls to request that the new Linked Clones join our Active Directory domain is executed from a Windows machine.

Step 7.

Once all VMs have been joined to the domain, the snap function of my-vmware-cmd.sh is run on these VMs. This is required to capture the pristine state of the system right after joining the domain.

Step 8.

At this point, the VMs are ready to be utilized by the available thinclients that have the HP SAM client installed on them. Changes that are made to the Linked Clones by users are discarded because the Linked Clones are refreshed every night using the revert function of my-vmware-cmd.sh that is scheduled with a crontab.

Step 9.

When an image needs to be rebuilt/upgraded, the Master VM image is cloned and worked on while the existing Linked Clones are online. Steps 1 through 7 are followed again on the new Master VM image and new Linked Clones are created with special attention towards disabling these new Linked Clones inside HP SAM.

Step 10.

The old inactive Linked Clones are disabled in HP SAM with old active Linked Clones left alone. The new Linked Clones are then enabled inside HP SAM. The old active Linked Clones will be manually disabled once the user logs out.

Step 11.

The purge function of my-vmware-cmd.sh is then used to destroy the old Linked Clones and all old Linked Clones are removed from HP SAM resources.

Note: With the advent of the new HP RGS licensing model, HP hardware is no longer necessary in a VMware VDI environment utilizing this display protocol.