Original URL: https://www.theregister.com/2012/05/15/stateless_vdi_deployment/

The key questions you must ask to save your virty desktop dream

Shifting to stateless? Don't turn it into a nightmare

By Trevor Pott and Iain Thomson

Posted in Systems, 15th May 2012 15:03 GMT

Sysadmin blog What is required for a successful stateless desktop deployment? Planning. Every implementation will be different, and experience has taught me that there are very few hard and fast rules.

Stateless desktops are non-persistent, meaning that they get destroyed every time the user logs off and returned to a known setup. Proper stateless VDI isn't a matter of using a specific tool, buying a specific program or using a specific configuration. There is no magic formula, and you will run across the long tail of end-user application issues eventually.

Your user is not sitting in front of a physical piece of hardware that will continue working when $remote_element ceases to be accessible, so what does that actually mean for your user? Everything else proceeds from here.

The first step of any desktop deployment is desktop configuration. Patches, security, application deployment. Things hammered out over decades in the stateful desktop world become complicated in a stateless environment.

Even the simple act of applying a configuration to your virtual machine has to be considered in the context of remote system accessibility. If your configuration server is down, can you still apply a configuration? How? Will it use last known good? How does it know what last known good is?

In a persistent (stateful) VDI deployment, scripts or configurations could be kept local to the virtual machine, with a background process periodically polling a centralised server of some variety to check for updates and changes. (Microsoft's GPOs work in this fashion.)

In a non-persistent (stateless) situation, where are the configs coming from? Are they baked into the template? Does your template call out somewhere to look for updates since the last time you rolled it? What if that update source is down?

The issues cascade from here. How does your configuration apply? Does it call other servers? Do those server calls rely on DNS? If they don't, how do they handle readdressing situations?

What about IPv6? Are any calls you are making to update or configuration servers capable of dealing with autoconfig problems? Do they separate link-local addresses from other addresses which might lead you to the same machine, but an interface (or address) on that machine whose firewall state is unfriendly?

What IP address will your config calls be coming from? How will the config servers treat them? If your VMs are truly stateless, they will not be using static addresses; rather, they will grab one from among a pool of possible addresses.

How many of what kind of firewall sit between you and the information you need in order to ensure that your newly spun up VM is as up-to-date as it needs to be?

Redundancy is key. When planning a stateless VDI deployment, starting your planning by asking the question: "If absolutely everything is broken, now how much of this works?" is far more critical than the same question might be when planning a static VDI or traditional desktop environment.

Establish a minimum required set of services and features to be online and running in order to serve your product/service to the end user. In the case of a remote desktop, there needs to be – at a minimum – a path from the remote desktop to the user. If that doesn't exist, the entire exercise is moot.

Assuming that this minimum threshold is indeed met, what happens if everything else is broken? If your user can log into the system, and every other back-end server and service you would ordinarily rely upon is down, what happens? How does your stateless desktop environment respond?

The tools you choose will be a function of the specific environment issues at hand. This makes stateless VDI deployments difficult in established IT environments; far too often issues are dealt with in the order that the tools at hand can address them.

In a stateless VDI world, configuration and deployment aren't separate and distinct from change management. If you wander down the path towards stateless, no-persistent VDI, be prepared to embrace a far more holistic approach to IT. In a stateless world, the end VM is merely a visible resultant piece of a much greater whole. ®