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

[Anthony Liguori]

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.

Regards,

Anthony Liguori

> Regards,
> Dor.
> > I guess Yuval will be very happy to make this work :-D
> >
> > Regards,
> > laurent
> >