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

[Anthony Liguori <anthony@codemonkey.ws>]

Dor Laor wrote:
> On 12/12/2009 07:40 PM, Anthony Liguori wrote:
>> If Spice can crash a guest, that indicates to me that Spice is
>> maintaining guest visible state.  That is difficult architecturally
>> because if we want to do something like introduce a secure sandbox for
>> running guest visible emulation, libspice would have to be part of that
>> sandbox which would seem to be difficult.
>>
>> The VNC server cannot crash a guest by comparison.
>
> That's not accurate:

Cannot crash the *guest*.  It can crash qemu but it's not guest 
visible.  IOW, the guest never interacts directly with the VNC server.  
The difference matters when it comes to security sandboxing and live 
migration.

> If we'll break spice to components we have the following (and I'm not 
> a spice expert):
> 1. QXL device/driver pair
>    Is anyone debate we should have it in qemu?
>    We should attach it SDL and vnc backend too anyway.
> 2. VDI (Virtual Desktop Interface)
>    http://www.spice-space.org/vdi.html

FYI, www.spice-space.org is not responding for me.

>    It's an abstraction layer for graphics/keyboard/mouse/sound
>    /usb/serial.
>    We need it anyway regardless of spice. What is our user like to
>    switch from vnc to SDL on runtime? It's good for usb-over-ip for
>    remoting, for various mouse modes, etc.
> 3. Spice server
>    Shared library, in the same address space of qemu (like vnc server).
>    Very sophisticated peace of code.

The bit I've been trying to understand is whether the Spice server 
interacts directly with a guest or not.  I assume I'd be able to gather 
that from the VDI interfaces but the server's been down since this morning.

> So #1 shouldn't run into any opposition.
> We can discuss why #2 is good, the layering separation between 
> guest/host seems good idea to me.
> As for #3, this is a library. If we have #2, one can even use a 
> separate address space for sanity reasons. From my experience with 
> spice (through all Red Hat QA), 99.9% of failures originated in qemu..

Where #3 lives is purely a function of what level of integration it 
needs with qemu.  There may be advantages to having it external to 
qemu.  I actually think we should move the VNC server out of qemu...

Dan Berrange and I have been talking about being able to move VNC server 
into a central process such that all of the VMs can have a single VNC 
port that can be connected to.  This greatly simplifies the firewalling 
logic that an administrator has to deal with.   That's a problem I've 
already had to deal with for our management tools.  We use a private 
network for management and we bridge the VNC traffic into the customers 
network so they can see the VGA session.  But since that traffic can be 
a large range of ports and we have to tunnel the traffic through a 
central server to get into the customer network, it's very difficult to 
setup without opening up a mess of ports.  I think we're currently 
opening a few thousand just for VNC.

For VNC, to make this efficient we just need a shared memory transport 
that we can use locally.  I doubt the added latency will matter as long 
as we're not copying data.

Of course, Spice is a different thing altogether.  I have no idea 
whether it makes sense for Spice like it would for VNC.  But I'd like to 
understand if the option is available.

Regards,

Anthony Liguori