Re: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt
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