[libvirt] Supporting hypervisor specific APIs in libvirt
Anthony Liguori
anthony at codemonkey.ws
Tue Mar 23 15:05:13 UTC 2010
On 03/23/2010 09:51 AM, Daniel Veillard wrote:
> 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.
>
qemu-doc.texi is a list of most of the command line features we
support. The help output of the monitor shows what we support in that
interface. It doesn't take a lot to read through it and see the things
not supported by libvirt. libvirt supports a relatively small amount of
our overall features (although a good chunk of the most common set).
>> 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.
>
Yeah, but the problem we're facing is, I want there to be an API added
to the management layer as part of the feature commit in qemu. If there
has to be a discussion and decisions about how to model the API, it's
not going to be successful.
Supporting legacy APIs forever is not a viable option for a project like
qemu. Things evolve quickly and we need a mechanism to deprecate APIs
over time.
>> 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.
>
Any management application really. Even with something like
virt-manager, there's a ton of useful features that qemu supports (like
migration status reporting) that libvirt doesn't support.
> 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.
>
It's not about the "hacker" use-case. It's about making sure that we've
got 100% feature coverage in our management API. All of the management
tools that focus on KVM have had this problem that I am aware of.
We need to come up with a way that we can very easily plumb new qemu
functions through the management interface.
Regards,
Anthony Liguori
More information about the libvir-list
mailing list