Pages

Saturday, May 26, 2012

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

image

image

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

image

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

image

image

image

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:

image

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):

image

image

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:

image

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

image

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:

image

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

image

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:

image

The available options for Storage Overcommit are as follows:

  • None
  • Conservative
  • Moderate
  • Aggressive

image

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:

image

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

image

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

image

image

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

image

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:

image

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

image

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

image

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.

image

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.

image

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.

image

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.

image

image

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

image

… then log into the newly deployed desktop:

image

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

image

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

image

image

image

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

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

image

Delta Disk - Refresh Operation

Now if we proceed with a refresh operation:

image

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):

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:

image

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:

image

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):

image

image

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

image

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

image

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:

image

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

image

Note that the new replica has a new unique identifier:

image

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:

image

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:

image

image

image

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

1 comment:

Anonymous said...

hi Terence,
Here's Shady from Egypt.
Although this may be late, but I found that the Disposable vmdk file in SDD folder is the original one created with the VM. It'll be used in Refresh oeprations to revert the other Disposable disk (under VM directory directly and the one that grow bigger with usage of VM) to its original state.
I hope this helps.