Tuesday Jul 22, 2008
Wednesday May 28, 2008
By MrDGrobler on May 28, 2008
It has been a while since I've been talking about the desktop lifecycle. Shame on me, no excuses. So in todays entry I want to dive a bit deeper into some of the specifics of Sun Virtual Desktop Connector. I want to cover the fine-tuning of desktop lifecycle. Or in other words I want to talk about parameters and choices available to control the semantics of the automatic provisioning and de-comissioning of desktops. Let's get started:
Fine-tuning the desktop creation
So initially we should talk about the options controlling the creation process. There are some very obvious setting for each pool, like the selection of a template or how many VMs should be minimally available for users. The later value drives the creation of new VMs. An available VM is not used and ready for the next user. If the pool is under the limit of minimum available VMs, new VMs will be created. In opposite the maximum value defines how many VMs should be in total created per pool. This helps you to control the utilization of storage.
It is also possible to define the naming prefix for each newly created VM. The naming of the VM has actually a broader reach than you might expect. It defines the name of the VM and if specified in the customization settings, it can also be used as the computer name for the Windows guest. This might be a handy choice in a lot of situations. But you have to take into account, that names of deleted VMs will be reused, which might cause trouble in the Windows domain. Using a self-defined naming scheme for the computer name is an alternative to consider. This can be defined in the customization spec as well.
Besides this there are 2 global settings in the advanced section of the administration tool. One defines the interval in which new clones should be created. The default is 30 minutes, very conservative, for demos definitely not suitable. The other option is to restrict the list of storage units, that will be considered for the cloning process. This is definitely a useful setting, although a more fine granular control per pool would be desirable.
Fine-tuning the desktop usage
It is all about making a couple of decisions on how the desktops should be operated:
This is really the first question you should find an answer to. Do you want your desktops always alive so that you can reach them for upgrades and patches or is it not important. Or is it more important to safe memory consumption by suspending unused desktops. It depends on how you are intending to operate your desktops.
The actual parameter that defines whether machines are always running or just running when assigned to a user is kind of hidden in the VM configuration. You find the setting under Options/Powermanagement that defines how a VM should behave, when the guest is placed into standby. The Virtual Desktop Connector uses this setting to make the general decision, whether VM should always be powered on and running or be suspended when not used. And this applies from the creation throughout the recycling process until the VM is deleted.
Snapshot or Reuse?
This is a very straightforward decision. If the snapshot policy is selected, all VMs will be 'snapshotted' before leaving the factory. At the moment when VMs are recycled, a 'revert' to the previous snapshot will be performed. This implies, that the VMs have always a clean state before they get into the next user's hands. But there is also tradeoff that more storage is required for the snapshot.
On the other hand if you select the reuse policy, the desktop will always be treaded 'as is'. That means for recycling, that a the desktop will simply be taken away for the current user and is made available to others. If there is still a user logged into the desktop, then this will create of course, problems.
Here is the idea that the desktop created in the factory can be used once and is afterwards deleted. So users always get a fresh desktop and once they are done or the desktop is marked for recycling, then the desktop is deleted and the user will get a new one next time.
Recycling is initiated when?
The VDC talks about an 'Idle Timeout'. This setting defines the duration that a desktop can stay with a user although the desktop is definitely not used. Beyond that duration, the recycling process kicks in and the desktop is taken away from the user. And a machine is definitely not used either when the user isn't logged into the Windows guest or the Windows guest is in standby mode or the VM is in suspended mode. In all these situations the desktop is marked idle.
Note: On Windows Vista there is a restriction, that only the logout situation is recognized by the VDC.
Desktops can expire
The administrator has the option to define the maximum age of desktops. Once the maximum age is reached, the desktops older than the maximum age are deleted. Again, very straight forward. The only thing you have to keep in mind is that desktops, that are currently assigned to a user, are not deleted. Only available desktops are immediately deleted once they have expired. Intention is here to not impact running sessions so that users do not loose part of their work.
That's roughly it. There are of course more screws you can use to fine-tune the lifecycle, like e.g. using group policies (GPOs) to force a logout of users after a certain amount of time and my other things. But there is one thing you really have to keep in mind, time and time synchronization is key. Otherwise a lot of unexpected behavior could happen.
In my next article about the desktop lifecycle I will discuss a few use cases that apply the lifecycle in different ways.
Wednesday May 14, 2008
By MrDGrobler on May 14, 2008
Yesterday I wanted to prepare for yet another demo (YAD (tm)) of Sun VDI 2.0. After not having touched my demo setup for a while I've figured out it is time for a change. So update to the Windows XP SP3 and what I always wanted to do, install LSI Logic as SCSI driver, because it is supposed to have better performance than the Bus Logic one.
And as usual, it took more time than anticipated. First I've downloaded the LSI Logic driver as recommended in Warren's XP Deployment Guide. I've downloaded as recommended the LSI 53C1030 driver, released on Dec. 10th, 2007.
I've tried to install the driver as a floppy image during the setup process (F6 to include external drivers), I've tried to add the driver into the ISO with nlite. No success. Looking at the forums everybody seems to be happy with the install procedure and be more successful than me. Hmm ...
Then I stumbled over a VMTN thread describing the exact same problem. Resolution is to use an older version of the LSI driver. This driver version is posted on the thread as well.
Afterwards the install went reasonably well. Only problem I had thereafter, that I couldn't establish a RDP connection on a recycled VM. The Windows Event Viewer just displayed: "Event ID 50, TermDD error".
Carsten T. in our group reported that problem earlier with the following resolution:
You just need to remove one registry key in the template and than you should be good to go:
1. Start Registry Editor.
2. Locate and then click the following registry subkey:
3. Under this registry subkey, delete the following values:
. X509 Certificate
. X509 Certificate ID
Long story short: Demo went well, customer happy!
Monday May 05, 2008
By MrDGrobler on May 05, 2008
With smart cards VDI on Sun Ray works quite well as the association of VM's to a Sun Ray session is triggered by the smart card. But what do you do, when your customer doesn't want to use a smart cards?
For that case Sarah has created simple, sample VDI session type, that doesn't require smart card access. This session type invokes a login dialog initially. After the user has provided the credentials it triggers the usual lookup process through the vda-client and brings up the Windows session, trying to authenticate the user instantaneously.
As usual, your feedback counts.
Monday Apr 28, 2008
Friday Apr 18, 2008
By MrDGrobler on Apr 18, 2008
Quite a few customers are interested in an integration of the Provision Networks broker and Sun Ray. And the only thing they really need is a specific kiosk session type and a login sequence against the Provision Networks broker. The rest is nearly identical with the way the Virtual Desktop Connector works.
So Sarah from my team has created a new session script for Provision Networks. You find it in the pnclient.tar.gz tarball. The installation is straightforward and can be done with a few steps. Look into the README for further details.
After installation and configuration users get a simple login dialog, where they have to specify username, password and a domain. Upon successful connection the user will be directly routed to their desktop. If there are multiple desktops defined, the first desktop on the list will be selected.
That's it. Note, that this is not a supported session type. But it is simple and should help you getting started and expand from here.
Thursday Apr 17, 2008
By MrDGrobler on Apr 17, 2008
Monday Mar 17, 2008
Wednesday Feb 27, 2008
By MrDGrobler on Feb 27, 2008
Did you see this announcement? Finally we have a proper relationship with VMware.
Friday Feb 22, 2008
By MrDGrobler on Feb 22, 2008
Today I'd like to expand on the idea of automatic deployment of a virtual desktop as introduced in the previous article. The good thing about a virtual desktop or a virtual machine in general is the fact, that the virtual machine is just comprised just by a bunch files, that can be copied relatively simple. And this is the basis for the automated deployment: Copying files and making them unique in the network. This is of course a bit too simplistic, so let's see how the process really works. First of all look at some ingredients of the virtual desktop lifecycle:
A template is a virtual machine that is configured in a way, that it can be replicated or in virtualization words, cloned. A template is nothing else than a golden image or golden master, terms that are used in the traditional PC deployment. This template needs to contain all the applications and settings you want your users to use. The only specific pieces to desktop virtualization are, that tools like the VMware tools need to be installed on top. And typically a set of tools for the connection broker as well. For the Sun Virtual Desktop Connector (VDC) these are the VDC tools. And then you need to prepare the virtual desktop template, that it can serve the Remote Desktop Protocol (RDP). This includes enabling the terminal services, opening the firewall for RDP and finally making sure that users have permissions to connect remotely to instances cloned from the template.
System Preparation (sysprep)
System preparation is the task you have to initiate after a template has been cloned. Main purpose is to create a unique instance of Windows that can be identified in the network. This includes the name of the instance, the registration in the Windows domain, network parameters as well as applying licenses and the activation of the Windows instance. And a whole bunch of other things. You can find lot's of articles on sysprep. Here is one that provides a bit more detail on what sysprep is, specific to Windows Vista though. You find similar documents on Windows XP as well.
Creating a virtual desktop automatically and giving users access to it somewhat implies that the administrator does not necessarily know, which instance of the virtual desktop is assigned to a certain users. In other words a user will get access to a desktop in the data center, that is not personalized for him at all. But that's not what users usually expect. They need to be familiar with their desktop. The Windows way of addressing such a requirement is called 'Roaming Profiles'. Roaming Profiles is a mechanism to store user preferences for the desktop and applications as well as user documents in a network folder. At the moment a user logs into a desktop, his roaming profile residing on the network is copied to the local machine, in our case the virtual desktop. When the user logs out, his profile is written back to the network location. This is a common mechanism, which has the drawback of slowing down logins and logouts when a lot of data need to be copied or the network storage access is slow. 'Folder Redirection' is another mechanism to improve the situation, by redirecting some folders, like the 'My Documents' to network locations. This mechanism avoids that data is copied back and forth between the virtual desktop and the network folder. The users data is simply fetched from the network location, when needed. This reduces typically the login time. There are plenty of articles out explaining this mechanisms, here is one for more detail.
The Lifecycle (Produce - Prepare - Recycle - Retire)
After talking about the prerequisites let's have a look on how the virtual desktop lifecycle works, in general. Fundamental to the idea is the desire to create a number of virtual desktops that are configured in the same way. These desktops should provide desktop sessions to users, that are completely isolated from other user desktop sessions. Which is the big difference if you compare this concept with Windows Terminal Services (WTS), where desktop sessions are not isolated from each other.
The container for these virtual desktops is called a pool. The pool is populated through a single virtual desktop template. The figure below illustrates the whole process:
The process begins with the cloning of new virtual desktops based on the template that has previously been created by the administrator. Cloning means that a copy of the whole virtual desktop is created which includes the virtual disk as well. Usually the clone consumes the same amount of disk storage as the template. Note: There are already storage systems out with a copy-on-write technology. Only differences are stored, which makes the cloning process instantaneous.
After the cloning process is complete, the instance of the virtual desktop is 'syspreped', meaning it is getting its own network identity and other settings different from the template. This production task of cloning and 'syspreping' can definitely take several minutes, depending on the size of the template, performance of the network and the storage as well due to the time it takes to prepare a system, which can involve several system reboots. Once the system preparation is complete, the virtual desktop is made available to users. This whole production process is also summarized under the term virtual desktop factory.
When a user connects through a Sun Ray or a web browser and there is no Windows RDP existing for that user, the connection broker is contacted. If the connection broker finds out, that a virtual desktop has already been reserved for that user, a new RDP connection is opened. If no reservation has been done or a previous reservation timed out, a new available virtual desktop is requested from the pool.
But before the requested virtual desktop can be handed out to the user, the connection broker needs to ensure that the virtual desktop is fully accessible. This includes starting the virtual desktop, e.g. if it is suspended or stopped for resource optimization purposes. It also needs to ensure that all the services of the virtual desktop are up and running, especially the terminal services need to be up and running on the virtual desktop. Once all checks have been successfully passed, the virtual desktop is handed over to the user. Thereafter the user can login to the desktop, his roaming profile might be synchronized and finally the user can begin his work.
Typically, as long as the user is actively using his virtual desktop, he owns it. But the administrator has the possibility to define, what should happen, when a user hasn't used his reserved virtual desktop for a defined period of time. This might be triggered through a logout of the desktop or just through leaving the virtual desktop idle with a subsequent standby of the virtual desktop. Both events can start a timer, which possibly triggers a recycle or a retire action.
Recycling means that the virtual desktop is returned to the list of available virtual desktops. And here the administrator can choose between a cleanup of the virtual desktop or just a handover as is to the list of available desktops. A cleanup is desirable if idle desktops are returned, where the previous user might still be logged in. The cleanup can actually be implemented through snapshot and revert technology. This happens in a way that a snapshot is taken of virtual desktops before they leave the factory. Thereafter a revert is initiated as part of the recycling process, which cleans up all modifications done by the previous user.
In other situations it might be sufficient to leave the desktop as is and return it immediately to the list of available virtual desktops. This is useful when the Windows desktop is configured for a kiosk mode operation and/or when the recycle process is only triggered by a logout of the user. In both cases there is no session state to revert, but the virtual desktop might still contain some data of the previous user that is neglectable.
The remaining action as part of the virtual desktop lifecycle is the action to retire a desktop. And there are two scenarios that can trigger the retirement of a desktop. The first one is that the administrator has configured virtual desktops for one time usage. After the first usage virtual desktops are not recycled but immediately destroyed. This is very similar compared to recycling with snapshots. However there are performance consideration that make the immediate retirement desirable. The VMware platform for example does not allow life migration of VMs with snapshots. It also takes noticeably longer to startup or resume a VM based on a snapshot. Another reason might be that the template of the pool is refreshed quite often and there is the desire to present always up-to-date copies of the template to the users.
Another reason to retire a virtual desktop is that instances simply expire after a certain amount of time. This mechanism can be used again when templates are regularly updated. In this case users also need to work with clones of the latest version of the template.
I'd like to wrap up at this point. You have hopefully now a better picture of how the virtual desktop lifecycle works, in general. In my next article I will focus on how this is implemented with the Sun Virtual Desktop Connector 1.0. And well, let me know if there's something unclear or you have suggestions to improve. Your feedback is welcome.
Wednesday Feb 13, 2008
By MrDGrobler on Feb 13, 2008
Monday Feb 11, 2008
By MrDGrobler on Feb 11, 2008
Friday Jan 18, 2008
By MrDGrobler on Jan 18, 2008
I have been for 2 days in Grenoble this week, participating at the Identity/Desktop event. That was really good. Lot of interested folks around, a bit more than a hundred I guess. And there was a considerable interest in VDI, also not too bad as this was my topic to cover. I got a lot of tough questions around the architecture, what is possible and what not. And finally people are pretty eager to see the final release of the Virtual Desktop Connector. I promise, we are working hard on it.
Many thanks to Dominique for organizing this great event.
Wednesday Dec 19, 2007
By MrDGrobler on Dec 19, 2007
It's time for Christmas lunch again. This is in the meantime a famous event, getting the Sun Desktop teams in Dublin together shortly before Christmas. I like this particular event as it starts early, well it's implied by the name. And it ends late, that is not implied by the name. There must be other reasons, why it is usually taking that long. Besides the Christmas lunch we have still a lot on our plates that need to be completed.
Number 1 is the Beta of the Sun Virtual Desktop Connector (SVDC). This beta is still running. Many people are very busy these days in closing the year, but some are not. So, if you have the time, give it a try. It is really an improvement compared to the previous version, the VDAK. Install and configuration is much simpler.
And besides the beta, we are fully focused on delivering the final version, getting it into a proper shape. See you in the next year, earliest opportunity is the event in Grenoble, that ThinGuy already mentioned in his blog entry. I will dive into the details of the SVDC. How it installs, how it can be configured and more details on how it works.
This one is about VDI, Sun Ray, SGD and sports, in particular basketball, and any combination of it. And of course other interesting stuff.
- Oracle VDI 3.2.1 available for download
- Back on the blog - VDI Forums
- VDI 3.1.1 has been released
- Application streaming
- VDI Image Layering
- Untold secrects about Sun VDI 3.1: Surving without a directory
- Understanding people from South Sweden ...
- Point and Shoot Sizing: Sun VDI 3.1, Sun VirtualBox 3.0.12, Sun Fire X4170
- The hidden major update: Sun VDI 3.1
- Sun VDI for the Education Market