Home > Blogs > VMware vSphere Blog > Tag Archives: linked clone

Tag Archives: linked clone

Linked Clones Part 2 – Desktop Provisioning in VMware View 5.0

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:

 # ls
COR-XP-PRO-000001-delta.vmdk
COR-XP-PRO-000001.vmdk
COR-XP-PRO-Snapshot1.vmsn
COR-XP-PRO-flat.vmdk
COR-XP-PRO.nvram
COR-XP-PRO.vmdk
COR-XP-PRO.vmsd
COR-XP-PRO.vmx
COR-XP-PRO.vmxf
vmware-1.log
vmware-2.log
vmware.log

Let's look at the metadata of the base disk. It appears that it is thick provisioned VMDK:

# cat COR-XP-PRO.vmdk
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=ceddb0f6
parentCID=ffffffff
isNativeSnapshot="no"
createType="vmfs"

# Extent description
RW 41943040 VMFS "COR-XP-PRO-flat.vmdk"

# The Disk Data Base
#DDB

ddb.deletable = "true"
ddb.toolsVersion = "8384"
ddb.virtualHWVersion = "8"
ddb.longContentID = "caae51e530f31cb41e9d0bc0ceddb0f6"
ddb.uuid = "60 00 C2 96 98 85 58 13-6b 06 53 2d a9 54 70 ae"
ddb.geometry.cylinders = "16383"
ddb.geometry.heads = "16"
ddb.geometry.sectors = "63"
ddb.adapterType = "ide"

While we're at it, we may as well check the snapshot. Nothing out of the ordinary either:

# cat COR-XP-PRO-000001.vmdk
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=ceddb0f6
parentCID=ceddb0f6
isNativeSnapshot="no"
createType="vmfsSparse"
parentFileNameHint="COR-XP-PRO.vmdk"
# Extent description
RW 41943040 VMFSSPARSE "COR-XP-PRO-000001-delta.vmdk"

# The Disk Data Base
#DDB

ddb.longContentID = "caae51e530f31cb41e9d0bc0ceddb0f6"
#

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.

Let's first look at the desktop VM's disks:

# ls *.vmdk
XP-Desktop-01-000001-delta.vmdk
XP-Desktop-01-000001.vmdk
XP-Desktop-01-delta.vmdk
XP-Desktop-01-vdm-disposable-e12b58f4-a196-4dbf-874b-607d6d8a51a6-flat.vmdk
XP-Desktop-01-vdm-disposable-e12b58f4-a196-4dbf-874b-607d6d8a51a6.vmdk
XP-Desktop-01.vmdk
XP-Desktop-011-internal-flat.vmdk
XP-Desktop-011-internal.vmdk

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:

# cat XP-Desktop-01.vmdk
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=4ac637ed
parentCID=ceddb0f6
isNativeSnapshot="no"
createType="vmfsSparse"
parentFileNameHint="/vmfs/volumes/7440912b-553c8e52/replica-c6e388c7-1a23-41d3-a264-0292fe29eb1f/replica-c6e388c7-1a23-41d3-a264-0292fe29eb1f.vmdk"
# Extent description
RW 41943040 VMFSSPARSE "XP-Desktop-01-delta.vmdk"

# The Disk Data Base
#DDB

ddb.longContentID = "5d89a2289098fd1e98a7f74c4ac637ed"

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:

# cat replica-c6e388c7-1a23-41d3-a264-0292fe29eb1f.vmdk
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=ceddb0f6
parentCID=ffffffff
isNativeSnapshot="no"
createType="vmfs"

# Extent description
RW 41943040 VMFS "replica-c6e388c7-1a23-41d3-a264-0292fe29eb1f-flat.vmdk"

# The Disk Data Base
#DDB

ddb.adapterType = "ide"
ddb.thinProvisioned = "1"
ddb.geometry.sectors = "63"
ddb.geometry.heads = "16"
ddb.geometry.cylinders = "16383"
ddb.uuid = "60 00 C2 93 22 40 a1 6d-1a 9d ca a9 4b a1 26 ff"
ddb.longContentID = "caae51e530f31cb41e9d0bc0ceddb0f6"
ddb.deletable = "false"
ddb.toolsVersion = "8384"
ddb.virtualHWVersion = "8"

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: Twitter @VMwareStorage

