[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