[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: |
Daniel P. Berrange |
Subject: |
Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API |
Date: |
Tue, 11 Dec 2007 17:04:42 +0000 |
User-agent: |
Mutt/1.4.1i |
On Tue, Dec 11, 2007 at 10:49:05AM -0600, Anthony Liguori wrote:
> 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.
Ah, ok that makes alot more sense now. We already disable 'vc' for the
monitor so that wouldn't be an issue.
> >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.
Of course libvirt daemon provides other things besides just managing the
QEMU process, but yes fixing the hard parent-child relationship between
the two would be good.
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 -=|
- Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API, (continued)
- Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API, Daniel P. Berrange, 2007/12/11
- Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API, Anthony Liguori, 2007/12/11
- Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API, Richard W.M. Jones, 2007/12/11
- Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API, Anthony Liguori, 2007/12/11
- Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API, Daniel P. Berrange, 2007/12/11
- Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API, Anthony Liguori, 2007/12/11
- Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API,
Daniel P. Berrange <=
- Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API, Dor Laor, 2007/12/11
- Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API, Jean-Christian de Rivaz, 2007/12/11
- Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API, Daniel P. Berrange, 2007/12/11
- Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API, Andreas Färber, 2007/12/11
- Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API, Laurent Vivier, 2007/12/11
- Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API, Andreas Färber, 2007/12/11
- Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API, Heikki Lindholm, 2007/12/11
- Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API, Avi Kivity, 2007/12/11
- Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API, Anthony Liguori, 2007/12/11
- Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API, Daniel P. Berrange, 2007/12/11