Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API

[Daniel P. Berrange]

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

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|