When I wrote about Net2Display's 1.0 specification release last week, I reached out to several different industry experts and committee members for opinions to include in the article.
When I wrote about Net2Display’s 1.0 specification release last week, I reached out to several different industry experts and committee members for opinions to include in the article. One of those folks was Desktone CTO Clint Battersby. In addition to providing comments about Net2Display, he made some off-the-cuff remarks about his thoughts of how remote protocols could evolve. I mentioned some of his remarks in that Net2Display article, but I think they’re interesting enough to warrant their own conversation.
So welcome to Brian’s interpretation of Clint’s protocol thoughts!
Clint’s opinion is that the real opportunity and proper packaging of remote display protocols is integrated with the hypervisor, just like VirtualBox does with RDP and Qumranet does with with Spice. He claims doing so provides three advantages:
- Guest OS independence, since no guest OS software is required
- Much closer to normal desktop experience, since you watch the machine boot
- Eliminates the complex feature matrix in current protocol/guest OS/client device implementations
Again, these were just side comments that Clint made, so I want to add on to the conversation from the perspective of refining his initial thoughts rather than calling him wrong.
So after thinking about this a bit more, I’m not so sure about Items 1 and 3, because there could be situations where you would want an a component of the protocol agent inside the guest VM. (This is what Qumranet does with spice.) So in that case you’re actually moving to a three-tier protocol approach, with a guest VM component, a hypervisor component, and a client component.
That said, another advantage of this is performance. Once of the reasons Qumranet claims to get the spice performance that they get is because they can dedicate cycles to protocol remoting outside of the guest VMs, where resources and be more appropriately allocated. (And think about the future potential for this to leverage GPUs, PC-over-IP chips, Calista chips, etc.)
A final advantage occurred to me when Client references these as “remoting protocols” versus the term “remote display protocols” that I used. Clint’s term reminds me that these are about more than just display. They’re also about client devices, peripherals, USB, etc. And since that’s something that has to be emulated, paravirtualized, or passed-through to the guest anyway, I would think that hooking that hypervisor up with the remote protocol engine could make some cool things happen here?
Regardless of the specifics, I think there’s a lot of potential here. Let’s step through the protocol / hypervisor combinations one-by-one.
Citrix ICA/HDX & XenServer
Clint said that he was surprised that Citrix didn’t integrate ICA into a commercial version of XenServer within six months of acquisition.
I think that would be cool for XenServer, although it would be tough for XenDesktop because it would probably make it platform-specific.
Then again, the HDX 3D that leverages the Nvidia CUDA-based GPUs is kinda sorta moving in this direction anyway, so that could always be an option.
Red Hat / Qumranet Spice & KVM
Clint wrote that he’s disappointed we have not seen or heard much regarding KVM/Spice in a long time.
Microsoft RDP/Calista & Hyper-V
Clint wrote that while there’s no official word from Microsoft about RDP 7/Calista integration with Hyper-V, he feels that would be a huge win given the broad availability of RDP on client access devices.
I know Microsoft hasn’t released too many details about Calista yet, although we do know there will be a few modes of operation, including sharing physical GPUs across multiple VMs and creating multiple virtual GPUs for VMs when real GPUs don’t exist. I would expect that both of those would only work via Hyper-V. The question is whether that would be an RDP-only thing, or if companies like Citrix would be able to leverage those capabilities via ICA if they run XenDesktop on Hyper-V.
VMware / Teradici PC-over-IP & ESX
Clint wrote that VMware appears to be on the right track integrating PC-over-IP with their ESX hypervisor but, we’re still waiting for a production release of the entire stack.
I don’t really have any more info than that, but I definitely need to learn more about how VMware’s software implementation of PC-over-IP actually works. Are they emulating a terachip? If so, is it in the VM or the host? Or did they rewrite that code to execute natively? And where?
So lots of questions still.
Net2Display & the open source Xen or KVM
Clint wrote that he believes the best opportunity for Net2Display given the backdrop of hypervisor / protocol wars brewing would be to integrate with an open source version of XenSource and/or KVM.
Seems like a good as plan as anything for them as far as I’m concerned. I’m really not excited about Net2Display anymore, so I don’t even know if I care what they do. Maybe I’m just impatient.
So there you have it. What are your thoughts? Does integrating the remoting protocol with the hypervisor make sense? Which vendors have the most to gain? Who’s got the most to lose?
[TECH NOTE: We're continuing the experiment of doing an audio version of our article. You'll find a link at the top of the article near my avatar for an MP3 attachment. If you're accessing the RSS feed of this article, the attachment will be recognized as a podcast.]