From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NtoC9-0002vj-BD for qemu-devel@nongnu.org; Mon, 22 Mar 2010 16:25:53 -0400 Received: from [199.232.76.173] (port=34559 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NtoC9-0002vZ-0z for qemu-devel@nongnu.org; Mon, 22 Mar 2010 16:25:53 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NtoC6-0008OF-Qs for qemu-devel@nongnu.org; Mon, 22 Mar 2010 16:25:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42272) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NtoC4-0008O7-9f for qemu-devel@nongnu.org; Mon, 22 Mar 2010 16:25:50 -0400 Date: Mon, 22 Mar 2010 20:25:37 +0000 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] Supporting hypervisor specific APIs in libvirt Message-ID: <20100322202537.GD28709@redhat.com> References: <4BA7C40C.2040505@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BA7C40C.2040505@codemonkey.ws> Reply-To: "Daniel P. Berrange" 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 Mon, Mar 22, 2010 at 02:25:00PM -0500, 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. The second thing I forgot to mention in my previous reply, is that we also need to get a much better idea of just which QEMU features missing in libvirt. Even if we provide a generic mechansim for setting QEMU specific features, we still need visibility into what needs to be added to the main generic libvirt XML / API format. I think the qdev & QMP work will be very useful in this respect, since both are pretty much self-describing. All that is missing from QEMU is a way to query/extra the qdev/QMP metadata from the QEMU binary in an automated fashion. eg, '-device qdev' can list all devices, but following on from that we need to query the properties known against each device type. I think it'd also be desirable to have a machine readable '-help' output format, so we can more reliably detect what args are available, since even with qdev + -device, we're still adding more command line args to QEMU over time like -netdev, -blockdev, etc. If we can easily get these details of qdev properties, QMP commands/args and ARGV from QEMU, then we can reliably identify just what is missing from libvirt & use that to guide development of generic APIs for the missing features. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|