VMware Composer and Linked Clones - VMware View: Chapter 9

VMware Composer and Linked Clones


If you are using linked clones with Windows 7, the new version of View Composer requires that you running license activation services in your environment. This will means you will either need a “Multiple Activation Key” (MAK) or a “Key Management Service” (KMS), requiring a KMS key for the linked clones feature to work with Windows 7. Specifically, you will receive this error message in the View located in the “Inventory” tab of the affected pool:

View Composer agent initialization sate error (16): Failed to activate the software license

This activation issue will be particular challenge to those people who need to demonstrate or train View 4.5 with Windows 7 as a guest operating system. A simple work around until Microsoft changes its activation routine might be to use Windows XP that still supports volume “corp” license keys.

As you can see, using conventional templates and virtual disks to create virtual desktops does come with some significant disadvantages. First, even with thinly-provisioned virtual disks you can waste disk space on very expensive shared storage. Second, although the automated provisioning of virtual desktop pools is efficient, it can be a huge storage hit on the array. If you have many desktops to create in a short period of time, it can take some time to complete the build process. Third, while Sysprep is fine as an engine to reset the Security ID and Domain parameters, it isn’t the quickest of processes, even when automated by guest customizations.

With this in mind, VMware View3 introduced the Composer feature and Linked Clones. The concept is a simple one. You create a single Master virtual desktop – very much in the same vein that we have covered so far. In VMware Composer, this is referred to as the “Parent VM”. A snapshot is taken of this Parent VM, and then a replica is generated. From this replica, linked clones are created. The reason they are called linked clones is that fundamentally the source of a clone’s information comes from the read-only replica.

The difference is that rather than using the template process to create a virtual desktop, only a file containing its delta (or differences) is created. Linked Clones are called such because the clone is linked to a replica of the Parent VM. In this way we can significantly reduce both the storage costs and deployment time. Additionally, it means that when changes are made to the master, the changes are proliferated to each of the linked clones, in a process which VMware calls “recomposing”. The virtual desktops are not linked to the parent VM but to the replica – this allows you to reuse the parent VM as the source for other linked cloned desktops. If you are using automated dedicated pools with linked clones, the replica disk is marked as read-only, all changes a user makes are sent to the VM’s delta virtual disk. Additionally, there is an optional “disposable disk” that used to be called a “user data disk”. This disposable disk holds a local profile for the user. The disposable disk is marked as being read-write, and the user is allowed to make changes to their profile and environment, albeit circumscribed by their Active Directory Group Policy settings. The user disk is automatically created and attached to the virtual desktop at first power on, and is assigned a drive letter that you choose when creating the linked clone. These disk types can be configured as what is called a persistent or non-persistent disk. The difference between them is that with a persistent disk, user profile changes are retained when the user logs out, and with a non-persistent disk, user profile changes are discarded. If your virtual desktop pool is automated and dedicated, I would recommend using the persistent disk type. On the other hand, if your pool is of the floating type I would recommend the non-persistent disk type. It’s worth stating that there are innumerable methods of handling the troublesome user profile, and you might want to investigate those first.

Such savings in space and time have been around at the storage layer for some time from such vendors as NetApp with their SnapClone and De-Duplication technology. If you have these storage technologies already, you may wish to evaluate their effectiveness and cost before using the linked clones feature. It’s worth noting that these so-called high-level storage features from the storage vendors are not always free and often require a license to function. With this said I think the future maybe that while VMware View may be the place where you create and define VMs, the instructions to carry out the cloning process will be sent directly to array to offload the copy process.

Perhaps the best analogy for Linked Clones is to compare their utilization of disk space with the way that ESX utilizes memory. In ESX, it is possible to allocate more memory to the VMs than is physically present on the ESX host. VMware call this memory over-commitment. Well, in a very similar way with View Composer, we can create more virtual desktops than we have physical disk space for. As with memory over-commitment, with disk over-commitment we must monitor very carefully the actual disk space used. View Composer comes with built-in settings that control what happens if we get close to using more disk space than we actually have available. In many respects, it’s like having virtual storage on an expensive array which might not even possess this feature.  

Finally, VMware have developed their only utility to replace Microsoft Sysprep, which is called QuickPrep. As the name suggests, the intention is to add a linked clone virtual desktop to a Microsoft domain as rapidly as possible. QuickPrep uses an account in Active Directory that you have configured with rights to join computers to the domain. It then pre-populates computer accounts in the domain, which significantly speeds up the deployment process. In addition, QuickPrep allows the administrator to specify where those computer account objects will be created using the Distinguished Name format (e.g. OU=Virtual Desktops, OU=Marketing), thus ensuring the right Active Directory Group Policy objects are applied. Additionally, if you delete the linked clone virtual desktop pool it will automate the process of deleting the computer accounts in Active Directory -- it’s worth noting that Dynamic DNS records can still be listed in the DNS database.

For linked clones to be possible, you must install the VMware View Composer Service onto your vCenter server. View Composer also needs a back-end database and it is possible to create a new database on your existing database server that is used to hold other VMware databases for features like vCenter and VMware Update Manager.

Want to read more of this guide?

Download the full “Administering VMware View 4.5” Guide (21 Chapters). The full guide contains additional step-by-step instructions and screen shots in each chapter.

Dig Deeper on VMware Resources