Linked Clones Part 1 – Fast Provisioning in vCloud Director 1.5

This is the first part of two posts that I plan to do on linked clones. 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.

Linked clones have been in vSphere for some time now, but since they are not a feature that can be created, configured or deployed from the vSphere client or ESXi CLI, they do not get a great deal of exposure.

This first post is related to the new Fast Provisioning feature in vCloud Director 1.5. This new feature uses linked clones. In previous versions on vCloud Director, the adding of a vApp Template (containing 1 or more Virtual Machines) to a cloud was a clone operation. This was quite time consuming depending on the number of VMs in the vApp Template. It also consumed quite a bit of disk space. Fast provisioning saves time & space by using linked clones for virtual machine provisioning operations.

In this post, we are using vCenter 5.0 and ESXi 5.0 hosts. When you create an Organization vDC within vCloud Director, one of the configuration settings is whether or not you will use Thin Provisioning (disabled by default) and Fast Provisioning (enabled by default) on the Virtual Machines that you deploy to your Cloud. If fast provisioning is disabled, all provisioning operations result in full clones. Also, if the provider vDC on which the organization vDC is based contains ESX/ESXi 4.x hosts, you must disable fast provisioning.

Once the Org vDC has been created (along with a number of other configuration tasks which are beyond the scope of this article), you can now being to populate your catalog with vApp Templates (containing 1 or more VMs). In this example, I imported a single Virtual Machine which already existed on my vCenter server. This VM is added to a new vApp Template in my catalog:

While this import process is taking place, I can examine what is happening from a vSphere perspective by looking at the VMs and Templates view in vCenter:

At this point, once the import completes, I now have a single vApp Template in my catalog. This is a standard VM with a thick VMDK disk. On my datastore,  I see a standard VM with a thick disk in the VM’s home folder (no snapshots, no linked clones): 

# cat Windows-2003-Template\ \(1321ef9a-8bb0-484e-943c-bfcc4da1cdef\).vmdk

# Disk DescriptorFile
version=1
encoding=”UTF-8″
CID=58738f2e
parentCID=ffffffff
isNativeSnapshot=”no”
createType=”vmfs”

# Extent description
RW 33554432 VMFS “Windows-2003-Template (1321ef9a-8bb0-484e-943c-bfcc4da1cdef)-flat.vmdk”

# The Disk Data Base
#DDB
ddb.deletable = “true”
ddb.toolsVersion = “8384″
ddb.virtualHWVersion = “8″
ddb.longContentID = “5b769d2faa3921485dbe93e058738f2e”
ddb.uuid = “60 00 C2 9a 1f f7 f1 1d-ae 9f fd a7 49 16 7d c9″
ddb.geometry.cylinders = “2088″
ddb.geometry.heads = “255″
ddb.geometry.sectors = “63″
ddb.adapterType = “lsilogic”

If I had included the option ‘Thin Provisioned’, the VMDK would be slightly different:

 

The VMDK metadata file for the VM would reflect that this is a thin disk:

# Disk DescriptorFile
version=1
encoding=”UTF-8″
CID=fffffffe
parentCID=ffffffff
isNativeSnapshot=”no”
createType=”vmfs”

# Extent description
RW 33554432 VMFS “Win-2003-Thin (c65a5956-0e41-4cc1-a588-728adaba71ca)-flat.vmdk”

# The Disk Data Base
#DDB

ddb.deletable = “true”
ddb.toolsVersion = “8384″
ddb.virtualHWVersion = “8″
ddb.longContentID = “5b769d2faa3921485dbe93e058738f2e”
ddb.uuid = “60 00 C2 91 4c 6f ec fa-37 48 cb c0 46 e1 2c 98″
ddb.geometry.cylinders = “2088″
ddb.geometry.heads = “255″
ddb.geometry.sectors = “63″
ddb.thinProvisioned = “1″
ddb.adapterType = “lsilogic”

Now that I have successfully added the VM to a vApp Template to my catalog, the next step is to add the vApp to My Cloud.

After populating the appropriate VM & network info (outside the scope of this blog), the vApp (and the VMs contained within that vApp) begin to deploy:

