Feeds

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

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

Secure remote control for conventional and virtual desktops

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. ®

Secure remote control for conventional and virtual desktops

More from The Register

next story
Ellison: Sparc M7 is Oracle's most important silicon EVER
'Acceleration engines' key to performance, security, Larry says
Oracle SHELLSHOCKER - data titan lists unpatchables
Database kingpin lists 32 products that can't be patched (yet) as GNU fixes second vuln
Ello? ello? ello?: Facebook challenger in DDoS KNOCKOUT
Gets back up again after half an hour though
Hey, what's a STORAGE company doing working on Internet-of-Cars?
Boo - it's not a terabyte car, it's just predictive maintenance and that
Troll hunter Rackspace turns Rotatable's bizarro patent to stone
News of the Weird: Screen-rotating technology declared unpatentable
prev story

Whitepapers

A strategic approach to identity relationship management
ForgeRock commissioned Forrester to evaluate companies’ IAM practices and requirements when it comes to customer-facing scenarios versus employee-facing ones.
Storage capacity and performance optimization at Mizuno USA
Mizuno USA turn to Tegile storage technology to solve both their SAN and backup issues.
High Performance for All
While HPC is not new, it has traditionally been seen as a specialist area – is it now geared up to meet more mainstream requirements?
Beginner's guide to SSL certificates
De-mystify the technology involved and give you the information you need to make the best decision when considering your online security options.
Security for virtualized datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.