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

[Anthony Liguori <anthony@codemonkey.ws>]

Yuval Kashtan wrote:
> As I can see,
> There is HUGH interest in management API for QEMU.
> seemly, DBus is NOT the right solution for direct integration into 
> QEMU as it is not cross platform enough, pose extra dependency and 
> (probably) not suitable for embedded systems.
>
> Keeping only the "old" monitor interface with no formal interface will 
> make QEMU harder to integrate with as it requires extra work

Why can't we make the monitor interface a "formal" interface?

Regards,

Anthony Liguori

> C API is not a complete solution as it does not define well enough how 
> will you integrate with QEMU without changing or adding to the source..
> But combined with AVI's idea of some plug-in mechanism, which will use 
> this C API, it sounds like a complete and valid solution.
>
> The monitor should be kept for backward compatibility, human interface 
> and be implemented on top of that API as well, so there will also be a 
> reference implementation of how to use the API and create a plug-in.
>
>
>
>
> As of Daniel remarks regarding DBus:
> - I actually have a newer version where commands are divided into 
> different DBus interfaces. So (hopefully) that solves the methods 
> naming problem.
> - I had to pass the server name at the CLI, since I was executing 
> multiple instances of QEMU.. Having an external server, raises again 
> the question of how will that server communicate with each instance of 
> QEMU?
> - It was easier for my project to configure QEMU after it started and 
> not through a file, that why there is a configuration method for each 
> option. of course there could also be a bulk method which receive them 
> all or even read them from a file (and actually with some extra work, 
> many of them could be made dynamics)
>
> On Dec 11, 2007 5:00 PM, Daniel P. Berrange <berrange@redhat.com 
> <mailto:berrange@redhat.com>> wrote:
>
>     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/
>     <http://search.cpan.org/%7Edanberr/>              -=|
>     |=-               Projects: http://freshmeat.net/~danielpb/
>     <http://freshmeat.net/%7Edanielpb/>               -=|
>     |=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742
>     7D3B 9505  -=|
>
>
>
>
>
> -- 
> Sincerly,
> Yuval Kashtan