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

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.