View Composer and Linked Clones

Introduction View Composer and Linked Clones

Version: Horizon View 5.1

What are Linked Clones?

As you have seen, using conventional templates and virtual disks to create virtual desktops does come with some significant disadvantages. Firstly, even with thinly-provisioned virtual disks you can waste disk space on very expensive shared storage. Secondly, 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. Finally, whilst 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 customisations.

With this in mind, VMware introduced the View Composer feature and Linked Clones concept. The concept is simple, 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 read-only 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 this 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. It also means that when changes are made to the master, the changes are propagated to each of the linked clones, in a process that VMware calls “recomposing”. As the virtual desktops are not linked to the parent VM but to the replica, you can reuse the parent VM as the source for other linked clone 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 are two option disks the first is a persistent disk, this persistent disk can be configured to hold the Windows profile for the user. The persistent 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 persistent 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 persistent disks are not affected by composer operations such as refresh and compose which means that the users profile is always. Even though you can use persistent disks when there is no other profile management in place to keep the users profile between composer operations, our recommendation would be to investigate the alternative profile management solutions. Using persistent disks adds complexities such as how to backup this data. The second optional disk is a disposable disk, the disposable disk allows files such as temporary Internet files to be redirected to the disposable disk, when the user ends their session the data is deleted. This stops unnecessary bloating of the deltas for the linked clones.

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. Increasingly we are also seeing storage vendors supporting VMware integration and being able to offer cloning of LUNs at the array level and they are then able to register these cloned VM’s with vSphere and View. One example of this is Dell Equallogic’s Thin Clone technology that works alongside their VMware Host Integration Toolkit, which is included with no additional license. We will be looking at these storage vendor specific methods of cloning in Chapter 12. 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. 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 thin provisioning functionality on an expensive array which might not even posses this feature.

VMware have developed their own 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 will significantly speed 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. If you delete linked clone virtual desktop pools it will also automate the process of deleting the computer accounts in Active Directory, it is 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 this on the existing database server that is used to hold other VMware databases for features such as vCenter and VMware Update Manager.

Managing Activation Issues

IMPORTANT: If you are using linked clones with Windows 7, View Composer requires that you running license activation services in your environment. This will mean you will require a “Key Management Service” (KMS) for the linked clones feature to work with Windows 7. If you don’t run KMS you will receive this error message in the View located in the “Inventory” tab of the affected pool.


We are not going to cover the installation of KMS but there are many resources available by completing a quick Google search. One thing to note is that KMS has a minimum of 25 devices attempting to be activated prior to it kicking into life, for a small PoC this can be a pain, to overcome this you will need to ensure your first pool is at least 26 desktops in size, subsequently KMS will kick into life.

Of course if you don’t have access to KMS keys this could make a PoC very difficult, luckily we found a registry hack that can be used to skip the activation stage of the customization process so you can utilise MAK keys in the short term, you need to be very careful with this as it will cause your MAK license count to increase with every recompose operation. VMware used to have a KB explaining how to do this, but it now just appears to have been withdrawn – VMware KB 1026556.

You will need to modify the registry on the parent VM, the location within the registry is HKLM /System /CurrentControlSet /services /vmware-viewcomposer-ga and you will need to change the SkipLicenseActivation entry to ‘1′

Once you apply the registry key, and reboot the virtual desktop, it will be able to continue with its “Customizing” phase. Once the desktop has completed “customizing” phase it will reboot and then be available. If you have a lot of virtual desktops that are afflicted with this, you could export the registry key and just import it. Of course, you would want to apply this key to the Parent VM and any templates so you don’t have this problem again

Install View Composer

1. To begin we will need to create a new blank database for View Composer on a SQL server. We recommend using a full licensed copy of SQL Server rather than Express where possible, but in a smaller environment or lab you will get away with Express. Once you have created the DB and relevant users note these down as you will need them later.

2. Log on to the vCenter desktop, and run the VMware-viewcomposer-N.N.N-NNNNNN.exe

3. Click your way through the usual suspects of Welcome, File locations and EULA

4. In the Database Information dialog supply your vCenter DSN Settings


5. Accept the default port for View Composer, and allow the installer to generate the default certificate for it


6. Choose Next and Install

Enable View Composer in Horizon View

1. Login to the Administrative webpage of the Connection Server

