Jumping VDI

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:

Staying alive?
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.

Disposable desktops
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.

- Dirk

Technorati Tags: sunray, vdi