Today is a huge day for desktop virtualization. Microsoft, Citrix, and several other partners are announcing a slew of new things specifically related to desktop virtualization, and we'll dig deep into each of them over the next few days. There's even a dedicated website, DesktopVirtualizationHour.com, setup for the announcements.
The first announcement we'll dig into today is that Microsoft's Calista-based graphics remoting capabilities will be called "RemoteFX" and shipped as part of SP1 for Windows 7 and Windows Server 2008 R2. I've written quite a bit on Calista in the past, including Microsoft's purchase of the company over two years ago and some updates (1, 2) on their progress along the way.
For those who don't know, RemoteFX is an enhancement to RDP's graphics remoting capabilities. The goal of RemoteFX is to deliver the full modern Windows desktop experience—including multiple displays, Aero, and multimedia—to all types of client devices including very thin, sub-$100 thin clients. RemoteFX does this via a technique known as host-based rendering, which means the entire final composited screen image is rendered on the remote host and then compressed and sent down to the client. (In effect this moves more computing into the datacenter and lessens the importance on specific client devices or client specs.)
Fundamentally RemoteFX is just a codec (like H.264) that's been written for real-time encodes. (H.264, on the other hand, is meant for content that can be pre-rendered not in real time, like TV shows and movies.)
There will be several initial ways RemoteFX will function once it's released, including:
- Full software-based encoders on the host.
- a GPU/CPU-based encoder (with extensions to Hyper-V to let GPUs be shared between multiple VMs).
- A custom chip-based encoder, either on a plug-in card or built-in to the host.
Similar variations will exist on the client side, with traditional PCs being able to decode RemoteFX fully in software (either running on the CPU or, if available, the client GPU). There will also be options for chip-based plug-in cards to fully offload the decoding from the client CPU, and new lines of thin client devices with the decoding circuitry built-in to their hardware.
Microsoft has stressed that the RemoteFX codec is the same regardless of whether it's running in software on the CPU, the GPU, or a custom plug-in card. And any client/host combination of software, GPU, or plug-in card will work, because the data on the wire is the same regardless of how it was created or how it's being decoded. (I visited Microsoft's Silicon Valley Campus earlier this week and recorded a video demo of RemoteFX in action on several clients.)
As I briefly mentioned before, RemoteFX is just an enhancement to RDP's virtual channel that handles graphics remoting. It's not a replacement for RDP. This means that all the "other" RDP characteristics and capabilities are the same. (Same ports, same encryption, same printing and client device remoting, etc.) It also means that you don't have to have a RemoteFX-enabled client to connect to a RemoteFX-enabled host as the client and host will auto-negotiate their capabilities (or lack thereof) around RemoteFX just like any other RDP component.
The first implementation of RemoteFX will be focused on LAN scenarios, which is code for saying it takes more bandwidth than RDP's traditional client-based rendering and doesn't like latency. Microsoft has said they'd like to (or enable partners to) extend RemoteFX to work in WAN scenarios, although they also point out that there are already ways to handle the WAN with traditional RDP, so the ultimate WAN solution might be RemoteFX or might be traditional.
Microsoft hasn't announced a ship date for RemoteFX yet, although they said it will be part of Service Pack 1 for Windows 7 and Service Pack 1 for Windows Server 2008 R2 (for Hyper-V and Remote Desktop Session Host). So I guess as soon as we get a ship date for SP1 then we'll know when we get RemoteFX. (Oh, and what ever happened to Service Packs not adding capabilities?)
Make no mistake: RemoteFX is about Hyper-V
In order for a remote Windows 7 VM (i.e. VDI) to use RemoteFX, that VM MUST be running on Hyper-V. Period.
At first you think this makes sense, since the new (SP1) version of Hyper-V is needed to virtualize and share GPUs between multiple guests. But then you think, "Wait a second... Isn't there a software-only encoder for RemoteFX?!? If so, then why do I need Hyper-V? Couldn't I just run the software-based encoder inside my VM on ESX?" And actually RD Session Hosts (Terminal Servers) can run on bare metal and still host RemoteFX sessions. (Presumably with the software-based encoder, although it will be interesting to see whether they can leverage GPUs or add-in cards across sessions.)
Even if you could theoretically run the software-based RemoteFX encoder inside a Windows 7 VM on a competing hypervisor, Microsoft is not allowing it. (We'll have to wait and see what the EULA for Win7 SP1 says to see if this is a licensing thing or there's a technical reason it can't happen.) [UPDATE: It just occurred to me that maybe the software-based encoder still needs that virtual GPU, and maybe the TS bare metal use case works only when there's a physical GPU. I guess we'll see?]
Either way, it's clear (and Microsoft fully admits) that the RemoteFX is all about pushing Hyper-V. So if you want RemoteFX for VDI, you need to run your VMs on Hyper-V.
And true to their "platform" role, Microsoft doesn't even care whose desktop delivery stack you use (as long as it's on Hyper-V). They're making the RemoteFX capabilities (on both the host and client side) available just like any other platform capability, so partners will be able to embrace and extend them as they see fit. In fact Citrix has already announced that they'll ship a RemoteFX-enabled HDX (ICA) stack six months after Microsoft ships RemoteFX. So imagine that. Citrix used to be 100% agnostic when it came to the hypervisor that powered XenDesktop (and in fact most XenDesktop deployments are on ESX). But now there will be a real reason to run XenDesktop on Hyper-V. Doing so will give capabilities that don't exist on XenServer or ESX.
How will VMware respond?
Obviously RemoteFX and PC-over-IP are similar in many ways. Both promise rich media to thin clients with most of the work being done on the host side. Both offer bandwidth scalability (with RemoteFX falling back to "traditional" RDP and PC-over-IP scaling back its dynamic quality). Both offer combinations of hardware- and software-based encoders and decoders.
Right now it looks like RemoteFX is more flexible (in terms of hardware/software combinations) than PC-over-IP, but I would imagine that VMware's already working on a similar capability for ESX where they too could virtualize and share GPUs among guest VMs. And since they already did that massive port to move PC-over-IP from hardware to software, I would imagine they could tweak their software implementation to work well on virtualized GPUs, perhaps giving a better experience or at least allowing PC-over-IP encoding to be offloaded from the CPU cores which should allow for better VM density.
If I was at VMware right now I would just move PC-over-IP out of View and into ESX. Make PC-over-IP part of the ESX/vSphere platform and make it available to any VM running on ESX--so then a Citrix XenDesktop customer could get RemoteFX if they chose Hyper-V and PC-over-IP if they chose ESX. (Hey wait.. isn't this exactly what we wrote in November with our article "Is the future of remote display protocols based on hypervisor integration?") That will put the final nail in the "remote protocol is a commodity" coffin and then we can all move on.
We're just scratching the surface of RemoteFX now, so keep an eye out over the next few weeks for more discussion and analysis of what this means. In the meantime, what do you think?
Also: Check out the video I recorded of Microsoft's Tad Brockway explaining RemoteFX and showing it on a few different clients.
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.