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.