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
