From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NJbfE-0003KC-Do for qemu-devel@nongnu.org; Sat, 12 Dec 2009 18:46:16 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NJbfA-0003IE-P4 for qemu-devel@nongnu.org; Sat, 12 Dec 2009 18:46:16 -0500 Received: from [199.232.76.173] (port=54989 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NJbfA-0003I2-Ix for qemu-devel@nongnu.org; Sat, 12 Dec 2009 18:46:12 -0500 Received: from mail-yw0-f171.google.com ([209.85.211.171]:62700) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NJbf9-0005I1-Jr for qemu-devel@nongnu.org; Sat, 12 Dec 2009 18:46:12 -0500 Received: by ywh1 with SMTP id 1so1915206ywh.18 for ; Sat, 12 Dec 2009 15:46:10 -0800 (PST) Message-ID: <4B242B40.4050409@codemonkey.ws> Date: Sat, 12 Dec 2009 17:46:08 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Spice project is now open References: <20091211213911.0dce90dc@redhat.com> <4B22A2D9.6020602@codemonkey.ws> <20091211223250.129675fc@redhat.com> <4B22B035.3010601@codemonkey.ws> <20091211233158.22e6681f@redhat.com> <4B22C093.2090806@codemonkey.ws> <4B231182.1080208@codemonkey.ws> <20091212144433.GA26966@random.random> <4B23B0BE.7080408@codemonkey.ws> <20091212160626.GB26966@random.random> <4B23D585.70400@codemonkey.ws> <4B241A99.2000704@redhat.com> In-Reply-To: <4B241A99.2000704@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dlaor@redhat.com Cc: Andrea Arcangeli , Paolo Bonzini , qemu-devel@nongnu.org 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