One of the most common discussion points I continue to experience with the release of XenDesktop 5.6’s Personal vDisk capability has been around the desktop pool type. When delivering a desktop with Personal vDisk, the desktop/VM in that Desktop Group will be assigned on first use. Often this creates the basis of the conversation of why not a random pool where the user would get whichever VM is available in that pool. So today I wanted to share the basis of this current dedicated model as well as explore options with you around the random model concept.
So just why does Personal vDisk require an assigned VM model? The bottom line is application compatibility. Keep in mind that app compatibility is not just about does the app work or not. It’s a little more nefarious than that. A lot of time the app might appear to work but certain functions are not there. This is most common when that app leverages services or devices that need to be started or loaded at boot time … long before a user has ever logged on to that desktop.
That is the basis for the assigned model. We need to know the user at boot time in order to mount that user’s PvD and ensure all the devices and services are present and working. Waiting for logon to identify the user is too late for certain apps. Which apps you ask? That’s been the bane of our existence with app support, right? Understanding which apps do what and when.
Some apps are obvious like iTunes and its need to sync to devices and burn CDs (does anyone still burn CDs for music??). Often we don’t find out that annoying nuance with an app until the few users using that capability call into the help desk to point out something is not working. So instead of spending our lives figuring out what apps work, what apps don’t work and which ones ‘mostly’ work, we just mount the PvD at boot and ensure maximum app compatibility.
So what’s the down side? There is always a trade off when it comes to technology, right? In this case it’s about the idle pool. Since desktops are assigned on first use, this means eventually every user will have a desktop assigned to them that has their PvD attached. So the concept of an idle pool is not applicable. You will need to use something like power management to manage the idle resource consumption. Either by a generic sleep schedule for the desktops or something more advanced like from Lakeside Software where it learns the user behaviors and patterns over time and automatically adjusts the sleep and wake based on the user.
So what about random pools with PvD? Well, this becomes a decision of what is more important: speed of logon versus app compatibility. As we discussed, mounting the PvD at boot maximizes app compatibility. So if it’s a random pool we need to either: (1) wait for the user to be identified, then grab any available desktop, mount their PvD and then start it up for the user to logon. Or (2) we just mount the PvD at logon time and sacrifice some app compatibility.
So let me know your thoughts on that. Let’s assume we can manage boot times to no more than 20-30 seconds before the user can logon. What would you prefer?
- Accept the boot delay before logon and retain maximum app compatibility. And if so, is 20-30 seconds acceptable – could it be longer to maybe 60 seconds?
- Or sacrifice app compatibility in favor of the traditional idle pool and random assignment. aka attach the PvD when the user logs in and deal with apps that have issues as they arise.
I know you are tempted to say give me both with the ability to configure one or the other. But for now let’s assume there can be only one. And yes, that was a Highlander reference …