|
From: | Anthony Liguori |
Subject: | [Qemu-devel] Re: [libvirt] Supporting hypervisor specific APIs in libvirt |
Date: | Tue, 23 Mar 2010 10:05:13 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |