From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nu5fk-0003tg-GP for qemu-devel@nongnu.org; Tue, 23 Mar 2010 11:05:36 -0400 Received: from [199.232.76.173] (port=58726 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nu5fj-0003sH-KD for qemu-devel@nongnu.org; Tue, 23 Mar 2010 11:05:35 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nu5ff-0003Mr-J3 for qemu-devel@nongnu.org; Tue, 23 Mar 2010 11:05:35 -0400 Received: from mail-px0-f173.google.com ([209.85.216.173]:59905) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Nu5ff-0003Mc-6K for qemu-devel@nongnu.org; Tue, 23 Mar 2010 11:05:31 -0400 Received: by pxi3 with SMTP id 3so2631904pxi.28 for ; Tue, 23 Mar 2010 08:05:30 -0700 (PDT) Message-ID: <4BA8D8A9.7090308@codemonkey.ws> Date: Tue, 23 Mar 2010 10:05:13 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <4BA7C40C.2040505@codemonkey.ws> <20100323145105.GV16253@redhat.com> In-Reply-To: <20100323145105.GV16253@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: veillard@redhat.com Cc: "libvir-list@redhat.com" , qemu-devel On 03/23/2010 09:51 AM, Daniel Veillard wrote: > On Mon, Mar 22, 2010 at 02:25:00PM -0500, Anthony Liguori wrote: > >> Hi, >> > Hi Anthony, > > >> 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. >> > If you could come up with a list, then I would have an easier job > answering, honnestly I have the feeling we spent the last 6 months > filling that gap in a really fast way. > qemu-doc.texi is a list of most of the command line features we support. The help output of the monitor shows what we support in that interface. It doesn't take a lot to read through it and see the things not supported by libvirt. libvirt supports a relatively small amount of our overall features (although a good chunk of the most common set). >> 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. >> > But one point of libvirt is that once an API is there we don't break it. > > I think there is a serious divergence of approach there, instanciating > API stating 'we are gonna deprecate them sooner or later' tell the > application developper 'my time is more important than yours' and not > really something I like to carry to the API users. > The main goal of libvirt remains to provide APIs needed to unify the > development of the virtualization layers. Having APIs which makes > sense only for one or 2 virtualization engines is not a problem in > itself, it just raises questions about the actual semantic of that API. > If that semantic is sound, then I see no reason to not add it, really > and we actually often do. > Yeah, but the problem we're facing is, I want there to be an API added to the management layer as part of the feature commit in qemu. If there has to be a discussion and decisions about how to model the API, it's not going to be successful. Supporting legacy APIs forever is not a viable option for a project like qemu. Things evolve quickly and we need a mechanism to deprecate APIs over time. >> 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? >> > The real question is what do you actually want to build. > Any management application really. Even with something like virt-manager, there's a ton of useful features that qemu supports (like migration status reporting) that libvirt doesn't support. > Most of the feedback I have seen in this thread so far are mostly > request to be able to hack on a qemu instance launched via libvirt. > It's not about the "hacker" use-case. It's about making sure that we've got 100% feature coverage in our management API. All of the management tools that focus on KVM have had this problem that I am aware of. We need to come up with a way that we can very easily plumb new qemu functions through the management interface. Regards, Anthony Liguori