[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 15:00:33 +0000 |
User-agent: |
Mutt/1.4.1i |
On Tue, Dec 11, 2007 at 08:51:32AM -0600, Anthony Liguori wrote:
> Dor Laor wrote:
> >Laurent Vivier wrote:
> >>Le mardi 11 décembre 2007 à 10:10 +0100, Fabrice Bellard a écrit :
> >>
> >>>Hi,
> >>>
> >>
> >>Hi,
> >>
> >>
> >>>At this point I am not interested in integrating it into QEMU as it is
> >>>one more API level to maintain in addition to the command line monitor.
> >>>However, I can change my mind if several projects insists to have a
> >>>similar interface.
> >>>
> >>
> >>perhaps the DBUS interface can replace the command line monitor ?
> >>We have just to move the command line interface to a client speaking to
> >>qemu through the DBUS interface.
> >>
> >>
> >This is a valid option but the problem is that local user will have to
> >use another tool (client) to
> >send commands. Another option is to have a common backend with machine
> >& user interfaces.
> >For example, if we use dbus as the backend, monitor commands will just
> >be translated into dbus.
> >The opposite option is also valid.
> >
> >Anyway, the motivation behind a new interface is that the monitor
> >interface is not good enough for automation:
> >There are not return status for commands, no option for async
> >notifications, no option for parallel actions in case
> >a command takes long time to complete (like snapshot).
>
> All of these are valid, and addressable. Return statuses can just be
> added to the beginning of the output of each command (similar to how
> POP3 works). Async notification can be made to work by add support to
> the monitor for a "select" command. Semantically, select would block
> the monitor and then output events. For this to work really well, you
> would have to support multiple simultaneous monitor sessions. The
> parallel options for long running commands is already address in KVM
> with the migration command. We just have to rework the snapshotting to
> be properly asynchronous.
>
> >
> >So we either a new interface is added or the existing one will be
> >enhanced.
> >Since Qemu/KVM will be used in production its highly important to have
> >a reliable channel to connects with mgmt daemons.
> >Dbus is a common practice for communication and used in Linux,
> >libvirt, etc. The question is whether to add a dbus server to Qemu or
> >a client is sufficient.
>
> The main objection I have to dbus is that it's very heavy weight. It
> implies a rather fat infrastructure and it not very suitable for
> embedding. QEMU has very few dependencies and that is a strength ATM.
> People interested in embedding QEMU still want a good management
> interface so enhancing the monitor seems more preferable to me than
> adding a dbus dependency.
It is also not so easily portable to other OS like Windows & Mac OS, who
will still be lacking a decent control API. As I mentioned in my other
thread, embedding a DBus in each individual QEMU process is not the right
way to write DBus services either. If you want DBus (which is questionable
in itself), then you want to have a single service which manages all a QEMU
VMs. This mandates that the DBus service be outside the context of the QEMU
process itself.
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 -=|
- [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API, Yuval Kashtan, 2007/12/10
- Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API, Blue Swirl, 2007/12/10
- Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API, Yuval Kashtan, 2007/12/11
- Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API, Fabrice Bellard, 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, Brad Campbell, 2007/12/11
- 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, 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, Yuval Kashtan, 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, Avi Kivity, 2007/12/11
- Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API, Paul Brook, 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, 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