مفاهیم VMware Composer و Linked Clones

At the time of writing VMware Composer and Linked Clones is incompatible with vCenter4. It was not feasible or realistic to delay the publication of this book to wait for VMware to release a new version of View that is compatible. As a consequence the following instructions were tested on Vi3.5 and should once VMware issue a new release of View 3 work in exactly the same way.
As you can see 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 make in a short period of time it can take some time to complete the build process.

With this in mind VMware View introduces 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 clone’s information comes from the read-only replica.

The difference is that rather than using the template process to create a virtual desktop – merely a “differences” or “delta” file is created. Linked Clones are called such because the “clone” is “linked” to a replica of the “Parent VM”. In this way we can massively reduce both the storage costs and deployment time significantly. Additionally, it means when we make changes to the master these are proliferated to each of the linked clones – in process VMware 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 persistent pools with linked clones the replica disk is marked as read-only, all changes that user makes are sent to operating systems delta virtual disk. Additionally, there is an option “user data disk”. This user data disk holds a local profile for the user. The user data disk is marked as being read-write – and the user is allowed to make changes to their profile and environment albeit circumscribed by your 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.

PRO+
Content
Find more PRO+ content and other member only offers, here.
E-Handbook
How GPU cards change the app game for VDI
E-Chapter
DaaS providers stack deck in their favor with SLAs
E-Handbook
How VDI shops can support cloud-hosted desktops
Such savings in space and time have been around at the storage layer for some time from such vendors as NetApp and their SnapClone and De-Duplication technology. If you have these storage technologies already you may wish to evaluate their effectiveness and cost first – before using the linked clones feature. It’s worth saying that these so called “high-level” storage features from the storage vendors are not free and often require a license to function.

Perhaps the best analogy for linked clones – is to compare its utilization of disk space to the way that ESX utilizes memory. If you recall from the performance chapters it is possible to allocate more memory to the VMs than is physical present on the ESX host. VMware call this memory overcommitment. Well, in a very similar way with View Composer we can create more virtual desktops than we have physical disk space. As with memory overcommitment, with disk commitment we must monitor very carefully the actual disk space used – and View Composer comes with built-in settings control what happens if we get close to using more disk space than we have physically available. In many respects it’s like having virtual storage on expensive array.

Finally, VMware have developed there 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 Microsoft Domain as rapidly as possible. QuickPrep uses an account in Active Directory which you have configured with rights to join computers to the domain, and pre-populates computer accounts in the domain which significant speeds up the deployment process. In addition, QuickPrep allows the administrator to specify using the Distinguished Name format (e.g. OU=Virtual Desktops, OU=Marketing) where those computer account objects will be created, thus ensuring the right Active Directory Group Policy objects are correctly applied.

For linked clones to be possible you must install the VMware View Composer Service to your vCenter server. View Composer does need a backend database and it is possible to simply create a new database on your existing database server that use to hold the other VMware databases for features like vCenter and VMware Update Manager.

Install View Composer

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

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

In the Database Information dialog, shown in Figure 1, supply your vCenter DSN Settings.
Figure 1 (click to enlarge)

Change the default port for View Composer, and allow it to generate the default certificate for it, shown in Figure 2.
Figure 2

Choose Next and Install
Enable View Composer in VMware View

Login to the Administrative web-page of the Connection Server.

Select the Configuration icon
.

Under the VirtualCenter section, select the VirtualCenter reference and click the Edit… hyperlink.

Select Enable View Composer.
Initially this connection will fail – after the failure you will be able to adjust the port number to the correct value, shown in Figure 3.

Figure 3 (click to enlarge)

Set the Service Account for View Composer, under the Domain Administrators Accounts click Add….

In the Add Administrators pop-up webpage complete the dialog box using a FQDN/DNS format for specifying the domain, as in Figure 4. Figure 4 (click to enlarge)

Prepare 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.

Login to the Parent VM.

Confirm it has successfully joined the domain.

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.

Shutdown the Parent VM.

Snapshot the Parent VM, allocating a friendly name such as Baseline Snapshot.
Create the Linked Clone Persistent Pool

In the Connection Server web admin tool select the Desktop and Pools icon.

Click the Add… link.

Select Automated Desktop Pool.

Select a Persistent pool.

Select you vCenter instance, and enable the option to Use linked Clone to create desktops in the pool, shown in Figure 5.
Figure 5 (click to enlarge)
When you select this option the explanation in the web page will change indicating that the “Offline Desktop” feature is only experimentally supported, and is current incompatible with the linked clone feature.

As before allocate a Unique ID and Display name.

In the Desktop/Pool Settings, shown in Figure 6, you should notice that the page has change slightly giving you an new option to control the Refresh OS disk on logoff feature.
Figure 6
As you might remember from the explanation of the linked clones feature – changes in the user’s desktop environment are merely “deltas” which are held in a separate virtual disk, in a very similar way to the VMware Snapshot feature. This setting controls what happens to those changes. The options are quite simple. The option “Never” means that the changes accrue over time with the delta files growing gradually larger day by day. This means the user’s environment is never reset, and you run the risk of eventually running out of disk space. The option “Always” means every time the user logs off their virtual desktop is reset back to a clean state as if they just logged in for the first time. The option “Every…” allows you to trigger a reset of the user virtual desktop at interval measured in days. Finally the At… option allows you to specify using a percentage a reset based on the size of the delta – so once the users delta drive is at 90% utilization it triggers a reset. VMware currently recommend a reset at every log off for virtual desktops that are persistent pools using the linked clone technology.

This refresh at log off causes the user virtual desktop to shutdown, and the delta virtual disks to be discard – then new delta virtual disks are created. The entire process can take some time and if user attempts log out and log in quickly they can find the virtual desktop not yet ready. If the user attempt to reconnect while this process is still ongoing they will receive a message in their client indicating their virtual desktop may not be available, as in Figure 7.

Figure 7
Personally, I’ve found users find this annoying especially as log out and log in sometime used a cure all for fixing problems in Windows. Personally, I would consider using of Never, and instead use Connection servers manual “Refresh” option which allows to you refresh the desktops at given date and time. This would allow us to refresh the virtual desktops during the evening of weekend – in such away to minimize the impact on end users.

In the Automated Provisioning page, the settings will remain very much the same. But remember because you are using linked clones, and each clone is just the changes that accrue during the use of the virtual desktop – you can create a very large number of VMs using a very small amount of storage. This means you can have very large maximum, minimum and reserve options without paying for the disk space upfront.

Next select the Parent VM you created earlier and in the subsequent window, shown in Figure 8, and select the snapshot you took after releasing the Parent VM IP address and powering it down, shown in Figure 9.
Figure 8
Figure 9 (click to enlarge)

The remaining parts of the Desktop Pools wizard remains the same from the perspective of selecting a vCenter VM folder, ESX host or Cluster location, and resource pool. After this part in the wizard you will be asked for settings for the User Data Disk, as in Figure 10.

Figure 10 (click to enlarge)
As you might recall from my description of the linked clone feature, the user data disk only functions with persistent pools that leverage the linked clone feature. The are very small virtual disks, that merely hold the user profile data of the end user – and thus relieves the administrator from the burden of Microsoft Roaming Profiles. As such the virtual disk does not have be anywhere near the size of the virtual disk that would store the operating system of the virtual desktop. The main care to be taken is making sure that the drive letter used by user data disk does not conflict with any mapped network drives the user might use. Finally, if you select the option “Use different datastores for user data drives and OS drives” this allows you in the next wizard to place the operating system delta disks and the user’s data disk in different datastores. I would not recommend the option “Store user data on the same disk as the OS” as this will significant reduce the functionality of the linked clone feature.