2. Select the >View Configuration icon

3. Select Servers

4. Select the entry for your vCenter and click the Edit… button

5. Ensure that the username used for you vCenter connection uses the fully qualified domain name e.g.\administrator

6. Click the Edit button the View Composer section of the screen

7. Select the View Composer co-installed with vCenter option (New in 5.1 we can now install View Composer on a dedicated machine if we wish or have a particularly large environment)

8. Next select the Verify Server Information button

9. If you are not using valid certificates you will need to accept the certificates shown to continue


10. Next click the Add button to set the service account for View Composer

11. In the Add Domain popup complete the dialog box, we recommend using a dedicated service account rather than the domain administrator as in our screenshot.


Once enabled you should find the icon for vCenter in the View Admin web page changes to to this:

Screen Shot 2014-05-02 at 13.48.00.png

Prepare The Parent VM

The Parent VM forms the base of the virtual desktop pool using linked clones. It’s probably a good idea to create a brand new VM from one of your templates that you know works without error. We would avoid re-using some existing VM for use as the parent – it might be claimed by View for a user. If a VM is chosen which has already been created and entitled, it will NOT appear in the list of Parent VMs in the wizard.

We like to create a special folder for our parent VMs before we begin.


1. Login to the Parent VM

2. Confirm it is joined to the domain

3. Release its IP address with ipconfig /release

This is done to make sure that the clones do not retain the IP address settings of the parent VM.

4. Shut down the Parent VM

5. Snapshot the Parent VM, allocating a friendly name such as Baseline Snapshot or alternatively name your snapshot after a grouping such as “Accounts Baseline”. A parent can be used multiple times by different pools. But we imagine many people will want to have one parent per pool to keep it nice and simple

Create the Linked Clone Persistent Pool

1. Log in to the Administrative webpage of the Connection Server

2. Open the >Inventory

3. Select the Pools node

4. Click the Add… button

5. In the pool type, select the option called Automated Pool

6. In the User Assignment page, select Dedicated as the method, and ensure Enable automatic assignment is selected as the option

7. In the vCenter page, select the option called View Composer linked clones


8. Next you must specify a unique ID for this virtual desktop, together with some friendly information by which the end user will be able to identify the virtual desktop. In our case, we set a unique ID of AccountsGroupWin7, with a friendly name of Accounts Group Windows 7 Desktop

9. The Pools Settings page allows you to control some per-virtual desktop settings that centre around the end user connections which are unique to using linked clones. This part of the wizard remains the same, however a new option will also be displayed – allowing control over the use of the “Refresh OS Disk after logoff” option


This refresh at log off causes the user’s virtual desktop to shutdown, and the delta virtual disks to be discarded. New delta virtual disks are then created. The entire process can take some time and if the user attempts to log out and log in quickly they can find that the virtual desktop is not yet ready. If the user attempts to reconnect while this process is still on-going, they will receive a message in their client indicating that their virtual desktop may not be available.


Personally, we have found users find this annoying, especially as logout and login are sometimes used as a cure all for fixing problems in Windows. Personally, we would consider using “Never”, and instead use the Connection Server’s manual “Refresh” option which allows to you refresh the desktops at a given date and time or alternatively make use of the available PowerShell cmdlets to automate this process. This would allow us to refresh the virtual desktops during the evening or weekend in such a way as to minimize the impact on end users.

10. The Provisioning Settings page controls how the virtual desktops will be created in the pool. In this case we were able to use much larger values for max, spare and min because each VM will take up a fraction of the disk space used with virtual desktop pools created without linked mode.


11. The View Composer Disks page allows control of the user profile disposable disk. In our case, because we opted for the automated and dedicated pool type, we selected to “Redirect Windows profile to a persistent disk”


There are lot of options here which we think really need clarifying. If you choose Redirect Windows profile to a persistent disk you essentially abandoning the concept of roaming profiles. Every time the user logs in they are returned to the same desktop with the same persistent profile. If you choose “Do not redirect Windows Profile” the profile remains in the C drive until you enable roaming profiles from Microsoft.

