Friday, September 18, 2009

How to use PVS without having to wait for file copies

By:Rich Brumpton

As I have mentioned before I love PVS. The entire concept of live booting a large number of XenApp servers off of a single image simply makes sense. Works great for VDI or Desktop OS streaming too and one of the facts of life on all three of these scenarios is that you are going to have to do updates to your images. No matter how good a job you do a separating your apps from your image using application virtualization tools, you will still have to deal with OS patches and other required changes.

Typically, this means that you are versioning anywhere from once a month up to several times a week depending on the life-cycle stage and stability of the requirements for the image. In this post I will outline an approach that I have started using in my lab and show how to make these updates simple and without requiring a wait for file copies.

The general principle behind this update method is the same as what Citrix uses themselves with XenServer. "If you have to copy something big, you might as well ask the storage system to do it for you." This way the data never has to leave the SAN to be copied, and if you have a SAN that supports it you can even do thin cloning for instant writable copies of data.

Because that is what I wanted, the ability to update a vDisk image without having to copy the file. In my lab environment I often have to version a vdisk several times in one day while working through several generations of a build and the file copy process was limiting how many versions I could iterate through in a day. I also have in my lab right now a NetApp SAN that provides me with thin cloning, and one day during a demo I hit on the way to make this all easier.

During a presentation that included a demo the NetApp SnapDrive component (more on this later) I was asked by a member of the audience "How hard is it to take a snapshot and mount it?" I was demoing SnapDrive on my PVS server so I said "easy, like this" and demoed taking and mounting a snapshot about as fast as I could run through the wizard. After this demo I got to thinking, I had just created a copy of 12 different PVS images in seconds, not the ~1hour copy time I usually faced for a full versioning of all of my vDisks. This in turn led me to investigate how I could make this work in production, and the result is:

How to use NetApp and PVS to make instant version changes
The Key to making this work for me is the ability of the NetApp FAS to take a snapshot and make it writable. There are two mechanisms that can do this for an iSCSI LUN (which is where I will focus) hosted on NetApp storage, FlexClone and LUN Clone. While it's possible to do what I'm about to describe with LUN Clone, it will take several more steps or more extensive scripting to get the same ease of use as FlexClone coupled with SnapDrive, which is the solution I'll focus on here.

FlexCloneas mentioned above has the ability to take a snapshot of point in time data and make a writable version of it that only grows by the deltas between the original and modified version. The other piece to the solution from NetApp is a piece of software that you install on your servers that connect to the SAN called SnapDrive. This software component snaps into computer management and allows you to manage the storage attached to the server from the server itself. This is a very easy way for server administrators to take advantage of features like storage snapshots, provisioning, and cloning without having to understand the underlying SAN operations.

With these components in place you can manage versions of images on provisioning server like so:

We have to build the environment properly to allow for this update method, so we begin by setting up a new store. Note that in this model you may have a large number of LUNs per server which is why we are using folder mount points instead of drive letters.
  1. Create a thinly provisioned FlexVol on the NetApp Array for use by PVS.
  2. Create a folder on the PVS server to server as a container for multiple vDisk stores (i.e. c:\stores)
  3. Create an iSCSI LUN and attach it to your PVS Server using SnapDrive and mount the LUN in a subfolder of your stores folder (i.e. c:\stores\WindowsXP.001)
  4. Use the PVS Console to create a new store pointed to this new LUN
  5. Create a new vDisk or copy an existing one to this location
  6. Assign this initial version to devices and use normally
The actual versioning process is used for each version of the vDisk throughout it's lifecycle. The longest part of this process will be the actual updating process in the VM.
  1. Use SnapDrive to clone this LUN and mount under a new subfolder (i.e. c:\stores\WindowsXP.002)
  2. Create a new PVS store and import existing vDisks
  3. Change vDisk properties to Private mode, change version number (if using automatic updates) and assign to an update VM.
  4. Use update VM to apply updates
  5. Change vDisk back to standard mode and then assign to dev, test or prod machines as appropriate
Because the child clone relies on it's parent, we do have to take steps to remove old versions cleanly.
  1. "Split" the child clone from the parent
  2. Ensure that all vDisks in the store are unused and unlocked
  3. Delete the old store
  4. Once this split is complete, delete the parent LUN and mount folder.

As you can see this update method, is not too unlike a traditional file copy update method in the number of steps required, but is much faster. The other really cool thing is that many of these steps can be scripted. Both PVS and SnapDrive provide scripting interfaces that can be used to perform many of these commands either on demand or on a regular basis. In fact I'm working on a variation of this for a customer who is looking for a way to script the behavior of PVS to allow scheduled updates trough SCCM. This process is to be completely automated up until it is tested and released into production by the administrators. The process for them would be very simular except instead of cycling ever upward through version number for their folders, they would have a series of folders that are re-used on a monthly basis (i.e. vDisks.1 to vDisks.4 for a weekly update schedule.)

The other cool thing about this solution is that you don't have to sacrifice performance in order to save space and time. Because the NetApp system is aware that the 2+ (virtual) copies of a given block in different thin clones are really the same physical block, it can simply cache it once, and avoid having to go to the disk for new instances of the same vDisk. This means that not only are you not slowing down the SAN by making a big file copy, your new Disk image is already in the cache of the storage array!

This kind of true synergy between vendors really gets be excited. To be able to take these features and tie them together ourselves without relying on them to do the integration for us by using a product like WorkFlow Studio is simply amazing.

More information on Provisioning Server


  1. very nice... thanks for the write up. you say NetApp can do this, are there any other SAN products that we can leverage other than NetApp to get this same configuration?

  2. NetApp is the only one I know of that has put all the pieces together for us like this.

    I think the same basic concept might be available on other platforms that can perform thin cloning (EqualLogic? LeftHand?) but without testing I can't be sure.

    Traditional Copy-on-write snapshot arrays might be able to do this, but be cautious because the write performance penalty on the LUN can be substantial. Traditional thick cloning technologies might also do this, but you are essentially back to a file copy there, so you might as well not bother.

    If anyone wants to try this on a different array and share their experience I'm sure we would all be interested.


Microsoft Virtualization, Citrix, XENServer, Storage, iscsi, Exchange, Virtual Desktops, XENDesktop, APPSense, Netscaler, Virtual Storage, VM, Unified Comminications, Cisco, Server Virtualization, Thin client, Server Based Computing, SBC, Application Delivery controllers, System Center, SCCM, SCVMM, SCOM, VMware, VSphere, Virtual Storage, Cloud Computing, Provisioning Server, Hypervisor, Client Hypervisor.