Storage consumption when provisioning Citrix XenDesktop 5.6 with personal vDisks (PvD) with MCS (Machine Creation Services)

I’ve been asked several times about the differences between Citrix’s XenDesktop 5.x pooled desktop catalogs and VMware View 5.x linked-clones with respect to the differences in the consumption of storage.  While I have yet to find the time to write up a post about VMware View’s provisioning process, I figure I’ll write this post about XenDesktop first because I’ve been working with the product all weekend and have access to some a few environments to capture some screenshots.  First off, Daniel who is a lead architect at Citrix has a great write up here:  http://blogs.citrix.com/2011/06/28/machine-creation-services-primer-part-1/.  The write up does not include PvD disks but nonetheless provides a great explanation of what happens during the provisioning process.  This post will not to into as much detail to differentiate between what automatically and what manually happens but rather show what folders and files are created.

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

Operating System: Windows 7 64-bit
Hard Disk: 40GB
Hard Disk Provisioning Type (master image operating system): Thin
End-user personal vDisk: 10GB
LUN(s) for desktop catalog (Virtual machine storage):  VMFS11_R10_FC
LUN(s) for PvD (Personal vDisk storage):  VMFS13CTX

Here is the master image’s properties:

As written above, we’re going to spread the virtual machines desktops in the desktop catalogs onto 2 separate stores as well as use a dedicated LUN for the PvDs:

The master image’s single primary operating system disk is thin-provisioned:

Size: 16,069,630.00K

Provisioned Size:  41,943,040.00KB

We’ll begin by creating a new catalog in desktop studio:

Create the machine type Pooled with personal vDisk:

Select the snapshot for the master image:

Leave the Total size of end-user personal vDisk as 10GB:

Complete the desktop catalog creation:

Note that as soon as the desktop catalog deployment begins, you’ll see 2 virtual machines built:

1. Win7Test_Datacenter_01-baseDisk-datastore-309
2. XD-Temp-4/15/2012 7:09:56 PM-6423fb95-d7e0-43d7-b6f8-97ea4d0cb21d

The Win7Test_Datacenter_01-baseDisk-datastore-309 virtual machine represents the base disk (vmdk) that your virtual desktops in the desktop catalog will use while the XD-Temp-4/15/2012 7:09:56 PM-6423fb95-d7e0-43d7-b6f8-97ea4d0cb21d the virtual machine that temporarily stores the:

• vmx
• vmxf
• vmsd

… files during cloning process and will ultimately be removed (after the files are copied out):

Note the small size of the XD-Temp disk (sorry about the screenshot as I realized I didn’t expand the column wide enough to show the extensions so I created another pool afterwards to show this:

Note the identical size of the base disk and your original master image’s operating system disk:

The process first creates the temporary virtual machines for both the virtual machine metadata files and another virtual machine for the actual base disk:

Once the virtual machine metadata files are created, that virtual machine gets “reconfigured” to have the folder and files renamed from the XD-Temp-xxxxxxx… name to something more similar to the base disk virtual machine:

Win7Test_Datacenter_01-baseDisk-25b42a63-5733-4019-923-8ac741bf972b

Also note that the virtual machine will get deleted but the data files will remain in the store.

Once the base disk is successfully cloned, the virtual machine will get “reconfigured” and then deleted:

What the XenDesktop DDC will then do is create the virtual desktops and copy the vmx, vmxf and vmsd disk into the folder then create an unique identity disk (vmdk file) sized at 16MB used to provide each VM with a unique identity as well as the nvram and .log files you normally see for virtual desktops:

What you’ll quickly notice is that the virtual desktop’s folder does not contain any large vmdk file that represents the disk with the operating system and this is because that is stored in one folder shared amongst all of the other virtual desktops in the desktop catalog:

If you proceed with comparing disk 1 of 3 for 2 of your virtual desktops in your desktop catalog pool, you’ll see that disk one represents your operating system 40GB disk:

Win7Test001 Disk 1 path:

[VMFS12_R10_NL_THIN] Win7Test_Datacenter_01-baseDisk-datastore-1304/Win7Test_BHB_Datacenter_01-baseDisk-datastore-1304.vmdk

Win7Test001 Disk 2 path:

[VMFS12_R10_NL_THIN] Win7Test_Datacenter_01-baseDisk-datastore-1304/Win7Test_BHB_Datacenter_01-baseDisk-datastore-1304.vmdk

Disk 2 of 3 will represent the identity disk (I won’t add the screenshot for the 2nd virtual desktop but it also has this identity disk in the virtual desktop’s own folder):

[VMFS12_R10_NL_THIN] Win7Test001/Win7Test001_IdentityDisk.vmdk

Note that the identity disk is thick provisioned:

Disk 3 of 3 will contain the personal vDisk vmdk file which in this case is stored on a different LUN:

[VMFS13CTX_R5_NL_THIN] Win7Test001/Win7Test001_pvdisk.vmdk

Note that the PvD for each virtual desktop is thin provisioned:

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

Before I continue, it’s important to note that because I’ve only selected 1 LUN for storing the virtual machine storage, the base disk and the virtual machine files will be stored in only 1 LUN.  If we were to select 2 or more LUNs for the virtual machine storage, we’ll the base disk folder along with the vmdk file stored onto each LUN.  This is important to note because every LUN you use for your desktop pool will mean extra consumption in storage.  A master image with a base disk consuming 16GB of space spread across multiple LUNs will mean 16GB of space will be consumed on all of the LUNs.

As an example, if we originally selected 2 LUNs for storage:

We’ll get the first virtual desktop on the first LUN and the second desktop on the second LUN.  If we add another desktop to the desktop catalog, the third desktop will be stored on the first LUN.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

With 2 virtual desktops provisioned, if we proceed with adding another virtual machine to the desktop catalog:

We’ll notice that nothing much appears to happen in the task window of the vCenter:

… and that the provisioning process is extremely fast.  The reason for this is because only the virtual machine metadata files need to be copied and there is no base disk image to clone since it already exists on all of the LUNs.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

Reviewing the provisioning process shown above, some of the important takeaways I would ensure is taken into consideration during the sizing of LUNs are as follows:

1. If you choose to use several LUNs for your virtual machines files, note that you’ll be consuming storage for the base disk on each LUN.
2. PvDs are thin provisioned disk to be aware that the storage consumed on a LUN storing only PvDs may continue to grow even if you don’t add any more PvDs to it.
3. Note that if your master image’s operating system disk is thin provisioned, your base disk image disk will also be thin provisioned.  If your mater image’s operating system disk is thick provisioned, your base disk image disk will also be thick provisioned.
4. What’s interesting that each virtual desktop gets a difference disk that is traditionally used to store any writes made to the virtual machine and is supposed to be able to increase to the maximum size of the base VM if required (it will also revert back to the base disk’s size if the desktop catalog is updated). However, I’ve noticed that as I copied files to the C drive of virtual desktops with PvDs, the differential disk does not appear to grow since the data is supposed to get intercepted by the PvD.  I’ll need to do a bit more testing with this.
5. Be aware that PvD disks do not shrink when users delete files from their virtual desktop folders.
6. Be aware that PvD’s redirect all of your user settings including cached mailboxes so 10GB may suddenly look insufficient if you cache users’ mailboxes that may be 8GB or larger.

***The following is the delta disk I was referring to in item #4 above:

Hope this helps anyone who may be looking for an explanation of how virtual machines in desktop catalogs are provisioned in XenDesktop 5.6.