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.