The Disposable Disk is used to handle the location of temporary files – a good example of this is the swap file in Windows. If this is enabled these temporary files are relocated to the new location, and destroyed at log off. It’s worth mentioning that you could choose not to redirect the Windows profile, and use roaming profiles – but augment that solution with some kind “virtual profile” feature. Also included in View 5 is their profile management feature that they purchased from RTO software, check out the dedicated chapter on this topic, there are also a number of alternatives such as profiles redirected through group policy or third party products such as RES Workspace or AppSense.

12. On the Storage Optimization page we can set our policy for storing the different types of disks to get optimal performance.


13. In the vCenter Settings page we can select the Parent VM that will form the basis of the linked clone. Each select button allows you to browse the vCenter selected earlier to indicate where the VMs should be located in terms of the VM Folders, Cluster and Resource Pool. In this case the wizard changes appearance to allow selection of the Parent VM


14. After selecting the Parent VM, you are then able to select the snapshot taken earlier:


15. We now will select the folder, cluster and resource pool that our desktops will reside in.


16. Select a storage location. Again, this dialog box changes once you are using linked clones. The interface allows you to place the OS Disk, Persistent Disk and Replica disks on different storage locations depending on what setting we choose on the storage optimization view The emphasis in the dialog is on the space required for the linked clones, but remember that these different datastores could also be on different tiers of storage offering potentially different levels of both performance (SATA/FC/SDD) and fault tolerance (RAID5, RAID10 etc). Additionally, View estimates your storage consumption, and you are able to indicate how conservative or aggressive you are to disk over-commitment.

The screen grab above shows the options that are available for storage overcommitment.


With linked clones, it’s possible to create perhaps 50 virtual desktops from a 10GB parent, but because the clones are merely deltas of the parent, they will not take up 500GB of disk space. In fact, they will take up much less. When we set up the storage, we hope that the VMs never actually need all the disk space we are assigning. The dropdown option allows us to set preferences of Aggressive, Moderate and Conservative as our estimate of how intensively we want to over-commit the storage used. If we select Aggressive, we are indicating that we expect the delta files and the user data disk to grow in size very slowly – thus allowing us to create many virtual desktops with very little available storage capacity. By contrast, the Conservative option allows us to indicate that we expect the delta and the user data disk to grow rapidly. Clearly, if we have a policy to always “Refresh OS disk at logoff”, the size of the deltas will be very small. The longer you retain the delta data, the greater the amount of free disk space you will need to hold that information, in a worst case scenario where you aren’t refreshing the disks at logoff these could grow nearly as large as the replica VM.

At the bottom of the page, VMware do a good job of estimating the actual disk usage compared to the delta file usage. These numbers will turn red if you try to do something silly, like trying to create 1,000 desktops on a 10GB volume. This will happen if your datastores have less free space than the value represented in the Minimum Recommended column. In the screen grab above, we selected different datastores which clearly have insufficient space for the volume of VMs we are creating, despite the space-saving properties of linked clones.

17. We will now configure the Advanced Storage Options as we have in previous chapters, remembering to configure our blackouts during the working hours for the host cache regeneration. We also have a new option to be able to configure native VAAI offload for the linked clones capabilities to supported NFS arrays, note that this is only a technical preview at the moment.

18. Finally, you will able to specify options for VMware QuickPrep. The browse button allows you to locate an OU where you would like QuickPrep to create the computer accounts. This is very useful for selective usage of computer-based Group Policy objects. After browsing the AD Structure, View automatically completed the DN (Distinguished Name), which reduces errors created by typos.


Whilst QuickPrep offers nothing like the level of sophistication that Microsoft Sysprep has, it does significantly decrease the deployment time caused by Sysprep’s Mini Installation Wizard. In the example above, we decided to create a pool of desktops for accounts, and created an OU in Active Directory called Accounts to hold the computer accounts. As you can see, QuickPrep uses the Distinguished Name (DN) format for specifying the path to the OU using a comma to separate one OU from the next, such as “OU=Accounts,OU=Virtual Desktops”.

It is also possible to call Power-off and Post-synchronization scripts for any additional desktop preparation work that needs to be carried out before the users access their desktops.

Once you click finish in the wizard, the deployment will begin. The process starts by creating a folder in Virtual Machines and Templates named after the unique ID for the pool – in our case this was AccountsGroupWin7. This holds the linked clones:


