Yesterday Red Hat used what was arguably the worst-titled press release ever to announce that they are open sourcing their SPICE remote display protocol.
Yesterday Red Hat used what was arguably the worst-titled press release ever to announce that they are open sourcing their SPICE remote display protocol. SPICE was developed by Qumranet a few years ago and made a huge splash at BriForum in 2008 when they demoed the software-based SPICE protocol on a client with multiple monitors running high-def video, audio, and games. (Here are videos of their sponsored breakout session from BriForum 2008 and DEMO Lab product demo from BriForum 2009.)
Later that summer, Qumranet hired Gabe and I to perform an independent analysis of the performance of the SPICE protocol as it compared to RDP and ICA. We wrote a paper of our findings, although I don't know if they ever published that since a few months later they were acquired by Red Hat. (I think our main contact at the time had bigger items on his plate than our little protocol analysis.)
We wrote about that acquisition on BrianMadden.com, essentially saying that we thought the main reason Red Hat acquired Qumranet was for the KVM hypervisor (which would compete against the open source Xen hypervisor), and we weren't really sure whether Red Hat cared about desktop virtualization at all.
Fast forward to today: Red Hat has is evolving Qumranet's VDI product into Red Hat Enterprise Virtualization for Desktops (currently in beta), and they're converting SPICE to a full-on open source remoting protocol.
So SPICE is vendor-neutral independent remoting protocol that has the advantage of actually existing. What impact will it have? I guess that depends on how good it is.
How good is SPICE?
Is SPICE better than RDP? Will it give Citrix a run for their money in HDX/ICA? Did VMware just waste a lot of money on PCoIP? Is Net2Display even more worthless?
As part of the analysis we did for Qumranet in 2008, we recorded a bunch of videos comparing the performance of running a set of user scripts via three protocols: SPICE, ICA, and RDP. Our videos show SPICE in action against ICA and RDP, each for three use cases (single display, multiple displays, and multimedia apps).
One thing about the videos that's important to note is that our lab was a non-bandwidth constrained environment, so the bandwidth consumption data is not really valid. (Remember that any protocol will take up as much bandwidth as it can when not capped, so we were just trying to compare the architecture of the protocols back then—not do a full bandwidth analysis.) That said, SPICE is actually fairly advanced when it comes to bandwidth. It will make determinations of client capabilities, network characteristics, and other parameters to automatically change its behavior to provide the best user experience possible. (So in some cases it might be sending raw graphics commands to the client which are processed there, and in other cases it might send what amounts to screen bitmaps to the client.)
Leveraging host-side hardware and special hypervisor capabilities: the future is now!
One important thing you need to understand is that SPICE is architected a bit different than ICA and RDP. While ICA and RDP are made of up two components (a remote software component that runs in the OS of the Windows host you're connecting to, and a client), SPICE is actually made up of three components:
- Remote guest component: A virtual graphics adapter running in the VM, just like ICA/RDP.
- Client component; The SPICE client software, just like ICA/RDP.
- Remote host component: A virtual graphics device which the hypervisor makes available to the VM. (This is different than today's ICA/RDP.)
In other words, because SPICE has a hypervisor component, it will only work when your remote hosts are VMs.
Last month we wrote an article asking whether the future of remoting protocols is going to be based on three-tiered architectures (such as SPICE). While not everyone thought it was a good idea, there's actually a lot of evidence that the industry is going down that path anyway. Microsoft has already told us that one of the ways Calista technology will make it into RDP will be via Hyper-V extensions that essentially provide virtual GPUs to guest VMs. And Citrix's HDX 3D leverages CUDA-enabled host-side Nvidia GPUs to provide specialized capabilities for encoding 3D graphics.
And then there's VMware's software-only implementation of Teradici's PC-over-IP protocol. Today's software PCoIP is only two-tier (just like traditional ICA and RDP), but that's really because VMware needed to get something out the door pretty fast. I wouldn't be surprised if we also saw some kind of ESX-based processing capability exposed to their VMs to really accelerate what they could do with PCoIP and View.
What impact could an open source SPICE have?
There are two possible things that could happen from SPICE being open source.
First, the actual SPICE protocol itself could get better which would lead to more support for Red Hat Enterprise Desktop Virtualization. This is a no-brainer and something I'm sure will happen. Will this lead to more people buying Red Hat? Probably not, because I don't think people choose desktop virtualization platforms based on protocol anymore.
Second, and the question that's on everyone's mind, is whether SPICE will make it into other desktop virtualization products out there, and if so, whether it will matter.
To answer that, it's important to first keep in mind that as of today, SPICE can only connect to remote hosts running on KVM-based hypervisors. I guess the idea is that it's now open source, that will change, but remember that since the hypervisor also has to provide a virtual graphics device to the VM, this isn't as simple as popping a SPICE agent in a View or XenDesktop VM. Using SPICE on a Xen, Hyper-V, or ESX-based VM will require additions to the hypervisor. When will we see those? (Or will we ever?) Who will make them and why?
So let's think about the vendors who could do this. Citrix doesn't need to, since you already get HDX/ICA with all their products, so they have no incentive to support another protocol. Microsoft already has plans for something like this with Calista, and they're probably already almost done with it, and it will probably be part of RDP, so they don't really need this. I guess that just leaves VMware, but now that they spent the money on PCoIP, I'm not sure if they have an incentive to add another protocol, especially if it means making changes to the hypervisor.
Of course we might just see a port of SPICE over to Xen-based hypervisors too, although I have no idea whether that's a simple thing or something that will require months of re-engineering?
The bottom line is that I want to love SPICE and think that it's going to be everywhere. But I think the reality now is that everyone who needs a remoting protocol has one. I'm guessing an open-source Xen-based SPICE is highly probable, along with SPICE getting better on KVM. But other than that, who knows?