More on VDI-in-a-Box and Personal vDisks

In my last post, I talked about the new release (v5.1) of VDI-in-a-Box (“ViaB”) and some of the new features. One of those new features is the addition of support for Personal vDisks (“PVDs”). But before we get any deeper into the subject, let’s take a step back, and make sure we’re clear on why you would want PVDs in the first place.

Dedicating a VM to every user consumes a lot of storage space – and, even though local storage on a ViaB server is not as expensive as SAN storage, it’s still more expensive than the storage on a desktop PC. Plus you still have the same headaches of managing and updating every individual PC. That’s why we prefer to provision virtual desktops from a common master image. It takes up far less disk space, and when you update your master image, all of the virtual desktops that are provisioned from that master image get updated the next time they reboot.

On the other hand, since the master image is a read-only image, the user has no ability to make persistent changes to the VM. In a Citrix environment, we generally handle this by using the Citrix Profile Management tool (which is included with ViaB), which allows us to write user profile changes to a shared folder somewhere else on the network, so that unique user profile data will survive changes to the underlying master provisioning image.

But there’s only so much you can do with user profiles – and one of the things you can’t do is allow users to install their own applications. Personal vDisks, which were first introduced in XenDesktop v5.6, are intended to give you the best of both worlds, by creating a persistent virtual disk that is unique to the user and that is, in simplistic terms, merged with the provisioned image at logon time. The PVD can be used to store user-installed applications, user profile data, and even user files, if you wish. So you get to provision from a common master image and give users the personalization they want.

But there’s an interesting wrinkle in the way PVDs work in ViaB v5.1. One of the major selling points of ViaB is simplicity: you don’t need all the supporting server infrastructure that a full-blown XenDesktop deployment requires, and you don’t need shared storage. That, in turn, keeps the cost down. But while ViaB is smart enough to replicate your master desktop images to all of the servers in your ViaB grid, PVDs are not replicated across the grid. Instead, a given user’s PVD gets created on the local storage of whichever server in the grid that user happens to land on at first logon – and it stays there. ViaB will then insure that, for all subsequent logons, that user will be directed to the specific server that contains the PVD.

That’s a great solution…unless that server fails, in which case the PVDs on that server are no longer available, and their associated personal desktops are broken. In all of their presentations on ViaB v5.1, Citrix glosses over this point by stating that they recommend that you periodically back up the users’ PVDs, and that they have documented the steps required to do so. And they have. Here is the process for backing up and restoring PVDs, assuming that you’re running XenServer as your underlying hypervisor, straight from CTX134792 in the Citrix Knowledge Base:

  • From the ViaB management console, look up the personal desktop that you want to back up. Note which server in your ViaB grid is hosting this desktop.
  • Note the personal disk name of the personal desktop you are backing up. This will have an intuitive name like “Windows7x64p1386d2eaab7.”
  • Insure that the personal desktop is shut down.
  • Move to XenCenter (the management tool that comes with XenServer). From within XenCenter, navigate to the XenServer in your grid that is hosting the desktop, and use the XenCenter “Export” function to export a copy of that VM. Where will you export it to? Well, assuming that you don’t have shared storage, you’re going to have to export it to some kind of storage repository that the XenServer can see which you can later move to a different XenServer in your grid…like an external USB-attached hard disk.
  • If the ultimate bad happens, and you have to restore the backed up PVD, you need to again fire up XenCenter, and navigate to a surviving server in your grid that you plan to use to restore service. Use the XenCenter “Import” function to import the VM from your backup storage repository.
  • Once it’s imported, select the VM in XenCenter, and select the Storage tab. You will see that the VM consists of two disks, one of which will match the name that you made note of way back in step 2. “Detach” that disk from the VM, and then delete the VM. That will leave you with a virtual disk (your PVD) that is not associated with any VM.
  • Now go back to the ViaB management console, select the “User Sessions” tab, and, under the “Actions” link for the non-functional desktop, select “Repair.” ViaB will scan the data stores of each server in the grid until it finds the PVD, and prompt you for confirmation that this is what you really want to do. When you confirm, ViaB will destroy the remains of the non-functional desktop, create a new linked clone on the server that now contains the associated PVD, and attach the PVD to the new linked clone. The user can now log in again.

Bear in mind that you will have to follow this manual backup procedure for every individual PVD that you have in your environment, and, likewise, if you ever have to restore PVDs, you will have to manually restore them one at a time.

Show of hands: anybody else out there think that this might be just a tiny bit onerous?

Now, if you do happen to have a SAN, you could attach a unique LUN to each server in your ViaB grid, and, provided you’re using Hyper-V or VMware as the underlying hypervisor, use that LUN for storing your master images and PVDs. (ViaB on XenServer does not support multiple datastores, according to Then you could conceivably move that LUN to a different server in your grid in the event of a server failure, and have all your PVDs back…although you still need to do periodic backups of the PVDs (maybe with SAN snapshots?), because it is possible that a PVD could get corrupted if the ViaB host goes down while the desktop OS is in the process of writing to the PVD. And, as we’ve said earlier, you’ve now negated one of the big advantages of ViaB – no shared storage requirement.

Here’s the bottom line, in my opinion: Until they come up with a way to automate the backup and restore process for PVDs, or, better yet, find a way to replicate PVDs across the grid, PVDs should be used sparingly (if at all) with ViaB. And do not use PVDs to store user profile data or user-generated files. Instead, use the Citrix Profile Manager to handle the profile data, and standard policy tools like “My Documents” redirection to direct user-generated files to a shared folder outside of your ViaB grid. That way, your worst-case scenario is that your user may have to reinstall whatever user-installed applications may have been lost when the PVD disappeared.

Finally, please note that these concerns are not applicable to a full XenDesktop deployment. With XenDesktop, you will have some kind of shared storage, and your PVDs will live on that shared storage. So: XenDesktop, PVDs are great; ViaB, not so much.

2 replies
  1. Geoff Keate
    Geoff Keate says:

    It does work, and it does restore, but yes, it is a pain to have to copy each PVD to the storage in every other hypervisor. Do wish the team, who are wonderful people BTW, would look at replication for the vDisk, rather than using a shared location as in HyperV 2012. Best solution in the long run is to ensure you have as few users of vDisk as possible, as restoring things can take time, and definitely no personal files in the P drive. For apps only, and only where App-V for example won’t play ball.


Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.