[libvirt] Supporting hypervisor specific APIs in libvirt

[Daniel Veillard]

On Mon, Mar 22, 2010 at 02:25:00PM -0500, Anthony Liguori wrote:
> Hi,

  Hi Anthony,

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

  If you could come up with a list, then I would have an easier job
answering, honnestly I have the feeling we spent the last 6 months
filling that gap in a really fast way.

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

  "most commonly used" is not the point of libvirt

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

But one point of libvirt is that once an API is there we don't break it.

I think there is a serious divergence of approach there, instanciating
API stating 'we are gonna deprecate them sooner or later' tell the
application developper 'my time is more important than yours' and not
really something I like to carry to the API users.
The main goal of libvirt remains to provide APIs needed to unify the
development of the virtualization layers. Having APIs which makes
sense only for one or 2 virtualization engines is not a problem in
itself, it just raises questions about the actual semantic of that API.
If that semantic is sound, then I see no reason to not add it, really
and we actually often do.

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

  The real question is what do you actually want to build.
Most of the feedback I have seen in this thread so far are mostly
request to be able to hack on a qemu instance launched via libvirt.
That looks a lot more an usability problem from the KVM/QEmu developpers
than a problem related to building long term applications using libvirt
stack and specific QEmu feature.

  As Dan answered the problem seems to be the short term, when features
are being developped or tested for QEmu/KVM, I think once the feature is
there we do try to provide support, and more general integration in the
OS framework. I actually think we are fairly fast to roll in support for
most feature, snapshot being one notable exception.

  Maybe more hacking support is needed, i.e. some way to access the
monitor or add arbitrary qemu command line in a non-supported way, the
main goal being to ease the life of developpers of QEmu/KVM, but that
non-supported status need to be made clear. That's runtime facilities,
and somehow I feel there is a point for this, though clearly that would
for example be disabled for 'enterprise' builds.

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/