From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J26b9-0003Uo-5d for qemu-devel@nongnu.org; Tue, 11 Dec 2007 10:00:39 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J26b7-0003TR-Hh for qemu-devel@nongnu.org; Tue, 11 Dec 2007 10:00:38 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J26b7-0003T4-7C for qemu-devel@nongnu.org; Tue, 11 Dec 2007 10:00:37 -0500 Received: from mx1.redhat.com ([66.187.233.31]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J26b6-0007cS-Fi for qemu-devel@nongnu.org; Tue, 11 Dec 2007 10:00:37 -0500 Date: Tue, 11 Dec 2007 15:00:33 +0000 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [RFC] QEMU Dbus support - a proposal management API Message-ID: <20071211150033.GC17368@redhat.com> References: <475E5403.2000705@bellard.org> <1197364997.4242.10.camel@frecb07144> <475E617D.6090702@qumranet.com> <475EA3F4.50802@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <475EA3F4.50802@codemonkey.ws> Content-Transfer-Encoding: quoted-printable Reply-To: "Daniel P. Berrange" , 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 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 : > >> =20 > >>>Hi, > >>> =20 > >> > >>Hi, > >> > >> =20 > >>>At this point I am not interested in integrating it into QEMU as it = is=20 > >>>one more API level to maintain in addition to the command line monit= or.=20 > >>>However, I can change my mind if several projects insists to have a=20 > >>>similar interface. > >>> =20 > >> > >>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. > >> > >> =20 > >This is a valid option but the problem is that local user will have to= =20 > >use another tool (client) to > >send commands. Another option is to have a common backend with machine= =20 > >& user interfaces. > >For example, if we use dbus as the backend, monitor commands will just= =20 > >be translated into dbus. > >The opposite option is also valid. > > > >Anyway, the motivation behind a new interface is that the monitor=20 > >interface is not good enough for automation: > >There are not return status for commands, no option for async=20 > >notifications, no option for parallel actions in case > >a command takes long time to complete (like snapshot). >=20 > All of these are valid, and addressable. Return statuses can just be=20 > added to the beginning of the output of each command (similar to how=20 > POP3 works). Async notification can be made to work by add support to=20 > the monitor for a "select" command. Semantically, select would block=20 > the monitor and then output events. For this to work really well, you= =20 > would have to support multiple simultaneous monitor sessions. The=20 > parallel options for long running commands is already address in KVM=20 > with the migration command. We just have to rework the snapshotting to= =20 > be properly asynchronous. >=20 > > > >So we either a new interface is added or the existing one will be=20 > >enhanced. > >Since Qemu/KVM will be used in production its highly important to have= =20 > >a reliable channel to connects with mgmt daemons. > >Dbus is a common practice for communication and used in Linux,=20 > >libvirt, etc. The question is whether to add a dbus server to Qemu or > >a client is sufficient. >=20 > The main objection I have to dbus is that it's very heavy weight. It=20 > implies a rather fat infrastructure and it not very suitable for=20 > embedding. QEMU has very few dependencies and that is a strength ATM. = =20 > People interested in embedding QEMU still want a good management=20 > interface so enhancing the monitor seems more preferable to me than=20 > 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 QE= MU VMs. This mandates that the DBus service be outside the context of the QE= MU process itself. Dan. --=20 |=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