From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nun2G-0001a3-PZ for qemu-devel@nongnu.org; Thu, 25 Mar 2010 09:23:44 -0400 Received: from [140.186.70.92] (port=47266 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nun2F-0001Zo-I6 for qemu-devel@nongnu.org; Thu, 25 Mar 2010 09:23:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nun2A-0004PY-3B for qemu-devel@nongnu.org; Thu, 25 Mar 2010 09:23:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43138) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nun29-0004PC-KI for qemu-devel@nongnu.org; Thu, 25 Mar 2010 09:23:37 -0400 Date: Thu, 25 Mar 2010 10:23:09 -0300 From: Luiz Capitulino Subject: Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt Message-ID: <20100325102309.5119918c@redhat.com> In-Reply-To: <4BAA86C2.4020701@codemonkey.ws> References: <4BA7C40C.2040505@codemonkey.ws> <20100323145105.GV16253@redhat.com> <4BA8D8A9.7090308@codemonkey.ws> <201003231557.19474.paul@codesourcery.com> <4BA8E6FC.9080207@codemonkey.ws> <4BA901B5.3020704@redhat.com> <4BA9A066.3070904@redhat.com> <20100324103643.GB624@redhat.com> <4BA9EC88.6000906@redhat.com> <20100324134250.38822113@redhat.com> <4BAA6CD9.6060001@redhat.com> <20100324171219.4365318b@redhat.com> <4BAA76EA.2060601@codemonkey.ws> <20100324182501.000b69a7@redhat.com> <4BAA86C2.4020701@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: "libvir-list@redhat.com" , Paul Brook , qemu-devel@nongnu.org, Avi Kivity On Wed, 24 Mar 2010 16:40:18 -0500 Anthony Liguori wrote: > >> We need to have a common management interface for third party tools. > >> > > QMP? :-) > > Only if QMP is compatible with libvirt. I don't want a user to have to > choose between QMP and libvirt. Why not? If all they want is a simple qemu session, they can use QMP directly, on the other hand if what they want is more complex, what's the problem of using a management API like libivrt? Again, one important point of the this discussion is: what interfaces should qemu provide and how/when should qemu rely on libvirt? IMO, we should rely on libvirt for a management interface for all the reasons that have already been exposed: it has a established community, it provides a well tested and stable API, it does VM management, it integrates with several other services like cgroups, SELinux, etc. Now, regarding qemu: > > You mentioned dynamic dispatch, but this is useful only for C clients right? > > If so, what C clients you expected beyond libvirt? > > Users want a C API. I don't agree that libvirt is the only C interface > consumer out there. Actually, I do agree. Maybe, we don't have other C consumers because they weren't crazy enough to parse the crap of the user Monitor (or they do, but for simple things). One possible future client is perf, for example. Here is my solution (actually it's not mine, you have suggested it some time ago): let's provide a convenient way for C clients to use QMP. That is, let's have an overly simple library which takes QDitcs, sends them to qemu through QMP and returns others QDicts. Something like the _sketch_ below: // Open a connection int qmp_open(..., QDict **greeting); // Register a callback for async messages, BUT note that the async message // object is passed verbatim void qmp_async_mes_handler(..., void (*async_mes_handler)(QDict *mes)); // Send a QMP command int qmp_send(..., const char *command, QDict *params, QDict **res); Obviously that we'll need a QMPContext and maybe additional functions, but the two main ideas are: 1. We don't do management 2. QMP is our standard interface > I really think what we want is for a libvirt user to be able to call > libqemu functions directly. There shouldn't have to be libvirt specific > functions for every operation we expose. Not sure if this is too crazy but, considering this user wants to use qemu features not implemented by libvirt yet, what about using both libqmp (above) and libvirt at the same time?