[libvirt] Supporting hypervisor specific APIs in libvirt

Anthony Liguori anthony at codemonkey.ws
Mon Mar 22 19:25:00 UTC 2010


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?


Anthony Liguori

More information about the libvir-list mailing list