To PVD or not to PVD

By Chaim Landau
Posted in Virtualization
On July 18, 2013

With XenDesktop 5.6, Citrix introduced Personal vDisks (PVD). With PVD, Citrix closed a serious gap in its VDI offerings. Prior to PVD, the enterprise was faced with few options when it came to VDI. The options were to either deliver a non-persistent desktop and lose all the changes to the operating system upon reboot, or a persistent desktop and manage the virtual machines like any other traditional workstation, practically depleting the ROI on the VDIs.

Non-Persistent Desktop

A non-persistent desktop is a desktop that does not preserve any changes made to the operating system between reboots. The desktop gets deployed using a master image, and any changes to the operating system are written to either a “difference” disk or cache drive, depending on whether PVS or MCS is being used as the provisioning technology. During reboot, all changes are discarded and the desktop is reset to the original image. Changes made to the master image (for example, service packs, hotfixes, or application installations) are applied to the desktops during boot time.

Common Use Case

Non-persistent desktops are commonly used by users who do not need the ability to make changes to the operating system and can do with the common set of applications installed in the image. In most cases, such a scenario would include a profile solution such as Citrix Profile Manager or AppSense Personalization, to preserve the user’s profile. An example of such a user would be a call center employee.

Pros

  • Manage all desktops, including future changes, through a single image
  • Save on storage, as the drive requirements for the difference disk and cache drives are much smaller than that of traditional desktops

Cons

  • Changes to the operating system by the users are not preserved between reboots

Persistent Desktop

A persistent desktop is a desktop that preserves all its changes throughout the life of the machine. The machine is originally deployed using a master image, however, once deployed the machine becomes a machine of its own and needs to be managed like a traditional desktop.

Common Use Case

Persistent desktops are usually meant for users who require administrative access to their desktop and/or the ability to install their own software. Developers are a classic example of such users.

Pros

  • Changes made to the machine by the user between reboots are preserved

Cons

  • Requires as much storage as the master image
  • Updates to desktops need to be performed like any other traditional desktop

Persistent Desktop with PVD Enabled

A personal vDisk (PVD) is a disk that gets attached to each of the virtual desktops and is then used to preserve any changes made by the user. It works by having the administrator deploy virtual desktops using MCS or PVS, and any changes made to the VDIs are redirected to the PVD. With this model, an administrator can continue benefiting from MCS or PVS, while not having to give up on the ability to preserve the changes to the operating system, such as application installations by the user.

Pros

  • Unlike non-persistent desktops, changes are preserved during reboots
  • Still provides cost savings on storage as the storage requirements for PVDs are usually much smaller than dedicated desktops
  • Ability to manage the desktop using MCS or PVS

Cons

  • Requires more storage than non-persistent desktops
  • The technology is fairly new and still lacks some important management features

Worth Mentioning

Drive Letters

By default, PVD will create two drive letters; a P drive to be used for the profiles, and a V drive for applications. The P drive is visible, while the V drive is hidden and can only be seen via a command line. The V drive will look like a copy of the C drive, and an administrator will have no way to tell which files have been installed by an administrator or by the user.

50/50 Split

By default, the PVD comes with a 50/50 storage split; half being allocated for the users' profiles and the other half for applications. To change that, an administrator would have to update the PercentOfPvDForApps registry key under HKLM\Software\Citrix\personal vDisk\Config.

Redirected Profiles

When using Citrix Profile Manager in conjunction with PVD, the user’s profile won’t be redirected to the PVD, allowing an administrator to provision smaller PVDs. This is recommended as the cost of preserving PVD storage for the profiles would be more expensive than housing them on file servers. In addition to the cost, having the profile de-coupled from the desktop allows an administrator to utilize that profile on other desktops as well, or to be used in a DR scenario. Should you choose to use Citrix Profile Manager, remember to adjust the 50/50 split to allocate more room for the applications.

Resetting a PVD

PVDs can be reset either through a PowerShell command or in the Desktop Director. When resetting a PVD, only the application portion of the PVD is reset; the profiles, however, will stay intact. To remove the profiles as well, an administrator would need to log on to the desktop and delete the profile in the traditional manner.

Rules Files

Citrix is using “rules” files to instruct PVD what to redirect to the PVD drive and what to place on the difference disk or cache drive. When troubleshooting an application that won't redirect to the V drive, one might potentially have to tweak those files. The rules files can be found in C:\ProgramData\Citrix\Personal vDisk\Config.

Symantec EndPoint Protection (SEP) with PVD

At the moment, version 12.2 of SEP does not work with PVD. Citrix recommends either upgrading to 12.3, which requires a server-side upgrade of SEP, or going with 12.1.