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

[Fabrice Bellard <fabrice@bellard.org>]

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.

Regards,

Fabrice.

Yuval Kashtan wrote:
> Some answers:
> - If there is interest I can re-create the patch so it will work against 
> the current head. I thought to receive some comments about it first..
> - thanks for the styling and configuration remarks, I will certainly fix 
> these. But before I invest more time in it, I would like to hear what 
> ppl think in general of management API? How do you like DBus as the 
> infrastructure for that? and what do you think of the proposed 
> implementation?
> - Currently only commands are implemented (with very few getters), but 
> of course this can be further extended to include values reading and 
> statistics.
> - This is very useful when you want to manage and control QEMU, for 
> instance developing a GUI to attach and detach usb devices or 
> controlling more than one instance of QEMU from a single management 
> point, receiving parameters externally and more.
> 
> 
> On Dec 10, 2007 10:51 PM, Blue Swirl <blauwirbel@gmail.com 
> <mailto:blauwirbel@gmail.com>> wrote:
> 
>     On 12/10/07, Yuval Kashtan < yuvalkashtan@gmail.com
>     <mailto:yuvalkashtan@gmail.com>> wrote:
>      > Hello All,
>      > Attached is a proposed patch which adds DBus support to QEMU.
>     DBus is a
>      > standard message bus for linux
>      > ( http://www.freedesktop.org/wiki/Software/dbus )
>      > The idea behind this is to allow for external programs such as
>     controlling
>      > GUI or HyperVisors to communicate and control QEMU, in a standard
>     manner.
>      > Although it is possible to connect to the monitor, an API is more
>     standard,
>      > theres no need to parse texts and error messages, no
>     internationalization
>      > problems and in general is a much better idea.
>      >
>      > Implementation:
>      > This is done by creating a DBus server from QEMU which raise
>     signals and act
>      > upon methods.
>      > Methods mainly implement same logic as the current command line
>     options and
>      > monitor does.
>      >
>      > How to use:
>      > To enable DBus support you'll have to add --enable-dbus when you
>     execure
>      > configure script.
>      > Then when you execute QEMU, you'll have to add -dbus-service
>     <service_name>
>      > where service_name follows the DBus naming convention (
>     xxx.xxx.xxx....)
>      > To support QEMU configuration through DBus,  you'll also have to add
>      > -dbus_configuration which will cause QEMU to wait until
>     ConfigDone is called
>      > through the DBus interface. this allows external programs time to
>     call DBus
>      > methods starting with Config_ which changes configuration (just
>     as the CLI
>      > does) thus enabling invocation of QEMU without parameters (beside
>     the DBus
>      > ones).
>      > With that, we have implemented a nice python script that reads VM's
>      > configuration from INI file.
>      >
>      > To compile this you will also have to compile the attached
>     freedesktop.org <http://freedesktop.org>
>      > dsrv library (it is also attach for those who can't handle GIT) from:
>      > git://people.freedesktop.org/~shaharf/dsrv
>      >
>      > Features:
>      > Currently support was added to all important CLI configuration
>     and some
>      > online monitor functions (such as connecting and disconnecting
>     usb devices).
>      > configuration methods begins with Config_ prefix and monitor ones
>     with
>      > Monitor_.
>      > For a complete list you can just execute qemu and connect with
>     dbus-viewer
>      > to see what is supported.
>      >
>      >
>      > All the dbus handling routines can be found in dbus-monitor.c.
>      > I have two different implementations of this:
>      > 1) A single threaded version. which comply to the qemu standard
>     of not
>      > opening additional threads.
>      > 2) A multi threaded version which open an additional, single,
>     thread which
>      > handles all the DBus load. I actually believe this version is
>     better as it
>      > allows QEMU to continue execution of guest operations even when
>     there are
>      > DBus methods/signals to handle, whereas in the first option, DBus is
>      > integrated into QEMU mainloop. Also this makes it possible to
>     monitor even
>      > during long operations (like monitoring the progress of savevm)
>      >
>      >
>      > Please comment both on the idea of management API and the proposed
>      > implementation.
>      >
>      >
>      > Attached are:
>      > RFC-QEMU-Dbus.patch - patch file including all necessary changes
>     to qemu.
>      > was made against QEMU HEAD as of 23/9 morning.
>      > RFC-QEMU-Dbus-Interface.xml - the xml description of the DBus
>     interface that
>      > I suggest.
>      > dsrv.tar.gz.txt - the dbus server library.
> 
>     I have no idea if this is useful. I would have tried the patch, but it
>     does not apply to current CVS. Other comments:
> 
>     When configure is invoked with --enable-dbus, it should check for DBUS
>     libraries and abort if not found.
> 
>     The coding style in monitor-dbus.c is different from what is commonly
>     used in Qemu. Some long lines could be shortened.
> 
>     Enabling of DEBUG_ACPI and other ACPI changes are probably not
>     directly needed so they should be in separate patches.
> 
>     Only commands are included, how about reading values and statistics?
> 
> 
> 
> 
> 
> -- 
> Sincerly,
> Yuval Kashtan