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.