Pages

Sunday, April 15, 2012

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:

image

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:

image

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

Size: 16,069,630.00K

Provisioned Size:  41,943,040.00KB

image

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

image

Create the machine type Pooled with personal vDisk:

image

Select the snapshot for the master image:

image

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

image

Complete the desktop catalog creation:

image

image

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

image

image

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:

image

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

image

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

image

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

image

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:

image

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:

image

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:

image

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

imageimage

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

image

Note that the identity disk is thick provisioned:

image

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

image

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

image

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

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:

image

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:

image

image

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

image

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

image

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

9 comments:

Jarl Nelson said...

Interesting. I have set up a similar pilot of PvD but instead of using MCS I used PVS. With PVS the "XenDesktop Setup Wizard" is invoked to creat the Catalog and PvDs. Unfortunately, all of the Personal vDisks it creates on my VMware VMFS volume end up being THICK provisioned. There was never any option during the Wizard to specify thin or thick.

Unknown said...

Great article. Has anyone tried to move the VM's from one datastore to another? What we found is that the identity disk refereance gets removed and a full copy of the base image disk gets created for the vm that we migrated to a new datastore.

nbiolo said...

Hey Mike,

I just migrated about 150 personal vDisk VMs and then noticed this was happening. Do you have any additional insight on this? Does it prevent images from being updated? I'm not so worried about space as dedupe will take care of the basedisk getting recreated each time, but it is very messy compared to how it was supposed to be.

Anonymous said...

nbiolo, you have to do a custom move on the disks in a vm. If memory services me right you have to move the reference disk first, then move the vm. If that does not work switch the process around. We ended up getting it to work.

Aitor said...

Very nice post. Anyway I continue having a doubt. If you create a base machine with 40 GB and 10 GB PvD, why appears C:\ like 4,99 GB Disk at Windows?
When I connect to the virtual desktop I have 2 hard disks. C: (4,99) and P: (10 GB PvD).
Anyone can explain me please? Thx! ;)

Unknown said...

Aitor, the reason for only seeing the 4.99GB when you allocated 10GB is because the PvD splits the disk up into User and Application Data keeping the 2 separated. When a user installs an application it goes into that respective area as does user data such as My Documents. Think of this as the change log for your base image. We have had some minor issues with this setup but overall it works pretty well. There is a new version of the PvD that we are hoping to test out soon. This version will dynamically allocate the space between User and Application space. You will still need to determine what your split will be but after that the system can pull space from one area over to the other if one area fills up. That is how I understand it at this point.

Jules said...

Has anyone looked at this in XenDesktop 7.6? I am noticing that something has changed. Specifically here:
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.

Now if you have more than one snapshot of the master image, the base disk will be Thick Provisioned even if the master's is Thin Provisioned.
https://discussions.citrix.com/topic/365787-base-disk-is-not-thin-provisioned-after-xendesktop-76-upgrade/

Unknown said...

This article was FANTASTIC! No where does Citrix specifically mention that additional storage at the whole storage level separation of TWO DISKS! Not one that encompasses the Storage being absorbed.

If they do they talk about it the only do that individually- not both, at least from the Citrix perspective anyway.

THANK YOU TERENCE! :)

Anonymous said...

Fastidious answer back in return of this issue with firm
arguments and explaining all on the topic of that.