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