The last window in the wizard will allow you to choose a datastore location for both the OS delta disk and user data disk. There is quite a lot of information to digest in this page, so I want break it down piece by piece.
In Figure 11, you can see I’ve decided to locate the OS Data on a datastore called “sanlun1”, and the User data disks on the datastore called “virtualdesktops”.

Figure 11 (click to enlarge)
I was able to do this because I select the option to “Use different datastores for user data drives and OS drives” in the previous page. In the Storage Overcommit column I’m able to set what level of overcommitment I’m hoping to achieve. With linked clones it’s possible to create say 50 virtual desktops from a 10GB parent, but because the clones are merely deltas that doesn’t mean they will take up 500GB of disk space. In fact they will take up much less – what I hope it that the VMs never actually need the disk space I am assigning.

The pull-down option allow me to set aggressive, moderate and conservative as my estimate of how intensely I was to overcommit the storage used. If I select aggressive I’m indicating that I expect the delta files and the user data disk to grow in size very slowly – thus allowing me to create many virtual desktops with very little actual storage capacity. Whereas the conservative option allows me to indicate that I expect the delta and the user data disk to grow rapidly. Clearly, if I have a policy to always “Refresh OS disk at logoff” then the size of these deltas are going to 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.

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 10GB volume. This will happen if you datastores have less free space than the value represented in the “Minimum Recommended” column.

In Figure 12, I select different datastore which clearly have insufficient space for the volume of VMs I am creating despite the space saving power of linked clones.

Figure 12 (click to enlarge)

Finally, you will able to specify option for VMware QuickPrep, as shown in Figure 13.
Figure 13 (click to enlarge)
Whilst QuickPrep offers nothing like the level of sophistication that Microsoft Sysprep it does significant decrease the deployment time caused by Sysprep’s “Mini Installation Wizard”. In the example above I decided to create a pool of desktops for marketing, and created an OU in Active Directory called “Marketing” 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=Virtual Desktops, OU=Marketing.

Once you click finish in the wizard the deployment will begin. The process starts by creating a folder in Virtual Machines and Templates called “VMwareViewComposerReplicaFolder”. This folder holds the “Replica” and “Source” data to which the linked clones will point. The Replica and Source do take some time to be created, however, once completed you will find the system will very quick begin to create your virtual desktops in the folder you selected during the wizard.

One interesting aspect of the VMwareViewComposerReplicaFolder, Replica and Source objects – is that cannot 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 and Source were deleted the linked clones would be orphaned from the system. The Replica and Source are not given especially friendly names.

The vCenter Environment after using Linked Clones
In the section I just want to very quickly tie up some loose ends in terms to the changes created by View Composer and the Linked Clones feature. I firm believer in mapping abstract concepts to something tangible that you can see on screen. Most people learn by doing and seeing – rather than just dry and abstract explanations based on pure theory.

In Figure 14, you can see that the system is still busy in creating my “marketing” desktops.

Figure 14 (click to enlarge)
I actually asked for a maximum of 50 desktops in the pool, with minimum of 25 and reserve of 10. Notice how it created a VM folder called marketing, and Replica and Source in the VMwareViewComposerReplicaFolder. View composer appends a unique string to the end of the Replica and Source so they can be unique tied to the clones (marketing1, marketing2 and so on) that have been created.

If I use the data store browser to examine the location selected for the OS data — in my case I selected sanlun1 — you can see in Figure 15 that each of the linked clones delta virtual disks take up a very small amount of space.

Figure 15 (click to enlarge)
As you can see, the linked clone called marketing1 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 User Data Disk on the “virtualdesktops” VMFS volume are very small indeed, in this case around 26MB in size, shown in Figure 16.

Figure 16 (click to enlarge)
Finally, in Active Directory – because I set appropriate values for QuickPrep – the OU called “marketing” has been populated with computer accounts valid for each virtual desktop created, shown in Figure 17.

Figure 17 (click to enlarge)
Figure 18 shows the OS virtual disk and User Data Disk together in Windows Explorer.

Figure 18 (click to enlarge)
In the next section, learn more about VMWare Composer and Linked Clones.