What is your Virtual Function?

Provisioning Server

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.

Citrix Provisioning Server (PVS) is now at version 6.1. Released in version 6.0 was the vDisk Update Manager and I think it is worth some time looking more closely at this feature.

Once installed and configured the PVS management console has a new node the vDisk Update Manager. This has three sections; Hosts, vDisks and Tasks.

Hosts; references the hypervisor hosts in use, XenServer ESX and Hyper-V are all supported.

vDisks; is the PVS vDisks enabled for update management.

Tasks; is the automated scripts that power the Electronic Software Distribution (ESD) client software. Microsoft System Center Configuration Manager (SCCM), Microsoft Windows Update Service (WSUS) and custom scripts are all supported. Please note: the ESD client software must already be installed in the vDisk image.

First let’s take a look at manual updates. In previous versions you had to make a copy of the vhd file (vDisk), mount this against a new machine in PVS, boot and make the changes required, shutdown the image, increment the vDisk version number and make it available to all machines. It was possible to script this process via PowerShell however in my experience not everyone did this and there was still manual work to do to integrate this into your environment.

To utilise the new features you require a running environment with machines utilising a standard mode vDisk. This feature is only available for standard mode disks; private disks are read / write and therefore can be managed by existing ESD tools.

Step one is to add the host that you are using; right click on the Hosts node and follow the wizard. You will require the correct host / pool credentials.

Step two is to add a vDisk to this tool; right click on the vDisks node and follow the wizard. This will search your Store for available vDisks and ask you to enter the VM on your host that will be used as your maintenance VM. Finally it will require an AD machine account in order to process the updates to the vDisk. If you have not created the VM on your host with then name specified in this step do so now.

In the image below you can see the PVS Services Console with the properties of the vDisk Update Management node highlighted. It shows that the vDisk in the Store StoreW7 is on host XenServer-1 and the VM on the host that will use this disk is called W73. The vDisk has to exist before you start step two however it does not check the Host to make sure the VM is there, so this can be created after if required. It will however need to be present for this process to work correctly, as highlighted below XenCenter is showing a VM with the name of W73.

Once this is completed from the Stores node you can select the vDisk and manage the Versions. Right click on the vDisk in the Store and select Versions.

Select New; this will create a new disk in Maintenance mode. To edit this disk boot your maintenance VM from the Host. Once this is completed if you refresh the vDisks Versions console you will see a single device is now accessing this version of the disk and that the Access type is Maintenance. Please note: you have not had to remove any locks form the existing vDisk, log off any users or shut down machines to start this process.

You can now make any changes required to the VM as the version you are using is in read write mode. To achieve this PVS is using avhd files and creating a chain to the original disk. This saves on time and disk space when making changes, it also means if we are not happy with the results we can revert back quickly to the previous image. Once we are satisfied with the build we can merge all updates, this stops a long chain becoming a performance drain.

Reboot the VM to apply any changes and then shut the Maintenance VM down. You can then Promote the vDisk and can set the access version to Test or Production. If you set it to Production and apply the changes immediately, on next reboot all users will have access to this disk.

Before reboot the VMs are still using disk 7.3

After reboot they are now using 7.4

As you can see this is a great improvement on the original way of updating the vDisk. However you will not always want to run through this process, especially when it comes to patching. This is where the Tasks feature of the vDisk Update Management tool comes into play. To implement; right click the Tasks node and follow the simple steps. This will by default allow you to connect to WSUS, SCCM or implement pre or post scripts. Like all tasks this can be scheduled and after the update the vDisk can be placed into Maintenance, Test or straight into Production modes.

In my opinion simplifying this process for desktops is a great win for XenDesktop. It makes it an easy step to get to grips with PVS and by integrating into SCCM and WSUS most desktop admins see significant advantages to their current virtual desktop update process. If you couple this with the advantages of PVS in terms of single image disk management, read IOPS cache and control over the write IOPS then we now have access to a powerful desktop management tool.

Finally lets not forget that all these advantages are available to XenApp too. With a number of organisations now virtualising XenApp servers the number of server instances is on the rise, what better way to manage them than with PVS.

***Update***

Stephen (comments below) has provided some links to PVS documentation that go into more detail on additional tasks. Thanks Stephen.

Last Tweets

I was lucky enough to join the Australian Institute of Company Directors swim team for the #PorttoPub swim in Perth Western Australia. The race was called off at the three hour mark due to the tough conditions. However it proved again to me that a good t…https://t.co/AMf3zGNVEx,7 hours ago