[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API
Date: Tue, 11 Dec 2007 10:49:05 -0600
User-agent: Thunderbird (X11/20071022)

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.


Anthony Liguori


reply via email to

[Prev in Thread] Current Thread [Next in Thread]