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

Avi Kivity avi at redhat.com
Wed Mar 24 04:48:47 UTC 2010

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.

More information about the libvir-list mailing list