On 04/10/2012 11:24 AM, Daniel P. Berrange wrote:
>> As of this[1] qemu email, both commands have been proposed
but not yet
>> incorporated into the tree; in fact, the implementation I tested with
>> has changed to match this[2] email that suggested a mandatory
>> 'full':'bool' argument rather than
'mode':'no-backing-file'. So there
>> is a risk that qemu 1.1 will have yet another subtly different
>> implementation.
>> [
1]https://lists.gnu.org/archive/html/qemu-devel/2012-03/msg01524.html
>> [
2]https://lists.gnu.org/archive/html/qemu-devel/2012-04/msg00886.html
>
>
> None of this gives me warm fuzzies :-/
Based on previous experience, my suggestion is that we do *not* merge
any of this new libvirt API work, until the QEMU stuff has actually
been accepted into their git master. The previous block streaming
stuff is a nice history lesson in what happens when we merge stuff
in libvirt before QEMU has agreed their final design :-(
I'll push hard on the qemu folks to at least commit to the qapi for qemu
1.1, even if the implementation is not available until after that point,
but I can live with the decision to not push the parts depending on the
new monitor commands.
This brings up some corollary questions:
patch 3/18 depends on the new monitor command only insofar as it uses
the existence of the command as a way to sanely tell if
'block_job_cancel' is asynchronous or synchronous. I may be able to
rework that into something that doesn't depend on 'drive-mirror's
existence, by instead tracking whether an event has been issued; is it
worth me spending time on this effort, or should I wait for the qemu
reaction to committing to 'drive-mirror' first?
patch 2/18 and 4/18 are independent fixes, which could be pushed now
without waiting for 1/18. Should I pursue this course of action? It is
only in 1/18, as well as in 5/18 and later, where we are treading on the
dangerous ground of committing to a libvirt API without a reference
implementation in qemu; and even then, we can choose whether to commit
to the libvirt API without immediate qemu support.
All that said, I'd still appreciate a review of the full series, to
catch any other potential mistakes while the code is still fresh on my
mind, even if we delay pushing it to libvirt.git until qemu has made
more progress.
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org