Re: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt

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.

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.