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

[Anthony Liguori <anthony@codemonkey.ws>]

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