In the main Hosts and Clusters view you will see a “replica” VM. The Replica does take some time to be created, however, once completed you will find the system will very quickly begin to create your virtual desktops in the folder you selected with the wizard. One interesting aspect of the Replica and its linked clones is that it cannot and should not be deleted manually from vCenter. They can only be deleted by deleting the linked clone desktop pool in the View admin page. These objects are marked as being protected in this way to prevent accidental deletion of the source of the linked clones. If the Replica were deleted accidentally, the linked clones would be orphaned from the system. The Replicas are not given especially friendly names as you can see:


The vCenter Environment after using Linked Clones

In this section, we want to tie up some loose ends in terms of the changes created by View Composer and the Linked Clones feature. We are firm believers in mapping abstract concepts to something tangible that you can see on screen. Most people learn by doing and seeing, rather than just listening to dry and abstract explanations based on pure theory! If we use the datastore browser to examine the location selected for the virtual desktop (in our case we selected virtualmachines), you can see that each of the linked clones’ delta virtual disks takes up a very small amount of space. As you can see, the linked clone called acctsdesktop2 is only using 32MB of data; in fact its virtual machine swap file is larger than the virtual disk containing the desktop. Similarly, the virtual disk which holds the Persistent Data Disk on the virtualmachines VMFS volume is very small indeed, in this case around 30-50 MB in size.

Finally, in Active Directory, because we set appropriate values for QuickPrep, the OU called Accounts has been populated with computer accounts valid for each virtual desktop created.

Our last screen grab below shows the OS virtual disk and Persistent Data Disk, together with SystemDisposableDisk and InternalDisk in Windows Explorer in the VM.

TIP: Occasionally, vCenter might not be available during the provisioning process, and this can cause the provisioning process to terminate unexpectedly, leaving a red X next to your pool. You can select the pool and restart the provisioning process from the status button once you have rectified your vCenter issue:

This option can be used to enabled and disable the provisioning process on demand.

Fixing Linked Clones Errors

Occasionally, the removal of a linked clone enabled pool can go wrong. When you destroy a linked clone pool it should power down all the virtual desktops, and the finally delete the replica and the VM folder that was created in the deployment process. Sadly, a small amount of the time this process may not complete correctly, and it is sometimes caused by a failure of communication between the VMware Composer service and the VMware Connection server.

Although the virtual desktops can be manually powered off, and deleted – you will find even as the administrator you will be unable to delete the replica from the system. This is because it is marked as “protected” object in the vCenter environment. The whole situation can be very frustrating! Fortunately, there is a command-line utility that can be used to both unprotect the replica and remove it. The Replicas are stored in a hidden virtual machine folder called “VMwareViewComposerReplicaFolder”. By default this folder is suppressed in the vSphere Client, but it can be made visible by changing the client options in Edit menu, Client Settings and enable the “Show View Composer virtual machines” option.

To remove orphaned replicas you can use the command sviconfig, and you will find it in C:\Program Files (x86). The full command is documented in this KB article –

Below is a sample syntax.

Sviconfig -operation=unprotectentity -VcUrl=https://localhost/sdk -Username=corp\administrator -Password=vmware -InventoryPath=”/NYC DataCenter/vm/VMwareViewComposerReplicaFolder/replica-22bdbbed-fd79-45a1-b454-69be7ccc637b” -Recursive=true

TIP: We would use cut and paste to get hold of the long replica-NNNN value rather than typing it in manually. The successful out come of this command will result in an output like this:

Once this command has been run you will be able to manually delete the replica, and the other components that make up the linked clone desktop pools. In addition to this we have sometimes found that linked cloned virtual desktop pools hang about in the web administration pages. They seem to hang in a (deleting…) process and won’t complete. Normally, you can just click the refresh button in View, and then this entry will be removed – but sometimes it just appears to get stuck as process.

Restarting and rebooting the Connection Server does not fix this. We have however had some success with the new PowerCLI snap-ins. The new PowerCLI snap-ins contains a remove-pool cmdlets that can be used to remove desktop pools based on their Pool-ID parameter.

Remove-Pool -pool_id SalesWin7Desktop


In this chapter we have covered View Composer and the use of linked clones, this is one of the main features with VMware View, once you get a good grasp on linked clones you will be able to understand how you can use them within your View Infrastructure and start to get an idea of how many pools you will require for your different users. In the next chapter we are going to continue along the path of linked clones and cover the management aspects of linked clones including refresh, recompose and rebalance.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s