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

[Alexander Graf]

On 12.12.2009, at 01:53, Izik Eidus wrote:

> 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."

Oh one of your arguments about the superiority of SPICE was that it uses a ring 
buffer. I just wanted to make sure you're talking about the guest <-> 
hypervisor interface there, thus not stressing anything in the SPICE protocol 
:-).

> 
> 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?

Nothing at all! I want to make it even more modular. I want to see a lego like 
approach where we can combine all the good parts together and use whatever we 
like from whatever corner we come from.

So the thing I dislike is the "take all of QXL and SPICE or leave everything" 
sort of attitude that's coming over. I'd love to use QXL, but I don't want to 
use SPICE :-). Thus I want to make sure we're going in a really modular 
direction, so all the bits can be combined to every users' liking. Thus 
creating choice.


Alex