I mostly see the use of Persistent Pools at organisations I visit here in Asia Pacific region. Perhaps this is different for other regions of the planet (I doubt!), but I can tell you what I see here.

When I ask administrators for the reason why persistent pools have been adopted as the default solution for their virtual desktop infrastructure I repeatedly get the same responses:

– Our users need to connect to the same environment
– Our users need to be able to retain the look and feel
– Our users must maintain their data every time they connect to the virtual machines
– We need the Persistent Disk (old User Data Disk)
– Not sure…

I personally don’t understand why organisations choose persistent pools over floating pool (old Dynamic, or Pooled on XenDesktop). Perhaps they don’t understand the differences between the two types of desktop pools or how they work; or should work. I feel that there is a big misconception on why and when to assign desktop pools. VMware View Architecture guide explains the use of desktop pools in terms of Task (floating) and Knowledge (persistent) users – what in my opinion doesn’t quite work for non-experienced administrators.

My personal take is to always to use Floating Pools and address exceptions with different pool type on a case-by-case, if required.

The Persistent Pool

Persistent pools are assigned to the user at first logon, and after the first logon users always connect to the same virtual desktop allowing them to personalise the look and feel of the desktop and have constant access to the data and documents created in the desktop. It is also possible to manually pre-assign a user to a virtual desktop.

In VMware View, Persistent Pools allow for a Persistent Disk (old UDD). When the persistent disk is created VMware View agent instruct Windows GuestOS to offload the user profile to this secondary disk. The user profile is made up of Application Data, Registry Entries, My Documents, My Videos and all other folders under C:\Documents and Settings\%username% on Windows XP; or C:\Users\%username% on Windows 7.

When using Persistent Disks it is possible to replace the virtual desktop base image (System) via recompose or refresh operations. This is useful to accommodate for application upgrades and patches without losing user data. However if persistent disks are in use it is vital to architect a good backup solution for the data resting inside those disks. Backup agents inside the GuestOS could be leveraged, however increasing the overall cost of the solution. It is also possible to make use of the VMware View storage tiering to dedicate a datastore to accommodate all persistent disks and then backup the whole datastore or LUN.

Some organisations prefer to enable active directory roaming profiles as an alternative to backup of the persistent disk (make sure you also backup the data from the network). The problem with roaming profiles (improved a little bit in Windows 7) is that the data is copied from the network during the user logon and copied back to the network during user logoff. Besides the logon slowness caused by these copies, we are now doubling the storage footprint used by the user profiles and consuming network bandwidth and storage IOPS every time a user logs on.

Either way, I find that most organisations that use Persistent Disks do not have a backup strategy in place to guarantee the user data inside those disks.

The Floating Pool

Floating pools are assigned to the user at logon time and every time the user re-connects he/she may or may not get the same virtual desktop. It’s also possible to refresh or delete the virtual desktop after first use, ensuring every user will always get a clean and functional desktop. I really like the idea of getting a clean VM, however be aware of the impact on IOPS operations and make sure this will not be a problem for your storage array.

Because virtual desktops are always refreshed users will lose any documents saved to the virtual desktop. And that’s when roaming profiles coupled with Folder Redirection comes into place. Yes, it needs to be ‘coupled’.

Roaming Profiles wills store bit and pieces of the look and feel, registry entries and other windows and application configuration settings. Folder Redirection will forward My Documents, My Videos and other user data files to a specific path on the network. The Roaming Profile is very small and will be copied forth/backward during user logon/logoff, however if the Folder Redirection is not enabled than Roaming Profile also incorporate all the data in My Documents. This data could be of several gigabytes and you definitely don’t want to copy those files to the virtual desktop every time the users logs in.

An alternative solution for Roaming Profiles and Folder Redirection configuration is the use of 3rd Party User Profile management tools. They really make the user profile/workspace administration task a lot easier; however a skilled administrator can live with Roaming Profiles, Folder Redirection and some scripting. The 3rd Party solutions available on the market today can do a lot more than simple user profile management. See LiquidWare Labs, AppSense, Immidio Etc.

When using floating pools the backup of the user data is also critical, however because all the data resides on file servers it is easier to backed up using conventional backup tools without requirement for GuestOS agents. Not having GuestOS agents is also important to minimise the performance impact on the VDI infrastructure.

Disaster Recovery

Persistent Pool

This is the point of the reality check for organisations using Persistent Desktops. Unless your environment is using Full Clones (most organisations do not use full clones given that Linked Clones offer a great deal of storage savings) it is not easy to create a DR strategy to migrate Linked Clone VMs from one datacenter to another. Anyhow, it’s also not supported by VMware.

VMware Site Recovery Manager also doesn’t support VMware View without some non-supported Hocus Pocus scripts. Long story short – not supported.

When using Persistent Desktops the only supported method is to either export/ship persistent disks to the DR datacenter. This shipment can be achieved via FTP transfer, array replication, USB drive copy etc.

On the DR datacenter an independent View infrastructure with dedicated desktop pools shall be created and then each newly provisioned virtual desktop must be manually assigned to each user in the organisation. In a second recovery stage it is required to attach the shipped persistent disks to the virtual desktops while making sure that the correct persistent disk is assigned to the user’s new desktop.

Some parts of the process can be automated, however doesn’t seem to be a very clever way to provide disaster recovery. Maybe for organisations with 15 users this would be doable, but how about 500 or 1000 desktops?

The picture below is not ideal but basically it is to provide the idea that Persistent Disks would have to be manually mapped to the virtual desktops, which also would have to manually be mapped to the users. It is possible to create some automation, but it is limiting.

Floating Pool

When floating desktops are in use no data is stored in the VMs. The user data (roaming profile + folder redirection) is stored in a CIFS share in a file server or in your unified storage array. Make sure these CIFS shares are replicated to the DR datacenter and they are accessible through the same Fully Qualified Domain Name. This replication can also be achieved via simple Windows DFS.

You will also need an independent infrastructure to hosts virtual desktops, and floating pools configured. Most organisations will have pre-configured floating pools and leave them in disabled state. Because there is no user persistency there is no need to backup or ship VMs or Persistent Disks from Datacenter A to Datacenter B. Make sure you point the FQDN to connect to the new set of brokers and your DR environment should be up and running in no-time.

Using this approach it is even possible to get to an Active/Active state where users connect to either datacenters based on a load balancer algorithm that will determine what is the closest or the datacenter with less latency to the user end point. That could be a travelling user in a remote office or a user working from home, as an example.

The Exceptions

Sure, there are exceptions and that is why I say, “address case-by-case exceptions with different pool type”. These exceptions may be, as an example:

User need to deploy applications to the virtual desktops.

In this case floating desktops won’t serve the cause, however I always ask the following question: – Do you know what applications the users might need to install? If the answer is yes, why not publish does applications using application virtualisation. Why not deploy the applications to the base image?

Ultimately: – Why do the users need to install applications unknown to the administrator?

If there is a good reason, then I recommend the creation of a Persistent Pool exclusively for those users with the specific requirement.

Another exception would be applications that required the same of NIC Address or Computer Name. Can you think of a different exception? Let me know.

Floating Pools give you not only desktop independency but also infrastructure independency. They ease backup processes and ultimately facilitate disaster recovery and business continuity.