Storage consumption and files created when provisioning VMware View 5.0 Linked Clones

I’ve been meaning to write a post about the storage consumption and files created when provisioning VMware View linked clones as I’ve always had problems remembering exactly what operations are ran and what files were created so this post serves to be a reminder for myself and others who may be looking for information about what goes on behind the scenes.

Note that this post will not go into the arithmetic calculations required because Andre Leibovici has made a great calculator available here: http://myvirtualcloud.net/?page_id=1076, this post will focus more on demonstrating the files that are created and how they behave. 

I find the best way in explaining / demonstrating storage consumption is by looking the process of how linked clones are deployed and how the settings affect the space consumption on the LUNs provisioned for it.

Before we start, let’s look at the master image we’ll be using:

Operating System: Windows 7 64-bit
Hard Disk: 24GB
Hard Disk Provisioning Type (master image operating system): Thick

To deploy a linked clone pool, begin by selecting the Add Pool option that launches a wizard and select Automated Pool:

Whether the User assignment is Dedicated or Floating doesn’t matter:

The first configuration that would affect the amount of space required for your linked-clone pool is the persistent and non persistent disks used for redirecting the Windows profile and the disposable files:

How big you want your persistent disk to be for redirecting profiles would depend heavily on your Active Directory domain environment so in an environment where you don’t use Active Directory to redirect profiles via GPOs, your persistent disk would most likely be bigger.  For this example, I’ve set the disk size to 10GB so if I were to have 50 virtual desktops, I would need to account for 50GB worth of space just for persistent disks and another 200MB for non persistent disks (4GB each):

Note that I will be changing the Max number of desktops from 1 to 2 so that a total of 2 virtual desktops will be deployed up front for this pool:

Proceed with selecting the Default image, VM folder, Host or cluster, Resource pool:

Clicking on the Browse button for the Datastore configuration will display a window with the LUNs that are presented to the cluster you’re working with:

As shown in the screenshot above, the wizard actually gives you an estimate as to how much storage, in this example, 2 virtual desktops would consume:

Data Type: Linked clones
Min Recommended (GB): 60GB
50% utilization (GB): 86GB
Max Recommended (GB): 120GB

The Min Recommended (GB): value represents the minimum amount of storage you need to provision the files required and start up these 2 virtual desktops, the 50% utilization (GB): value represents the amount of storage the 2 virtual desktops would consume and finally the Max Recommended (GB): value represents the maximum amount of storage the 2 virtual desktops would consume.  It’s important to note that the estimates take into the account of the replica that needs to be created for the 2 virtual desktops to be used so the files included into the calculations are not only the files of the virtual desktops. Andre Leibovici does a great job of explaining this here:  http://myvirtualcloud.net/?p=1222.  We’ll have a better idea about the files later on in this post when I show what files are created.

Once you select the datastore that you intend on using for your virtual desktops, you also notice that options for the Storage Overcommit becomes accessible and the default is set to Conservation:

The available options for Storage Overcommit are as follows:

• None
• Conservative
• Moderate
• Aggressive

I won’t get too deep into what Storage Overcommit is for but generally speaking, it’s a way to allow VMware View to cram more virtual desktops into a LUN even though the virtual desktops can grow to a size that exceeds the LUN.  See page 104 in the following VMware View Administration guide for more information:

http://pubs.vmware.com/view-51/topic/com.vmware.ICbase/PDF/view-51-administration.pdf

Once you complete the steps during the wizard for the linked clone pools:

… you’ll immediately notice that vCenter will begin creating a replica by cloning your master image:

You will also notice that a virtual machine named replica with a unique identifier created within your vCenter datacenter:

If you navigate to the datastore you selected for the virtual desktops, you should also see a folder created for this replica:

Opening the replica folder will show that the replica is just as the name suggests, a clone of your master image that is used as the base disk (operating system) that all of your virtual desktops will use:

Shortly after the replica gets created, you should then see the virtual desktops created:

Navigating over to the datastore that you selected for the virtual desktops will show corresponding folders created:

Note the following disks that are created:

Disposable Disk – TestVDI001-vdm-disposable-8bc1a426-7544…vmdk

The disposable disk is the disk that stores temporary Windows operating system files (i.e. page files) that are removed when the virtual desktop is powered off.

Persistent Disk - TestVDI001-vdm-user-disk-D--8bc1a426-7544…vmdk

The persistent disk is used for storing user profile specific information (i.e. C:\Users\<userName>) so when desktops are recomposed, the user’s experience and settings does not change.

Delta Disk – TestVDI001-000001.vmdk

The delta disk is used for storing any changes made to the base disk and has the potential to grow to the size of the base disk (in this example, 24GB).  I will demonstrate the change in file size by copying a file to the local C drive a bit later.

Internal Disk – TestVDI0011-internal.vmdk

The internal disk is used to store the computer account password used for the domain as well as sysprep or quickprep files.

Delta Disk - Changes to the Local C drive

To demonstrate the functionality of the delta disk, let’s review the size of the delta disk:

TestVDI001-00001.vmdk – 12,405.50 KB

… then log into the newly deployed desktop:

Note that the virtual desktop’s C drive currently has 7.21GB of free space with a capacity of 23.8GB:

What we’ll do now is copy a 1,166,145 KB (1.1GB) file from a file server over to the C drive:

Once the file copy has completed, note the change in size to the delta file:

TestVDI001-00001.vmdk – 1,431,533.00 KB

Delta Disk - Refresh Operation

Now if we proceed with a refresh operation:

VMware View revert to a snapshot and some of the information in the internal disk to revert the virtual desktop to the original state (the configured snapshot of the master image):

Once the refresh operating completes, you should now see a new delta disk created with the next number (in this example: TestVDI001-00002.vmdk) that is similar to the original size prior to make any changes to the guest OS’ disk:

Recompose Operation

Recomposing virtual desktops allow administrators to either revert back to a previous state of the master image or roll forward to a modified state through the use of snapshots.  Lets now look at what happens during a recompose operation:

For the purpose of this example, we’ll only be recomposing 1 of the 2 virtual desktops.  The original virtual desktop was recomposed with the snapshot May 14 while the new snapshot we’ll be rolling forward is named March 16 (sorry about the typo, I meant to type May 14):

You will notice that when you kick off a recompose operation with a new snapshot, a Copy file operation is shown within vCenter:

What this operation does is actually copy the disposable disk file in the virtual desktop’s /sdd folder into the root:

Note: I haven’t been able to find any clear documentation about why an extra copy of the disposable disk is stored in a sub /sdd folder but seeing that the smaller file size of the copy in the /sdd folder compared to the root, my guess is that when the desktop gets recomposed, VMware View copies a fresh disposable disk to the root folder.

Once the disposable disk is copied, a revert snapshot operation is ran:

… and VMware View then proceeds to re-clone the master image with the updated snapshot to a new replica:

Note that the new replica has a new unique identifier:

Once the desktops have been successfully recomposed, you’ll notice that 2 replicas are now stored in the datastore you’re using for the virtual desktops:

The reason why we’re seeing 2 replicas is because we have only recomposed 1 of the 2 desktops within the pool.  Since the 2nd desktop is still using the old base disk image, the old replica must be kept.  If we proceed to recompose the 2nd desktop with the new snapshot, VMware View will delete the old replica since it is no longer used:

Hope this post helps anyone out there who may be looking for more information about the provisioning process of VMware View’s linked clones.