On Mon, Mar 22, 2010 at 02:25:00PM -0500, 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.
The second thing I forgot to mention in my previous reply, is that we also
need to get a much better idea of just which QEMU features missing in libvirt.
Even if we provide a generic mechansim for setting QEMU specific features,
we still need visibility into what needs to be added to the main generic
libvirt XML / API format. I think the qdev & QMP work will be very
useful in this respect, since both are pretty much self-describing. All that
is missing from QEMU is a way to query/extra the qdev/QMP metadata from the
QEMU binary in an automated fashion. eg, '-device qdev' can list all devices,
but following on from that we need to query the properties known against each
device type. I think it'd also be desirable to have a machine readable
'-help'
output format, so we can more reliably detect what args are available, since
even with qdev + -device, we're still adding more command line args to QEMU
over time like -netdev, -blockdev, etc.
If we can easily get these details of qdev properties, QMP commands/args and
ARGV from QEMU, then we can reliably identify just what is missing from
libvirt & use that to guide development of generic APIs for the missing
features.
Regards,
Daniel
--
|: Red Hat, Engineering, London -o-
http://people.redhat.com/berrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org -o-
http://deltacloud.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|