From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J28IF-0004iL-EP for qemu-devel@nongnu.org; Tue, 11 Dec 2007 11:49:15 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J28IC-0004dm-CE for qemu-devel@nongnu.org; Tue, 11 Dec 2007 11:49:14 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J28IC-0004dZ-7P for qemu-devel@nongnu.org; Tue, 11 Dec 2007 11:49:12 -0500 Received: from nz-out-0506.google.com ([64.233.162.233]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J28IA-000475-QS for qemu-devel@nongnu.org; Tue, 11 Dec 2007 11:49:12 -0500 Received: by nz-out-0506.google.com with SMTP id f1so3779933nzc for ; Tue, 11 Dec 2007 08:49:08 -0800 (PST) Message-ID: <475EBF81.5020009@codemonkey.ws> Date: Tue, 11 Dec 2007 10:49:05 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API References: <475E5403.2000705@bellard.org> <1197364997.4242.10.camel@frecb07144> <475E617D.6090702@qumranet.com> <475EA3F4.50802@codemonkey.ws> <20071211150228.GD17368@redhat.com> <475EA9AA.3020503@codemonkey.ws> <475EAF65.5050809@redhat.com> <475EB146.9000105@codemonkey.ws> <20071211155842.GI17368@redhat.com> In-Reply-To: <20071211155842.GI17368@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , qemu-devel@nongnu.org Daniel P. Berrange wrote: > On Tue, Dec 11, 2007 at 09:48:22AM -0600, Anthony Liguori wrote: > >> Richard W.M. Jones wrote: >> >> Actually, this was the original intention of the -name parameter. What >> a management tool would want to do is: >> >> 1) if -name is specified by user, generate one with uuidgen >> 2) pass -name and -pidfile /path/to/well/known/location/name.pid >> >> This will ensure uniqueness of name without requiring the creation tool >> to maintain any state (so no daemon is required). Right now, you would >> also have to store a monitor socket in that well known path. However, >> I'm working on a VNC tunnels patch right now that would allow the >> monitor to be tunneled through a VNC session. The idea here is that a >> management tool could just store a hint about the VNC location and then >> you can get at the rest of the character devices through the VNC session. >> >> Otherwise, you end up with a bunch of temporary sockets for things like >> the monitor, serial devices, parallel devices, etc. >> > > Tunnelling things like the serial devices / parallel devices over VNC > would be very useful, as using a pty/file isn't useful for remote > management. Tunnelling the monitor over VNC is questionable though because > it has very significant security implications - if you can connect to the > VNC server, you essentially own the entire user account that the VM is > running under since the monitor can be used to map arbitrary files into > the guest VM. Now this may be useful in some cases, but for libvirt we > really just want the monitor accessible locally via a well-known UNIX > socket. Also, VNC ports are typically auto-allocated at startup so not > neccessary a good predictable access method. > The monitor is already tunneled through VNC ala a 'vc'. The tunnels extension I'm developing would just expose 'vc's as plain-text instead of rendered. If your management tools policy is to not make the monitor exposed over a 'vc', then it wouldn't be exposed via VNC tunneling either. > The reason libvirt use the PTY & direct PID ownership was because we stared > off with QEMU 0.8.0. We should really just mandate use of QEMU 0.9.0 with > libvirt now since its been around quite a while. Then we could just run > with -daemonize, -pidfile and -monitor unix:/well/known/path. > Yeah, it would be very nice to eliminate the extra daemon. Regards, Anthony Liguori > Dan. >