From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NunXK-0001iv-QW for qemu-devel@nongnu.org; Thu, 25 Mar 2010 09:55:50 -0400 Received: from [140.186.70.92] (port=36229 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NunXI-0001iW-V4 for qemu-devel@nongnu.org; Thu, 25 Mar 2010 09:55:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NunXH-0000BU-89 for qemu-devel@nongnu.org; Thu, 25 Mar 2010 09:55:48 -0400 Received: from mail-pz0-f194.google.com ([209.85.222.194]:36354) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NunXG-0000BO-N3 for qemu-devel@nongnu.org; Thu, 25 Mar 2010 09:55:47 -0400 Received: by pzk32 with SMTP id 32so1632024pzk.4 for ; Thu, 25 Mar 2010 06:55:45 -0700 (PDT) Message-ID: <4BAB6B5E.5040101@codemonkey.ws> Date: Thu, 25 Mar 2010 08:55:42 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt 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> <20100325102309.5119918c@redhat.com> In-Reply-To: <20100325102309.5119918c@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: "libvir-list@redhat.com" , Paul Brook , qemu-devel@nongnu.org, Avi Kivity On 03/25/2010 08:23 AM, Luiz Capitulino wrote: > 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? > My point is that libvirt should not be a separate management API but effectively an add-on API that provides higher level features, better integration with Linux host services, etc. 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); > Yes, this is the core API. It's missing a mechanism to create a QMPContext. I'll also argue that we want a set of auto generated wrappers like: QError *qmp_last_error(QMPContext *context); int qmp_set_link(QMPContext *context, const char *name, bool up); That's a thin wrapper around qmp_send(). You can autogenerate this fairly easy with an IDL like: None:qmp_set_link:String:name,Boolean:up Which is fairly easy to output using introspection on a QMP session. > Obviously that we'll need a QMPContext and maybe additional functions, > And for a QMPContext, we need functions like: /* use qemu's default advertisement mechanism to find a guest */ QMPContext *qmp_context_new_by_uuid(uuid_t uuid); QMPContext *qmp_context_new_by_name(const char *name); /* connect to an already established QMP session */ QMPContext *qmp_context_new_by_fd(int fd); QMPContext *qmp_context_new_by_iops(QMPIOOps *ops); libvirt could use qmp_context_new_by_iops() to implement a virQemuGetQMP(). It can support this either by having a second QMP connection or even by parsing the QMP traffic and relaying commands over it QMP session (which gives it a chance to snoop on anything it's interested in). I think the former approach is less difficult technically. We can certainly make it easier to create dynamic QMP sessions. > but the two main ideas are: > > 1. We don't do management > I really believe we need to stop thinking this way. I'm not saying that qemu-devel is the place where we design virt-manager, but we ought to consider the whole stack as part of "we". >> 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? > Yes, that's *exactly* what I want. Except I want to call it libqemu because qmp is an implementation detail. Regards, Anthony Liguori