RDSH session live migration: One last look

For nearly 20 years, the live migration of RDSH sessions has been out of reach, and when it became feasible the world was focused on VDI. Is there still a place for it in today's world, with workloads moving to the cloud and a new, usage-based cost model?

In 2013, Brian wrote an article asking if it's "too late for Terminal Server live session migration," which has been on the desktop virtualization administrator’s wishlist since back in the 1900’s. Until recently, it was always thought of as a pipe dream–the kind of thing you and your buddies would start wishfully thinking about at the bar after a long day of attending Synergy sessions.

We thought it would be useful, for a number of reasons. Primarily, they were:

  • On-premises environments could use it to consolidate sessions to a smaller group of servers so the rest could be powered down.
  • Problem users could be migrated to different servers so that they don't affect the performance of an entire server's worth of users.
  • Systems could be patched/rebooted with zero downtime for users.

By the time we got to the point where it might be possible to do, virtualization had begun to take hold and our focus shifted towards VDI. By the time VDI was ready for the masses, we weren’t thinking about individual RDSH sessions, we were thinking about individual, virtualized Windows desktops, and those could be live migrated at the hypervisor level.

The idea of live migrating RDSH sessions fell by the wayside, though it has come up from time to time. In the 2013 article, Brian wrote that he’d talked to a group of people that said they could make it happen, so he asked the community what they thought. In general, the comments on that original article agreed that it was probably too late:

  • Some of comments indicated that VDI made the problem go away
  • Others said that Moore’s Law and improvements in hypervisor technology enabled cost-effective use of single-user VMs, so it was a non-issue
  • Shawn Bass (before he was VMware’s EUC CTO) said it was possible but difficult, depending on the application architecture. VMs are easy enough because you preserve the memory and network state during migration, so apps can stay connected, but to do so at the application level would require something like a load balancer VIP to maintain the connection with the backend when the session moves.
  • Several others thought it would still be nice to have, but not the game changer it would have been 10 years earlier.

With that in mind, I want to look at the question through 2017 goggles. Has enough changed to make this concept more achievable / valuable than it was in 2013?

What’s changed?

When that article was written, certain things had yet to happen:

  • Citrix hadn't killed off XenApp as a standalone product, then brought it back because customers were not happy.
  • VMware was still poo-pooing applications (and deriding Windows overall as "legacy"), only to come around years later with Horizon Apps and a renewed focus on Windows.
  • VMware had yet to release NSX, which kicked off the Software-Defined Networking rage.
  • DaaS and cloud-based desktop virtualization had not yet gained widespread attention (we wrote our DaaS book in 2014, and that was even a bit early)

Essentially, in 2013, VDI was still the sexy thing that everyone wanted to do, so both VMware and Citrix tried to capture that market. The move to roll XenApp into XenDesktop was an awakening, though, because while VDI got all the buzz, it turns out a huge portion of customers were running RDSH, too. Though Moore's Law and virtualization improvements have lessened the price gap between VDI and RDSH, that high number of people that just want to use RDSH remains today. According to the VDI Like A Pro survey from earlier this year, nearly the same percentage of companies use VDI (77%) as RDSH (78%), with the average overall distribution of each technology within organizations at 58% for VDI and 42% for RDSH.

Also, in the same four-year span, the way we look at our applications and infrastructure has changed. Organizations are turning to the cloud in droves to build infinitely scalable application and desktop platforms. And, above all, application development has shifted from traditional Win32 apps to other, more modern platforms like SaaS and web (and even mobile).

That said, we still have loads of WIndows apps. For the most part, those are still run on-premises, but increasingly companies are using public cloud providers. With that move, customers are faced with different economic incentives. For example, since the cloud is a pay-as-you-go environment, the costs incurred by delivering full Windows desktops on a dedicated virtual instance to end users could become more expensive than servicing the same users with RDSH-based applications/desktops on a shared virtual instance.

Last, our ability to control networking has never been better. For example, software-defined networking has enabled way more customization both on-premises and in the cloud than we ever thought we'd get. If (and I'm drifting way outside my lane here, so this might have already been done or has already been deemed impossible) session information can be used to route traffic, I can see a situation where network connections between the client application and the server can follow each other.

Why RDSH session portability might be useful today

The classic reasons for RDSH Session Portability from the beginning of the article still apply, for the most part. In addition to all of those, increased use of the cloud means you can also make a strong financial case for session portability. As I mentioned above, the pay-as-you-go cloud model favors density, meaning a single, expensive RDSH server loaded with users probably costs less than an individual VDI instance for each user, especially when you factor in unused resources multiplied by each VDI instance.

While that might make sense at 100% load, what happens at the end of the day when 75% of the people have logged out? With VDI, perhaps those individual instances are shut down, but in an RDSH environment those expensive instances are up and running with a small number of users on each one. This is where it would be great to be able to automatically consolidate individual RDSH sessions and spin down unused instances.

Current approaches to doing this notify the user that they need to log out and back in, which isn't exactly the best user experience and results in downtime. RDSH session portability ensures continuous work while also saving what could be significant amounts of money.

So...are you saying there’s a chance?

In 2013, it was easy to say "Eh, we'll just take care of this with VDI," because VDI was finally coming together after years of struggling with storage, graphics, and high costs. That's still true–VDI works now–but we're not moving in that direction as fast as we used to be. The focus on SaaS and cloud apps means that we're relying less on the Windows desktop because we have fewer Windows apps. And, if we don't rely on the desktop, it doesn't make sense to spend money to deliver the desktop when all we really need are the applications.

With that in mind, what do you think? Should we finally put this idea to rest forever, or is there still a potential need for RDSH session portability, especially as the need for RDSH increases over time? It certainly wouldn’t be the earth-shattering, gee-whiz feature that it would have been fifteen years ago, but it still might be useful.

Join the conversation

3 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Of course, session portability would be useful. Things don't need to be disruptive or gee-whiz to be great. Enterprise administrators don't care about shiny things when they want to get things done. 
Cancel
As far as I'm concerned with Xenapp on Azure, it's a requirement now unless M$ wants to just kill us with usage charges on farm workers.  The savings would be enormous for the system to be able to upsize and downsize itself automatically based upon some simple rules you could setup.  Even large onprem customers would benefit from this being able to spin up and down vm's as needed, move them around the cluster, etc, etc.  Honestly I don't see it being real difficult today, but I don't write code either. 
Cancel
It seems to me if you can take some of the technologies from Docker and AppV (app and memory isolation) plus the networking state and migrate it, that would be a nice feature to have.
Cancel

-ADS BY GOOGLE

SearchVirtualDesktop

SearchEnterpriseDesktop

SearchServerVirtualization

SearchVMware

Close