As the title suggests, this is the second blog post on how VMware is using linked clones in its products. The first blog, found here, covers how linked clones are used for fast provisioning in vCloud Director 1.5. This post will focus on how linked clones are used with provisioning desktops in VMware View 5.0, VMware's VDI product.
To recap, a linked clone is a duplicate of a virtual machine that uses the same base disk as the original, with a chain of delta disks to track the differences between the original and the clone.
Before you can begin to use linked clones in VMware View 5.0, you must first of all identify a Virtual Machine running an appropriate Guest OS (e.g. Windows 7 or XP) and install the VMware View Agent on that VM (the steps are beyond the scope of this post). You then need to power down the VM and create a VM snapshot. If you recollect from the previous post, only VMs which have snapshots can be used for link clones. In this example, I have a Windows XP VM which I will be using for the desktops that view will deploy.
So far, there is nothing that unusual about the disks or snapshots associated with this VM. In the VM home folder, there are two VMDKs; one is the original base disk and the other is the snapshot which I just created:
With the snapshot now taken, the next step is to create a Desktop Pool in the VMware View Administrator. I'm sure you can appreciate that there a considerable number of additional configuration steps required to get to this point, but these are beyond the scope of this post as I simply want to show you how linked clones are used.
In VMware View Administrator, select the Pools object under Inventory and then click the 'Add' button to launch the Add Pool wizard:
When you get to the vCenter Server part of the Pool Definition, there is an option to select Full Virtual Machines or View Composer linked clones. Obviously View Composer (another component of the VMware View Product) needs to be installed before you can select this option.
Later on in the Add Pool wizard, you will need to select a base desktop image for the parent VM, and this is where you would select the pre-prepared VM with snapshot that was previously setup:
After selecting the VM, you will then be prompted to select a snapshot associated with that VM (again, we set this up earlier on):
Once all the steps have been complete, and the pool is created, a new task begins in vCenter which clones the desktop base disk to a replica VM:
Once the replica is created, the creation of the XP desktops can begin. In my setup I asked View to make sure that my VMs are always powered on – this is why you see them deploying automatically. This speeds up end-user access to the VM:
The desktops are in fact made up of a number of different disks, but the disk used for the Guest OS is a linked clone created from the replica VM. Now you might ask why do we bother going through the process of cloning our original base disk into this replica disk before deploying the linked clones. The reason is simple – the replica is a thin provisioned version of the original base disk. By doing this step, we guarantee space savings on disk.
Let's take a look at this replica VM, and then one of my desktop VMs, first via the UI and then via the CLI. First thing I notice is that my replica VM has a snapshot:
If you remember, we need to make sure the base disk has a snapshot in order to create linked clones. If I look at my desktop VM, it also has a snapshot associated with it.
Why does my desktop VM need a snapshot? Well, View is quite powerful in what it can do with these desktops, and a snapshot is taken so that certain operation can be done which involve reverting the desktop's OS disk rather than redeploying a new one.
It appears, that we have a delta disk (linked clone), a snapshot of the delta disk (vdm-initial-checkpoint) snapshot observed previously, and internal disk and a disposable disk. The disposable disk contains temporary files that are deleted when the virtual desktop is powered off, such as Windows temp files. The internal disk stores the computer account password to ensure connectivity to the domain when a desktop is refreshed. Additionally, the configuration for Quickprep and Sysprep are stored in this disk.
The delta disk (our linked clone) is where the Guest OS resides. Let's examine that in more detail:
As can be clearly seen, this linked clone points back to the replica VMDK, which is a clone of our original base disk. Let's just check the metadata file of that replica disk as a final step:
If you compare this to the original XP VM that I used for my base disk, you'll see that this replica is identical in every characteristic except for one; the replica is thin provisioned so that it is space efficient.
That concludes the post. Hopefully you'll see how linked clones are used in VMware View to facilitate speed of deployment and space efficiency over standard cloning mechanisms.
Obviously a number of VMware View fundamentals were glossed over in this posting to show you the link clones. If you want to know more about the various operations that can be done such as refresh/recompose, this KB article does a pretty decent job. For more information about the various disks (internal, disposable, etc), this blog post does an excellent job. Finally, if you are considering deploying VMware View in your own lab for a Proof-Of-Concept, this blog post provides super step-by-step instructions.
Get notification of these blogs postings and more VMware Storage information by following me on Twitter: @VMwareStorage
