From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J2223-0001mJ-Lc for qemu-devel@nongnu.org; Tue, 11 Dec 2007 05:08:08 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J2220-0001it-MP for qemu-devel@nongnu.org; Tue, 11 Dec 2007 05:08:06 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J2220-0001id-EH for qemu-devel@nongnu.org; Tue, 11 Dec 2007 05:08:04 -0500 Received: from mu-out-0910.google.com ([209.85.134.190]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J221z-0000gd-V1 for qemu-devel@nongnu.org; Tue, 11 Dec 2007 05:08:04 -0500 Received: by mu-out-0910.google.com with SMTP id i2so3886824mue for ; Tue, 11 Dec 2007 02:08:01 -0800 (PST) Message-ID: <475E617D.6090702@qumranet.com> Date: Tue, 11 Dec 2007 12:07:57 +0200 MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API References: <475E5403.2000705@bellard.org> <1197364997.4242.10.camel@frecb07144> In-Reply-To: <1197364997.4242.10.camel@frecb07144> Content-Type: multipart/alternative; boundary="------------030002060700060207090900" From: Dor Laor Reply-To: dor.laor@qumranet.com, qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org This is a multi-part message in MIME format. --------------030002060700060207090900 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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). 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. Regards, Dor. > I guess Yuval will be very happy to make this work :-D > > Regards, > laurent > --------------030002060700060207090900 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit 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).

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.

Regards,
Dor.

I guess Yuval will be very happy to make this work :-D

Regards,
laurent

--------------030002060700060207090900--