From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NuIWt-00079S-Vq for qemu-devel@nongnu.org; Wed, 24 Mar 2010 00:49:20 -0400 Received: from [140.186.70.92] (port=43559 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NuIWn-00077q-K8 for qemu-devel@nongnu.org; Wed, 24 Mar 2010 00:49:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NuIWi-0007QH-WA for qemu-devel@nongnu.org; Wed, 24 Mar 2010 00:49:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:25059) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NuIWi-0007Q9-Nw for qemu-devel@nongnu.org; Wed, 24 Mar 2010 00:49:08 -0400 Message-ID: <4BA999AF.5000909@redhat.com> Date: Wed, 24 Mar 2010 06:48:47 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [libvirt] [Qemu-devel] Re: 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> <20100323182345.GN364@redhat.com> In-Reply-To: <20100323182345.GN364@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: "Daniel P. Berrange" Cc: "libvir-list@redhat.com" , Paul Brook , qemu-devel@nongnu.org On 03/23/2010 08:23 PM, Daniel P. Berrange wrote: > On Tue, Mar 23, 2010 at 08:00:21PM +0200, Avi Kivity wrote: > >> On 03/23/2010 06:06 PM, Anthony Liguori wrote: >> >>>> I thought the monitor protocol *was* our API. If not, why not? >>>> >>> It is. But our API is missing key components like guest enumeration. >>> So the fundamental topic here is, do we introduce these missing >>> components to allow people to build directly to our interface or do we >>> make use of the functionality that libvirt already provides if they >>> can plumb our API directly to users. >>> >>> >> Guest enumeration is another API. >> >> Over the kvm call I suggested a qemu concentrator that would keep track >> of all running qemus, and would hand out monitor connections to users. >> It can do the enumeration (likely using qmp). Libvirt could talk to >> that, like it does with other hypervisors. >> > The libvirt QEMU driver started out as a fairly simple "concentrator" not > doing much beyond spawning QEMU with argv& issuing monitor commands. The > host concentrator inevitably needs to be involved in the OS level integration > with features such as cgroups, selinux/apparmounr, host NIC management, > storage, iptables, etc. If you look at the daemons for Xen, VirtualBox, > VMWare, that other libvirt drivers talk to, they all do faaaaar more than > just enumeration of VMs. A QEMU concentrator may start out simple, but it will > end up growing over time to re-implememt much, if not all, the stuff that > libvirt already provides for QEMU in terms of host level APIs. The idea is not to replace libvirt, but provide something that sits underneath. It wouldn't do any non-qemu host-level APIs. > If the core > problem here is to provide app developers access to the full range of QEMU > functionality, the re-implementing the entire of the libvirt QEMU driver is > rather over the top way to achieve that. > It's trivial to expose all qemu functionality by exposing a qmp connection. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.