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

[Avi Kivity <avi@redhat.com>]

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.