posted

3 Comments

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

About the Author

Cormac Hogan

Cormac Hogan is a Senior Staff Engineer in the Office of the CTO in the Storage and Availability Business Unit (SABU) at VMware. He has been with VMware since April 2005 and has previously held roles in VMware’s Technical Marketing and Technical Support organizations. He has written a number of storage related white papers and have given numerous presentations on storage best practices and vSphere storage features. He is also the co-author of the “Essential Virtual SAN” book published by VMware Press.