Once this ‘Add to My Cloud’ operation is initiated,  the first thing that I noticed is that the VM within the vApp Template now has a snapshot:

The metadata for this snapshot contains the following information:

# Disk DescriptorFile
version=1
encoding=”UTF-8″
CID=58738f2e
parentCID=58738f2e
isNativeSnapshot=”no”
createType=”vmfsSparse”
parentFileNameHint=”Windows-2003-Template (1321ef9a-8bb0-484e-943c-bfcc4da1cdef).vmdk”
# Extent description
RW 33554432 VMFSSPARSE “Windows-2003-Template (1321ef9a-8bb0-484e-943c-bfcc4da1cdef)-000001-delta.vmdk”

# The Disk Data Base
#DDB

ddb.longContentID = “5b769d2faa3921485dbe93e058738f2e”

Why do we need this snapshot? Linked clones can only be created against base disks that have snapshots. This snapshot makes sure that no linked clones do anything to the original base disk.

The second thing I notice from the ‘Add to My Cloud’ operation is that there is a new folder created in the vCenter “VMs & Templates” Inventory. This is my instantiated vApp from the vApp Template and it has its own Windows-2003-Template VM deployed:

 

Let’s look at this VM (part of the newly instantiated vApp) in more detail. The first thing you will notice is that this VM only has a single delta disk:

# ls
Windows-2003-Template (9b0e78eb-bf82-4c7c-94e7-c35a4ddbf523)-delta.vmdk
Windows-2003-Template (9b0e78eb-bf82-4c7c-94e7-c35a4ddbf523).nvram
Windows-2003-Template (9b0e78eb-bf82-4c7c-94e7-c35a4ddbf523).vmdk
Windows-2003-Template (9b0e78eb-bf82-4c7c-94e7-c35a4ddbf523).vmsd
Windows-2003-Template (9b0e78eb-bf82-4c7c-94e7-c35a4ddbf523).vmx
Windows-2003-Template (9b0e78eb-bf82-4c7c-94e7-c35a4ddbf523).vmxf
vmware-1.log
vmware-2.log
vmware-3.log
vmware.log

And if we examine the metadata for that delta VMDK, we can see that this delta points back to the original base disk of the vApp Template:

# cat Windows-2003-Template\ \(9b0e78eb-bf82-4c7c-94e7-c35a4ddbf523\).vmdk

# Disk DescriptorFile
version=1
encoding=”UTF-8″
CID=58738f2e
parentCID=58738f2e
isNativeSnapshot=”no”
createType=”vmfsSparse”
parentFileNameHint=”/vmfs/volumes/edcbc280-4dc07457/Windows-2003-Template (1321ef9a-8bb0-484e-943c-bfcc4da1cdef)/Windows-2003-Template (1321ef9a-8bb0-484e-943c-bfcc4da1cdef).vmdk”
# Extent description
RW 33554432 VMFSSPARSE “Windows-2003-Template (9b0e78eb-bf82-4c7c-94e7-c35a4ddbf523)-delta.vmdk”

# The Disk Data Base
#DDB

ddb.longContentID = “5b769d2faa3921485dbe93e058738f2e”

This is a linked clone. Any future vApps instantiated from the vApp Template in my catalog will also use linked clones but on a new chain.

That pretty much concludes the post. Hopefully it has given you some idea of how vCloud Director 1.5 now uses linked clones for faster deployments of VMs, as well as saving disk space by avoiding complete clones of VMs from a vApp Template.

There is one other feature in vCloud Director 1.5 that I want to bring to your attention. Linked clones cannot span vCenter datacenters or datastores. Therefore a new feature called shadow virtual machines was introduced to address this restriction. Shadow virtual machines support linked clones of virtual machines that are associated with vApp templates across vCenter datacenters and datastores. A shadow virtual machine is an exact copy of the original virtual machine that vCloud Director creates on the datacenter and datastore where a linked clone is created. My understanding is that shadow VMs will be used when a datastore containing the base disk and linked clones starts to run out of space or when the linked clone chain length becomes too large. There may be other reasons but these are the two I am aware of.

I shortly plan to follow up this post with a look at how linked clones are used in another VMware product, namely VMware View.

Get notification of these blogs postings and more VMware Storage information by following me on Twitter: Twitter @VMwareStorage