From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nu8Lz-0008AQ-Vd for qemu-devel@nongnu.org; Tue, 23 Mar 2010 13:57:24 -0400 Received: from [140.186.70.92] (port=50768 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nu8Lw-000899-AA for qemu-devel@nongnu.org; Tue, 23 Mar 2010 13:57:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nu8Ls-0002Ds-J6 for qemu-devel@nongnu.org; Tue, 23 Mar 2010 13:57:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:6142) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nu8Ls-0002Df-AJ for qemu-devel@nongnu.org; Tue, 23 Mar 2010 13:57:16 -0400 Message-ID: <4BA900F1.5020001@redhat.com> Date: Tue, 23 Mar 2010 19:57:05 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Supporting hypervisor specific APIs in libvirt References: <4BA7C40C.2040505@codemonkey.ws> In-Reply-To: <4BA7C40C.2040505@codemonkey.ws> 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: Anthony Liguori Cc: "libvir-list@redhat.com" , qemu-devel 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. 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. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.