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

[Avi Kivity]

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.