From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J27AE-0004Wj-98 for qemu-devel@nongnu.org; Tue, 11 Dec 2007 10:36:54 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J27AC-0004Vu-9b for qemu-devel@nongnu.org; Tue, 11 Dec 2007 10:36:53 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J27AC-0004Vh-1b for qemu-devel@nongnu.org; Tue, 11 Dec 2007 10:36:52 -0500 Received: from rv-out-0910.google.com ([209.85.198.190]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J27AB-0006oy-9p for qemu-devel@nongnu.org; Tue, 11 Dec 2007 10:36:51 -0500 Received: by rv-out-0910.google.com with SMTP id g11so7558702rvb for ; Tue, 11 Dec 2007 07:36:49 -0800 (PST) Message-ID: <475EAE8F.4020209@codemonkey.ws> Date: Tue, 11 Dec 2007 09:36:47 -0600 From: Anthony Liguori 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> <475E617D.6090702@qumranet.com> <475EA3F4.50802@codemonkey.ws> <20071211150033.GC17368@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Reply-To: 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 Yuval Kashtan wrote: > 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 Why can't we make the monitor interface a "formal" interface? Regards, Anthony Liguori > 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 > reference 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. of course there could also be a bulk method which receive them > all or even read 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é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. > > 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 > questionable > 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. > -- > |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 > 392 2496 -=| > |=- Perl modules: http://search.cpan.org/~danberr/ > -=| > |=- Projects: http://freshmeat.net/~danielpb/ > -=| > |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 > 7D3B 9505 -=| > > > > > > -- > Sincerly, > Yuval Kashtan