qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Supporting hypervisor specific APIs in libvirt


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] Supporting hypervisor specific APIs in libvirt
Date: Mon, 22 Mar 2010 20:25:37 +0000
User-agent: Mutt/1.4.1i

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 :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]