One of the most common points of discussion that I continue to experiment with the release of the personal vDisk capacity of XenDesktop 5.6 was around the office pool type. Upon delivery of a desktop computer with Personal vDisk, office / VM Desktop in this group will be assigned to the first use. Often this creates the basis of the conversation why not a random pool where the user would get by VM is available in this pool. So today I wanted to share the basis of this model being dedicated and to explore options with you around the random model concept.
So just why Personal vDisk requires a VM affected model? The bottom line is application compatibility. Keep in mind that application compatibility is not just about the app not working or not. It is a little worse than that. Many times the application may appear to work, but some features are not there. This is most common when that application uses the services or devices that need to be started or loaded at startup ... long before a user ever connected to this workstation.
This is the basis for the assigned model. We need to know the user at boot time to mount PvD this user and ensure that all devices and services are present and working. Waiting for logon to identify the user is too late for some applications. What applications do you ask? This has been the bane of our existence with the support of the application, right? Understanding what applications do what and when.
Some applications like iTunes are obvious and need to synchronize devices and burn CDs (someone even burn CDs for music ??). Often we do not find this annoying nuance with an application until a few users with the ability to call in the help desk to emphasize something is not working. So instead of spending our lives determine what applications work, what applications do not work and those who "mostly" work, we just mount the PvD start and ensure application compatibility Max.
So what's the side down? There is always a compromise as regards technology, right? In this case, it is about the resting pool. Since desktops are assigned to the first use, it ultimately means each user will have an assigned office to those who have their PvD joint. Thus, the concept of an idle pool is not applicable. You will need to use something like power management to manage resource consumption at idle. Either a generic sleep schedule for desktop computers or something more advanced like Lakeside Software, where he learned behaviors and user patterns over time and automatically adjusts the sleep and wake up based on the user.
So what about the random pools with PvD? Well, this is a decision which is more important: the connection speed from the application compatibility. As we, the assembly of PvD start maximizes application compatibility. So if there is a random pool we must either: (1) Allow the user must be identified, and then enter any desktop available, mount their PvD then run it for the user to log on. Or (2) we have to climb PvD at logon and sacrifice some application compatibility.
So let me know your thoughts on this. Suppose that we can manage the startup time to no more than 20-30 seconds before the user can connect. What do you prefer?
- Accept the startup time before the opening session and maintain the compatibility of the maximum application. And if so, is 20-30 seconds acceptable - could it be to perhaps 60 seconds
- Or the compatibility of the application sacrifice for the traditional resting pool and random assignment? . aka the PvD set when the user logs on and deal with applications that have problems that arise.
I know you are tempted to tell me also give the option to configure either. But for now, let's assume that there can be only one. And yes, it was a reference Highlander ...
0 Komentar