From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J26v6-0000MO-FF for qemu-devel@nongnu.org; Tue, 11 Dec 2007 10:21:16 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J26v5-0000L5-LP for qemu-devel@nongnu.org; Tue, 11 Dec 2007 10:21:15 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J26v5-0000Ky-4M for qemu-devel@nongnu.org; Tue, 11 Dec 2007 10:21:15 -0500 Received: from wr-out-0506.google.com ([64.233.184.230]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J26v2-0003T6-TY for qemu-devel@nongnu.org; Tue, 11 Dec 2007 10:21:14 -0500 Received: by wr-out-0506.google.com with SMTP id c37so6440627wra for ; Tue, 11 Dec 2007 07:21:10 -0800 (PST) Message-ID: Date: Tue, 11 Dec 2007 17:21:08 +0200 From: "Yuval Kashtan" Subject: Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API In-Reply-To: <20071211150033.GC17368@redhat.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_32638_20506478.1197386468371" References: <475E5403.2000705@bellard.org> <1197364997.4242.10.camel@frecb07144> <475E617D.6090702@qumranet.com> <475EA3F4.50802@codemonkey.ws> <20071211150033.GC17368@redhat.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" , qemu-devel@nongnu.org ------=_Part_32638_20506478.1197386468371 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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 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 referenc= e 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. o= f course there could also be a bulk method which receive them all or even rea= d 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 wrote: > On Tue, Dec 11, 2007 at 08:51:32AM -0600, Anthony Liguori wrote: > > Dor Laor wrote: > > >Laurent Vivier wrote: > > >>Le mardi 11 d=E9cembre 2007 =E0 10:10 +0100, Fabrice Bellard a =E9cri= t : > > >> > > >>>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 questionabl= e > 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. > -- > |=3D- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 24= 96 > -=3D| > |=3D- Perl modules: http://search.cpan.org/~danberr/ -=3D| > |=3D- Projects: http://freshmeat.net/~danielpb/ -=3D| > |=3D- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 950= 5 > -=3D| > > > --=20 Sincerly, Yuval Kashtan ------=_Part_32638_20506478.1197386468371 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline As I can see,
There is HUGH interest in management API for QEMU.
see= mly, DBus is NOT the right solution for direct integration into QEMU as it = is not cross platform enough, pose extra dependency and (probably) not suit= able for embedded systems.

Keeping only the "old" monitor interface with no formal i= nterface will make QEMU harder to integrate with as it requires extra work<= br>
C API is not a complete solution as it does not define well enough h= ow 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 mo= nitor should be kept for backward compatibility, human interface and be imp= lemented on top of that API as well, so there will also be a reference impl= ementation of how to use the API and create a plug-in.




As of Daniel remarks regarding DBus:
- I actually ha= ve a newer version where commands are divided into different DBus interface= s. So (hopefully) that solves the methods naming problem.
- I had to pas= s the server name at the CLI, since I was executing multiple instances of Q= EMU.. 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 n= ot 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 eve= n read them from a file (and actually with some extra work, many of them co= uld be made dynamics)

On Dec 11, 2007 5:00 PM, Daniel P. Berra= nge <berrange@redhat.com> = wrote:
On Tue, Dec 11, 2007 at 08:51:32AM -0= 600, Anthony Liguori wrote:
> Dor Laor wrote:
> >Laurent Viv= ier wrote:
> >>Le mardi 11 d=E9cembre 2007 =E0 10:10 +0100, Fab= rice Bellard a =E9crit :
> >>
> >>>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 comm= and line monitor.
> >>>However, I can change my mind if seve= ral projects insists to have a
> >>>similar interface.
> >>>
> >>
> >>perhaps the DBUS interfa= ce can replace the command line monitor ?
> >>We have just to m= ove the command line interface to a client speaking to
> >>qemu= through the DBUS interface.
> >>
> >>
> >This is a valid option but t= he problem is that local user will have to
> >use another tool (cl= ient) to
> >send commands. Another option is to have a common back= end 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.
> >
> &= gt;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
> >notifi= cations, no option for parallel actions in case
> >a command takes= long time to complete (like snapshot).
>
> All of these are valid, and addressable.  Return stat= uses can just be
> added to the beginning of the output of each comma= nd (similar to how
> POP3 works).  Async notification can be mad= e to work by add support to
> the monitor for a "select" command.  Semantically, = select would block
> the monitor and then output events.   For t= his to work really well, you
> would have to support multiple simulta= neous monitor sessions.  The
> parallel options for long running commands is already address in K= VM
> with the migration command.  We just have to rework the sna= pshotting 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 productio= n its highly important to have
> >a reliable channel to connects w= ith mgmt daemons.
> >Dbus is a common practice for communication a= nd used in Linux,
> >libvirt, etc. The question is whether to add a dbus server to = Qemu or
> >a client is sufficient.
>
> The main object= ion I have to dbus is that it's very heavy weight.  It
> imp= lies a rather fat infrastructure and it not very suitable for
> embedding.  QEMU has very few dependencies and that is a stre= ngth ATM.
> People interested in embedding QEMU still want a good man= agement
> interface so enhancing the monitor seems more preferable to= me than
> adding a dbus dependency.

It is also not so eas= ily portable to other OS like Windows & Mac OS, who
will still be la= cking 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 questiona= ble
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.--
|=3D- Red Hat, Engineering, Emerging Technologies, Boston.  +1= 978 392 2496 -=3D|
|=3D-           Perl module= s: http://search.cpan.org/~danberr/           &nb= sp;  -=3D|
|=3D-               P= rojects: ht= tp://freshmeat.net/~danielpb/            =   -=3D|
|=3D-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 564= 8 23C1 B3DF F742 7D3B 9505  -=3D|





-- Sincerly,
Yuval Kashtan ------=_Part_32638_20506478.1197386468371--