From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NuA1H-00018H-8a for qemu-devel@nongnu.org; Tue, 23 Mar 2010 15:44:07 -0400 Received: from [140.186.70.92] (port=43920 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NuA1D-0000f6-2p for qemu-devel@nongnu.org; Tue, 23 Mar 2010 15:44:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nu9om-0003Ah-3N for qemu-devel@nongnu.org; Tue, 23 Mar 2010 15:31:13 -0400 Received: from mail-px0-f173.google.com ([209.85.216.173]:59923) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nu9ol-0003AU-Ps for qemu-devel@nongnu.org; Tue, 23 Mar 2010 15:31:12 -0400 Received: by pxi3 with SMTP id 3so2895347pxi.28 for ; Tue, 23 Mar 2010 12:31:10 -0700 (PDT) Message-ID: <4BA916FC.2000607@codemonkey.ws> Date: Tue, 23 Mar 2010 14:31:08 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Supporting hypervisor specific APIs in libvirt References: <4BA7C40C.2040505@codemonkey.ws> <4BA900F1.5020001@redhat.com> In-Reply-To: <4BA900F1.5020001@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: "libvir-list@redhat.com" , qemu-devel On 03/23/2010 12:57 PM, Avi Kivity wrote: > On 03/22/2010 09:25 PM, Anthony Liguori wrote: >> Hi, >> >> I've mentioned this to a few folks already but I wanted to start a >> proper thread. >> >> We're struggling in qemu with usability and one area that concerns me >> is the disparity in features that are supported by qemu vs what's >> implemented in libvirt. >> >> This isn't necessarily libvirt's problem if it's mission is to >> provide a common hypervisor API that covers the most commonly used >> features. >> >> However, for qemu, we need an API that covers all of our features >> that people can develop against. The ultimate question we need to >> figure out is, should we encourage our users to always use libvirt or >> should we build our own API for people (and libvirt) to consume. >> >> I don't think it's necessarily a big technical challenge for libvirt >> to support qemu more completely. I think it amounts to introducing a >> series of virQemuXXXX APIs that implement qemu specific functions. >> Over time, qemu specific APIs can be deprecated in favour of more >> generic virDomain APIs. >> >> What's the feeling about this from the libvirt side of things? Is >> there interest in support hypervisor specific interfaces should we be >> looking to provide our own management interface for libvirt to consume? >> > > One option is to expose a qmp connection to the client. Of course > that introduces a consistency problem (libvirt plugs in a card, user > plugs it own, libvirt is confused). If the user promises to behave, > it can work for stuff that's 100% orthogonal to libvirt. With GTK/GDK/Cairo/etc, the expectation is that users behave. For things like GDK, most people never break out to X11 unless they absolute have to. The Cairo API is nice enough though that GDK doesn't even attempt to introduce wrappers. If you muck with X11, accessing the same info with GDK might prove harmful. > > One problem is that this is libvirt version specific. For example, > libvirt x doesn't support spice so we control that thorough qmp. But > libvirt x+1 does support spice and now it gets confused about all the > spice messages. That's only a problem if we only support a single QMP session. This is exactly why we need to support multiple QMP sessions (and do). Regards, Anthony Liguori