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

[Anthony Liguori]

On 03/23/2010 01: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.

But with Xen, VirtualBox, and VMware, if you create a VM through the 
native interfaces, you'll see that virtual machine with libvirt.  
virt-top will show meaningful results for those VMs and almost all of 
libvirt's functionality will work as expected.

Likewise, if you create a virtual machine with libvirt, when you do an 
xm list, run the VirtualBox GUI, or use VirtualCenter, you see that 
guest and you can interact with it through those interfaces.

What that means is that if you write a libvirt application and need to 
use a feature that libvirt doesn't support for xen, you can also fall 
back to the Xend API.

That's currently missing with qemu.

>   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.
>    

The goal is not to replicate libvirt but to let a more complete, qemu 
specific API co-exist with libvirt just as is implemented for almost all 
of the other hypervisors libvirt supports.

Regards,

Anthony Liguori

> Regards,
> Daniel
>