分类： LINUX
2011-06-05 10:51:02
by
Yesterday Red Hat used what was arguably the 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 (currently ), 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.
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.)
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:
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.
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?
RedHat开放了Qumranet SPICE源代码，spice能够成为免费的ICA/PcoIP么？
by Brian Madden Written on Dec 10 2009
昨天RedHat开放了SPICE远程协议的源代码，SPICE是Qumranet公司开发的，在2008年BriForum上一段demo使之声名鹊
起，录像中一个client使用SPICE协议在多个monitor上运行高质量视频，音频和游戏。Demo地址：
http://www.brianmadden.com/blogs/videos/archive/2009/07/21/briforum-2009-demo-lab-red-hat.aspx
http://www.brianmadden.com/blogs/videos/archive/2008/06/17/qumranet-s-solid-ice-desktop-virtualization-done-right-sponsored-by-qumranet-from-briforum-2008.aspx
后来，我和Gabe负责测试SPICE,RDP,ICA的性能对比，我们写了一篇文章，但是Redhat还没有发布。我们认为Redhat对Qumranet感兴趣是因为KVM hypervisor（与Xen hypervisor竞争），而不是桌面虚拟化。
时至今日，Redhat整合了Qumranet的VDI产品到Red Hat Enterprise Virtualization for
Desktops中，并完全开放了SPICE的源代码。那么SIPCE会带来什么影响？我想这要看how good it is。
How good is SPICE?
SPICE比RDP更好么？它会让思杰的HDX/ICA收到威胁么？会让VMware在PcoIP上损失金钱么？会使Net2Display更加无用么？
在我们为Qumranet做的分析中，我们针对SPICE，ICA，和RDP三种协议运行用户脚本的性能做了对比，结果显示SPICE
在三种情况（单个显示，多个显示，多媒体应用）下都强于ICA和RDP。地址：
http://www.brianmadden.com/blogs/gabeknuth/archive/2009/06/18/redhat-spice-vs-rdp-vs-ica-performance-video.aspx
有一点要说明，我们做的测试都是在无带宽限制的环境中，所以带宽消耗数据不准确（所有的协议都尽可能的消耗它得到的带宽，所以我们只是对比协议的架构而不是带宽分析）也就是说SPICE在宽带下是有优势的。它根据client性能，网络规格参数，和其它参数决定它的行为，以提供最好的用户体验。（所以，它可能发送原始图形命令给client，让client处理渲染；也可能发送屏幕位图到client）。
Leveraging host-side hardware and special hypervisor capabilities: the future is now!
SPICE与ICA，RDP有一点不同，ICA和RDP都是二组件结构（远程的guestOS中的组件和client组件），而SPICE由三部分组成：
1.远程guest组件，运行在VM中的虚拟图形适配器，与ICA/RDP相同
2.Client组件，与ICA/RDP相同
3.远程host组件，hypervisor中的图形设备，不同于ICA/RDP
也就是说，SPICE中有hypervisor组件，所以它只能运行在虚拟机中。
三组件结构是不是远程协议的未来架构？很多人不这样认为，但是很多工业行为已经证明了这个趋势。微软透漏把Calista
技术融合到RDP中的一种途径就是通过Hyper-V扩展以为guest提供虚拟GPU，思杰的HDX 3D在host端提供Nvidia
GPUs以支持3D图形操作。Vmware的PcoIP和传统的ICA/RDP一样是而组件结构，但是这只是因为Vmware needed to
get something out the door pretty fast。
