VDI – vVol Linked Clones

Many enterprise customers use at least part of their infrastructure to host VDI environments or virtual desktops. Even at Dell I can order up one of these desktops through a self-service catalog if the need arises. I’ve seen a variety of different types of VDI implementations from NFS to FC, sometimes on a small dedicated array, other times as a carved out portion of a larger array like PowerMax. As VMware continues to push into the virtual volume space, I imagine VDI environments on vVols might become more common. As both PowerFlex and PowerMax support vVols, either could be used with this process. Just a reminder that PowerFlex does not support vVols in version 4.x.

Clones for VDI

The three basic VDI clones are:

  • Full clones
  • Linked clones
  • Instant clones

Since full clones are self-explanatory, and vVols do not support instant clones, I’m going to look at linked clones.

Linked clone

A linked clone is created by creating a new VM off a snapshot of a source VM. While the new VM creates a copy of the source VM in terms of disk/memory, it takes up no space because it points back to the source snapshot. When a write is performed on the clone, at that point the changed data is written to the vVols of the cloned VM. In other words, if data is only be viewed on the clone, very few allocations will occur (e.g., OS event logs).


First, we start with a source VM named vVol_LinkedClone_Source. In this example I am using a PowerMax as backend storage as I don’t have vVols setup on my PowerFlex, but as I noted either array could be used (or others). The VM is Windows OS which is the most common for VDI. After preparing it, I shut it down, and took a snapshot.

The VM doesn’t have to be down for the snapshot, and you could also quiesce it, but when preparing a source VM for VDI, that is really unnecessary. So this “linkedclone” snapshot as I’ve named it is ready for VDI creation. There are different types of software that can be used to create VMs, e.g., VMware Horizon, but I’m taking the simple route of using PowerCLI since everyone has that.

Source VM allocation

Let’s look first at the amount of storage utilized by our source VM to understand how the linked clone works. Setting aside the config vVol and swap, it’s comprised of one vmdk. I was able to pull the device IDs using the method I outlined in the vVol paper you can find in the Documentation Library. Basically using the VMware integration in Unisphere you can find the WWN of each vVol and then grep for the device ID in Solutions Enabler. My device is 1001A(40GB) and the amount of storage allocation is detailed below. BTW if the numbers below got you scratching your head, remember those are tracks, so it is 327690 x 128 (track size) or 41944320 (40GB).

The C drive is 28% full. If I were to do a normal VMware clone of this VM, my cloned VM would have the exact same storage usage (let’s put aside Data Reduction for now). When I do a linked clone, however, the idea is that I am reading from the source snapshot so I would expect my vVol would be empty. Let’s find out if that’s true.


There’s nothing special about creating a linked clone – you still use the New-VM Cmdlet, just pass a parameter named LinkedClone. If you aren’t logged in to your system as an administrator, be sure to run PowerCLI as an administrator. In my command I am using a resource pool, though you could assign a host. The command would look like:

New-VM -Name LinkedClone01 -VM vVol_LinkedClone_Source -ReferenceSnapshot linkedclone -LinkedClone -ResourcePool vVol_VDI -Datastore VVOL_LINKED_CLONE

Here is the output. I’ve modified the picture just to show the progress because that goes away after it completes successfully.

Now let’s look at the storage usage of the clone to see if we are using any space:

No tracks as expected! The only time tracks will be allocated is if I write data to the linked clone. For example, if I power on the VM, Windows is going to write some information so I will see some allocations:

Any future writes will be written to this vVol. Note this is different than a VMFS linked clone which keeps delta files in the VMFS. I’m sure you can see the benefit here of the linked clone in that so much of the OS can be shared among many VMs, avoiding the duplication of data. (Yes, we could talk about Data Reduction on the PowerMax and full clones but that’s not this post.)


Besides providing the basic process, I wanted to point out that vVols are ideal for linked clones because of how it differs from VMFS. Those delta files that VMware uses for linked clones on VMFS can become a performance issue. With vVols you are writing directly to devices on the backend, not a file system, yet you retain the full benefit of thin provisioning. The only caveat is that linked clones still use space in the vVol datastore. Remember that vVols are treated as thick from a VMware perspective so when using VDI, you may have to make your storage container on the array larger than normal. This has no bearing on the storage allocations, it’s just logical space so use what you need.


Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Website Powered by WordPress.com.

Up ↑

%d bloggers like this: