Month: October 2014

Citrix Provisioning Server – Cache in device RAM with overflow on hard disk

I first wrote about Citrix Provisioning Server (PVS) in 2012 and focused on a feature called vDisk Update Manager.  Back then PVS was at version 6.0, the current release is version 7.1 and again it’s worth time looking at a small change that has made a massive impact.

In this release Citrix has introduced the vDisk feature Cache in device RAM with overflow on hard disk.

Before we leap into cache first lets wind back a little and quickly look at PVS.  I have to admit that in a lot of recent work I have been using Citrix Machine Creation Services (MCS) not PVS, I’ve been neglecting one of Citrix’s imaging technologies because I’m not managing a production site and therefore not having to deal with patching and updates or worrying about backend performance.  A lot of the work I do is demonstrations and proof of concepts therefore convenience is good for me .  I’ve certainly found MCS useful and have a number of customers doing really good things with the utility in production at scale.  However the ace PVS has always carried is the ability to redirect the locations of disk writes and it’s a trump card as good as any you carried in the playground.

Why is that important?  It’s been well documented that virtual desktops create lots of writes, in small blocks too.   Although we are far from the early days of desktop virtualisation and therefore this no longer comes as a surprise (if it came as a surprise I’d argue you didn’t really understand desktops before you started), PVS has come up with the perfect answer with its new write cache option.

There are now six options for the vDisk Cache type:

  • Cache on device hard drive
  • Cache on device hard drive persisted (NT 6.1 and later)
  • Cache in device RAM
  • Cache in device RAM with overflow on hard disk
  • Cache on server
  • Cache on server persisted

I have only ever used PVS with XenDesktop and XenApp and have only ever looked at Cache in device RAM and Cache on device hard drive.  I’ve always liked the idea of caching things in RAM, its fast and has become relatively cheap but fill it up and you have no where to go.  Well you do it crashes the server instance and that in the end does give us somewhere to go the exit door!

The second option, up till now, has been move those writes to a hard disk on the host and take them away from your storage.  The theory, we don’t wan’t to keep them with our pooled desktops so let’s write to a location thats out of the way, of the network and cheaper.  Many production environments use this and it works very well.

But now we have the ultimate hybrid; Cache in device RAM with overflow on hard disk.  We can use the RAM option without the risk.

To implement this feature is a straight forward procedure.

Make sure you have a disk to overflow to, if you are using the XenDesktop Setup Wizard in PVS this is created for you.  If not you do need to have this; it will need to be part of your VM as  local disk on the host and will appear as the next available drive letter in the VM when it boots (note- the streamed disk will normally be the first disk).

You are now ready to switch on the feature in the vDisk properties.  Remember that to do this the disk has to have no locks. The feature is found in the properties section of the vDisk, in your Store.

Once enabled you are asked to select a value for the Maximum RAM size in MBs.  This is the amount of RAM to use as the cache, in the example below I have used 512MB.   Note you should make sure you have an additional 512MB or RAM assigned to your VM.  You can play around with these numbers to find the best fit for your environment.  I have found that with good storage and server based hardware 512MB works very well, however in older environments and some labs I’ve increased this number to 1.5GB to get good results.