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

Avi Kivity avi at redhat.com
Tue Mar 23 17:57:05 UTC 2010

On 03/22/2010 09:25 PM, Anthony Liguori wrote:
> Hi,
> I've mentioned this to a few folks already but I wanted to start a 
> proper thread.
> We're struggling in qemu with usability and one area that concerns me 
> is the disparity in features that are supported by qemu vs what's 
> implemented in libvirt.
> This isn't necessarily libvirt's problem if it's mission is to provide 
> a common hypervisor API that covers the most commonly used features.
> However, for qemu, we need an API that covers all of our features that 
> people can develop against.  The ultimate question we need to figure 
> out is, should we encourage our users to always use libvirt or should 
> we build our own API for people (and libvirt) to consume.
> I don't think it's necessarily a big technical challenge for libvirt 
> to support qemu more completely.  I think it amounts to introducing a 
> series of virQemuXXXX APIs that implement qemu specific functions.  
> Over time, qemu specific APIs can be deprecated in favour of more 
> generic virDomain APIs.
> What's the feeling about this from the libvirt side of things?  Is 
> there interest in support hypervisor specific interfaces should we be 
> looking to provide our own management interface for libvirt to consume?

One option is to expose a qmp connection to the client.  Of course that 
introduces a consistency problem (libvirt plugs in a card, user plugs it 
own, libvirt is confused).  If the user promises to behave, it can work 
for stuff that's 100% orthogonal to libvirt.

One problem is that this is libvirt version specific.  For example, 
libvirt x doesn't support spice so we control that thorough qmp.  But 
libvirt x+1 does support spice and now it gets confused about all the 
spice messages.

Do not meddle in the internals of kernels, for they are subtle and quick to panic.

More information about the libvir-list mailing list