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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list