Floating Pools are the way to go….

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.


9 pings

Skip to comment form

    • Barrie on 03/03/2011 at 5:44 pm

    Fully agree with you on all points.

    I am using some persistent pools (on 15k SAS) – mostly to mitigate IOPS on profile logon/logoff and enhance logon speed.

    But I now have a couple of floating pools on local SSD with a stateless design in mind (with extra VMs as buffers in case of blade failure) – roaming profiles are OK if kept in check, but Appsense or ProfileUnity would be better

  1. @Barrie
    Thanks! Not to mention the management overhead added by Persistent Pools. When a user leave the organisation you will need to make sure the data is backed up and then delete the virtual desktop. For a organisation with 2,000 virtual desktops this may be a huge task.

    Local SSDs help you to achieve a stateless solution, however there might be a impact a performance impact on DRS and vMotion. You could also leverage local disks only for the .vswp files.

    • Craig on 03/05/2011 at 1:06 pm

    With the release of View 4.5 I really like how they integrated Thinapp into the Management Console. It makes it very simple to assign ThinApp applications to individual users virtual PC’s that require applications outside the standard image. That being said the only weak point of using the Floating Pools is you take away the ease of assigning Thinapps to user’s. Not to say you can’t work around that with logon scripts. However, that would be a nice feature if they added an option to assign Thinapps to User’s and not just to PC’s and Pool’s.

  2. I actually disagree with this article. First of all I how many companies are backing up data on users desktops/laptops right now…none that I know of I am sure their are exceptions but its not the rule. Most companies have policies where data is stored on a sharepoint site or network drives anyway that get backed up. I don’t want to backup users personal pictures or videos, or other random downloads.

    Using folder redirection can certainly reduce the network bandwidth required for login/logoff but roaming profiles can still sometimes have megabytes of data in them which could take a few minutes if you have mobile clients like most companies. And taking minutes to login to your desktop frustrates users.

    Third I actually like the fact that after someone leaves the company I have all of their files on one disk. The nice part is you can just mount that users persistent disk to their managers virtual desktop and presto they have access to everything they need.

    • Simon Rowan on 05/06/2011 at 10:35 pm

    Floating pools should always be the final goal, unfortunately for the largest implementations where the number of applications can run into the thousands, it is incredibly difficult to define a base image and/or virtualise a percentage of those applications. Application virtualisation may be able to cover 60% of the apps, but if you are left with 40% of applications, that could still leave 2000 applications, which cant all be included in the base image, then you have the problem of defining multiple master images.

    For any client with less than 200 apps I would always go down the floating pool design.

    • MSK Kishore on 06/20/2011 at 11:19 pm

    First of all your article is good, I am using VMWare View 4.5, using administrator i am not able to assign more than one VD to a single user in a single pool, is it a limitation? If it is limitation the is there any workaround can you please tell me.
    MSK Kishore

  3. I love the working pool concept however I also need the users to be able to checkout the desktop in such I have to use persistent pool but not setting a persistent disk but instead use roaming profile.

    Do you think that would work?

  4. @wee kiong
    You can use roaming profiles and check out the vistual desktops to laptops. It will work as long the users are still connected to the network. Be aware of profiles being transmitted over slow WAN links. Persona Managemement not supported in this case.

  5. @MSK Kishore
    For floating pools you can allow multiple sessions from the same pool to same user. For persistent pools only a single Active Directory user per pool.

  6. @Simon Rowan
    Thanks for your comments.
    I agree with your aproach. Pay attention to new tools popping up to help with application virtualization, layering and customizations. In particular have a look at LiquidWare Labs FlexApp that will allow users to install and maintain applications even when using floating desktops.

  7. @Paul Slager
    Always good to have people with diferent opinions. I stick with my idea of non-persistent desktops where possible. Pay attention to new tools popping up to help with application virtualization, layering and customizations. In particular have a look at LiquidWare Labs FlexApp that will allow users to install and maintain applications even when using floating desktops.

  8. @Andre Leibovici
    So checking out and not connected to a network would only work if its not using roaming profile?

    How about if I have a persistent pool to cache the information? Do you think that would work?

    Else what would be a good way to have a checkout desktop without having to connect back? Is persistent disk the only way?

    • Sivix on 11/22/2011 at 2:37 pm

    I totally Agree with this article: I always suggest to use floating pools because of the “pain” in management/load/DR of persistent disks.
    Now the question is: What about .OST file of Outlook 2010? they are requested to use Outook in cache mode (anti-spam use it, Desktop Search use it). if using folder redirection is “not support”/”not suggested” because of heavy load on Network. if selecting the option of Persona Management to sync the “local” folder using floating pool, every day thounsand of users will download the same copy of 3/4GB OST files.

    SO what are the current solution? using persistent? some “special” feature of outlook?

    tell me your opinion.

  9. @Sivix
    May I suggest you to read my article “VDI and Microsoft Outlook, analysing the variables” hwre I discuss how to handle Outlook in a VDI environment.



    • snakethejake on 11/25/2011 at 12:35 pm

    On a floating pool with Folder Redirection, how are you getting around the two logon issue for redirecting folders for the first time a use logs in? Currently any user logging into a PC for the first time has to login a second time before the redirection will occur. How are you getting around this?

  10. @snakethejake
    I never came across this issue before, but I how it may present itself. There is a KB from MS around FAST Logon that may help you (http://support.microsoft.com/kb/305293). You need to make sure that applications, group policies and scripts at startup/log on are executed synchronously.


  11. I have since this article completely changed my mind about Persistent vs. Non-Persistent desktops. Please read my “Open letter to non-persistent VDI fanboys…” at http://myvirtualcloud.net/?p=5198

  1. […] was reading Andre Leibovici’s excellent article on View Floating desktops and comparing it with my feeling about View features and use.  I completely agree that if […]

  2. […] I have previously stated that Floating Pools and Linked Clones (or similar technology) is the way I believe every VDI deployment should be done (either using VMware View, XenDesktop or any other broker). Persistent Desktops should be treated as exceptions to address specific user or application needs. You will find reasoning in my article Floating Pools are the way to go… […]

  3. […] The non-persistent desktop – this is a special category of VDI, where desktops are refreshed at some point in time, usually after user log off, returning to its pristine state. Fans of non-persistent desktops claim this is the best way to maintain a fresh and clean desktop. I was a big fan of non-persistent desktop and wrote multiple articles, including this one (Floating Pools are the way to go….). […]

  4. […] March 2011 published an article entitled ‘Floating Pools are the way to go….‘ where I  put a stake on the ground in relation to the use of persistent versus […]

  5. […] If you want to learn more about why and when you should choose Floating and Linked Clones pools you should read my article “Floating Pools are the way to go….” […]

Leave a Reply