Re: [Qemu-devel] Spice project is now open

[Izik Eidus]

On Sat, 12 Dec 2009 01:27:09 +0100
Alexander Graf <address@hidden> wrote:

> 
> On 12.12.2009, at 01:14, Izik Eidus wrote:
> 
> > On Sat, 12 Dec 2009 00:54:47 +0100
> > Alexander Graf <address@hidden> wrote:
> > 
> >> 
> >> On 11.12.2009, at 23:46, Izik Eidus wrote:
> >> 
> >>> On Fri, 11 Dec 2009 23:08:01 +0100
> >>> Alexander Graf <address@hidden> wrote:
> >>> 
> >>>> 
> >>>> On 11.12.2009, at 22:13, Izik Eidus wrote:
> >>>> 
> >>>>> On Fri, 11 Dec 2009 14:46:55 -0600
> >>>>> Anthony Liguori <address@hidden> wrote:
> >>>>> 
> >>>>>> Izik Eidus wrote:
> >>>>>>> I personaly dont like mjpeg, and yes in the end of the day you
> >>>>>>> can add the video streaming into vnc, but what is the point
> >>>>>>> here?
> >>>>>>> 
> >>>>>> 
> >>>>>> What I'm trying to understand is, what can we do with Spice
> >>>>>> that we couldn't possibly do with vnc.  That means
> >>>>>> understanding each feature and then figuring out if there's a
> >>>>>> vnc analog.
> >>>>>> 
> >>>>>> If there are compellingly unique features to Spice that can't
> >>>>>> be duplicated in vnc, then it's a no brainer.  If you can do
> >>>>>> most things in vnc but it would be hackish whereas Spice makes
> >>>>>> it all elegant, then provided we can merge Spice without a
> >>>>>> huge amount of pain, then it's a net win.
> >>>>>> 
> >>>>>> However, if we need to make a few changes to vnc in order to
> >>>>>> get the same performance as Spice, then it's not quite as
> >>>>>> clear that it's what we should be using.
> >>>>>> 
> >>>>>> We're talking about a major change here.  There is a ton of
> >>>>>> management software that assumes vnc today.  Even though there
> >>>>>> are Spice clients out there, there are embedded vnc clients in
> >>>>>> certain tools today along with java applets.
> >>>>>> 
> >>>>>> That's not to say we shouldn't embrace Spice, we just have to
> >>>>>> make sure we have a good reason to.
> >>>>> 
> >>>>> Ok, I understand your concerns.
> >>>>> 
> >>>>> But even though that spice and vnc achive in the end of the day
> >>>>> the same thing - they both allow remote rendering, they have
> >>>>> fendumental diffrent architacture.
> >>>>> 
> >>>>> Spice server work with a ring to the guest, it was build from
> >>>>> day one to work like that, In addition it was built from day
> >>>>> one so that the server will render only what it must to render
> >>>>> (to allow much higher virtualization denticity).
> >>>> 
> >>>> The ring is from qemu <-> guest, right? I mean, qemu <-> client
> >>>> would be a TCP transport anyways, so the ring argument is void.
> >>> 
> >>> 
> >>> Beside the fact that we dont have the network overhead...
> >> 
> >> Eh - when you connect to the VM remotely you still get the network
> >> overhead, because you're connecting to it via the network :-).
> > 
> > Yes but you send the data from the HOST networking, not from the
> > virtualized guest networking (That will later send it from the Host
> > networking)...
> 
> Exactly. So you'd get the same as with virtio-fb and VNC :-).

Yes, virtio-fb and spice have the same overhead for the ring part,
but this not what i understood when you said:
"The ring is from qemu <-> guest, right? I mean, qemu <-> client
 would be a TCP transport anyways, so the ring argument is void."

But leave it :).

> 
> > 
> > 
> >> 
> >>> 
> >>>> 
> >>>>> Just to make clear how much spice is diffrence from VNC is by
> >>>>> the fact that only the library itself (not including the
> >>>>> drivers) have 128,277 lines of code inside it. (In my old qemu
> >>>>> repo i see almost 600,000 lines for qemu) so this should give
> >>>>> better prespective on how much spice is diffrent from vnc.
> >>>>> 
> >>>>> So ofcurse in theory you can take all this 128,000 lines and
> >>>>> push them into qemu-vnc.c ?, but you got to remember that spice
> >>>>> is not just specific qemu thing, Spice should be used to work
> >>>>> on physical machines too, just cutting all this lines of code
> >>>>> from spice and throw it into qemu-vnc.c will be meaning a fork
> >>>>> of spice inside qemu....
> >>>> 
> >>>> I definitely understand your point of having a single protocol.
> >>>> The good news is that your physical machine stuff isn't released
> >>>> yet (AFAIK), so luckily there's still time to change parts of the
> >>>> protocol :-).
> >>>> 
> >>>>> It isnt just the rings and the rendering style that make spice
> >>>>> diffrence, it is the channels it have for each compoment, it is
> >>>>> the multiple drawing surfaces, and so on...
> >>>> 
> >>>> These should be fairly easy to implement in VNC too. In fact, I
> >>>> remember a project implementing off-screen drawing in VNC using a
> >>>> larger region of the screen than what was visible and then
> >>>> copyrect them in.
> >>> 
> >>> In theory you can even change the whole of VNC into SPICE or the
> >>> whole of VI into EMACS, so???, I personaly think changing code
> >>> isnt the problem, the problem is always the desgien, and SPICE
> >>> have fandumental diffrent desgien than VNC, (Here you can say: OK
> >>> I can make my VNC desgien like SPICE, or you can say I think
> >>> SPICE dsgien is bad, or you can just use SPICE...)
> >> 
> >> Oh I'm not trying to talk you or anyone into anything. I was merely
> >> trying to stress that SPICE isn't really its own protocol but
> >> extensions to the RDP protocol (IIUC). You could do similar
> >> extensions to VNC if you liked. Thus I'd love to see a generic
> >> mid-layer and implementations of RDP and VNC on top of that
> >> actually.
> > 
> > One of the decisions we have made in SPICE, was to provide a full
> > functional remote system, not realying on other system,
> > We already have far more features than VNC have, so what is the
> > logical in making spice extention of VNC? it more logical to make
> > VNC extention of SPICE...
> > 
> > SPICE have networking tunneling, local/server mouse, (in progress)
> > usb remote, audio / recording channel , private channels for each
> > compoment, Even if VNC would have part of this stuff, It seems like
> > they are trying to achive things in diffrent way than SPICE does.
> 
> It kind of reminds me of the vbus story ;-).
> 
We are not forking qemu, we are self depended protocol, we have the
right to implment the protocol the best way as we understand, I don`t
see much connection with the VBus case...

The real interesting part is, that we not forcing any changes to qemu,
we dont say "throw" vnc, we just add another protocol, that users
already are using and are very happy.
check out:

http://www.brianmadden.com/blogs/brianmadden/archive/2009/12/10/red-hat-makes-the-qumranet-spice-protocol-open-source-a-free-alternative-to-ica-pcoip.aspx

Why is it that bad to allow user freedom of choice for whatever
protocol it want to use for its remote system?

Thanks.

> 
> Alex