Is it too late for Terminal Server live session migration?

Back in the late 1990s and early 2000s, most of us in the SBC space dreamed of a Terminal Server feature called "live session migration." We wanted to be able to take a fully running user session from one server and instantly and transparently move it to another server.

Back in the late 1990s and early 2000s, most of us in the SBC space dreamed of a Terminal Server feature called "live session migration." We wanted to be able to take a fully running user session from one server and instantly and transparently move it to another server. Unfortunately this feature never existed, and now that most of our RDSH and XenApp servers are virtual (with live migration capabilities), most of us forgot about our single session migration dreams.

A few weeks ago I had some beers with a couple of guys who talked about how live session migration for XenApp/TS/RDSH would actually be possible to do. They asked me if I thought they should build it into a product or if it was too late. I figured this would be a good idea for an article and an interesting conversation, so let's look at this today.

Why would you want live session migration?

The ability to move a live user session from one Terminal Server to another was huge in the days of physical servers. We liked this concept for several reasons, including:

  • Towards the end of the day when you only have a few users left on each server, you could consolidate your users to a single server and power down the rest.
  • You could move a "problem" user from one server to another. (For example if one user is taking up too much CPU, move him to a server that has more available.)
  • Move users off of servers that need to be patched in order to provide 24x7 computing with no downtime.

Do we still need this today?

If this Terminal Server live session migration capability was suddenly available today, would we care? It could be interesting:

  • Live migration allows us to move entire VMs from host-to-host today. With RDSH / TS / XenApp servers, sure we can consolidate users onto fewer physical hosts, though it's still not as efficient since there's a lot of extra overhead for each VM. Or do Moore's Law and the efficiencies of today's hypervisors make this point moot?
  • Moving a problem user to a different server is still nice today, right? Or again, do Moore's Law and the protections built into current versions of Windows Server mean this isn't as important anymore?

And of course there's the whole trend I wrote about last week of single user desktop VMs potentially replacing RDSH / TS / XenApp sessions. If that happens then we essentially get "single user live migration" for free.

So what do you think? Would you like to see single user live session migration for RDSH / TS / XenApp? Or is it too late?

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Holy old topic revival Batman!  I remember requesting this feature more than 10 years ago.  It would have been cool then, but with hypervisor density from every major vendor improving with each release we kind of worked around it.  Single-user VMs (either workstation OS or server OS) is one way.  Also, when people virtualize RDSH/XenApp workloads, generally fewer sessions are hosted per VM.  So, planned downtime is easier to facilitate as the user impact decreases.


Forget about XenApp/RDS. They should build this for VDI and the desktop OS and leverage it as the ultimate personalization solution for all desktop OS user case including physical. Me want!


Its time has past. If they had it in 2003 we would have been excited.

Now... meh.

Do it on VDI.


I personally think there is a market for this still.  Sure, nowhere near as important as it was back then, but this would undoubtedly be useful for me if it was an easily implemented, inexpensive option.


VDI is excellent virtualized primary desktops, but I really think XenApp is awesome for application hosting.  XenApp's value is that it brings many of the features of a web app to a windows app.  One major feature that is lacking is user session portability.  Closing that gap would add tremendous value to those of us using XenApp to host enterprise customer-facing apps.


At this point, I think it would be a "neat" feature for XenApp that definitely has some value, but not a game changer.  I think it would give the most benefit to a VDI environment.  Particularly in scenerios where you are using local storage or are caching locally on the host in some way and cannot perform a live migration.


If you've seen where Microsoft are heading with Project Drawbridge, this would allow per-process live-migration on RDS.

Each process effectively runs it's own mini-OS (called Picoprocess) and you RDP into each sandbox to interact with the application. As each process maintains state within the picoprocess, it can be suspended, hibernated to disc, or live-migrated onto a different host.

Of course this is still a research project, but may well find it's way into a future version of Windows.

My own view is that live migration of individual RDS sessions has largely been negated by the development of the CPU and hypervisor features. One should no longer be having "problem servers" if you've properly provisioning your infrastructure via templates or PVS, and your physical "problem servers" can be evacuated at the VM level.


Lots of people have *thought* they could do it.  It's a rat-hole.


I think 5 to 10 years ago this would have been one of the best features available. I think there is still a requirement for it but it wouldn't be a killer feature like it could have been.

Still think it would be great to have. I know if some very large XenApp implementations on physical hardware.

I like the idea if sessions getting redistributed like VMWare DRS or consolidated at the end if the day.

If someone is thinking about building this as a 3rd party tool I'm wondering how XenApp would cope with the moving around of sessions.

Also, could a feature like this be used to lessen the impact of logins on session hosts? I.E dedicate some beefy servers that deal with logins and the uMotion (or whatever it would be called) the session over to another session-host for normal running?


From a user perspective, if you can wheel me around wherever you want without making me log off and then on again, I like that. I've got things to do.


I think some smart people have already been working on some underlying tech which may allow 'apps' to be migrated,

As Tim says, smart people have already looked at this and deemd it 'too hard',  but newer hardware technologies and initiatives from Microsoft like this one....

....could make it possible.

"As far as we know, Drawbridge is the first in this class to provide not just isolation, but also persistent compatibility and execution continuity. When packaged with its library OS, a Drawbridge application can run across many different host OS versions.  And, a running Drawbridge application can move from one host machine to another (without losing its state)."

That's a comment from one of the dev's on this team.


Doh, just saw that Neil Spellings posted something similar !!


@help4ctx Great minds...etc :)


Abstracted apps that can auto scale and leverage hardware as needed sounds good to me. This is much more than a XA/VDI conversation. It's about what future role an OS plays with future apps that can adapt and call resources as needed.


Funny I recall a BriForum a few years ago when Chetan (Atlantis) had discussed a similar idea to Drawbridge (only not as lightweight) and everyone dismissed it as lunacy.  I recall sitting in the audience saying that it made perfect sense to me given Moore's law and such, but that it was incredibly difficult to pull off.

Regarding the idea of session mobility, as we've discussed this many times before it's doable but very difficult and it depends on the application architecture.  The issue is that while you can live migrate a VM around because you are preserving the memory contents and IP addressing as you suspend/resume the entire OS, it is much more difficult to do at the user session layer with individual processes.  Some applications would be unaffected by being resumed on a new IP on a different host.  Other apps would implode.  You would almost need to create a load balancing style VIP to route your client/server communications through in order to maintain session state with back end systems.  Again, very tough thing to do.  For apps that didn't have any back end communications this is easier, but still not simple.