On 06/12/2014 06:01 AM, Peter Krempa wrote:
On 06/11/14 18:27, Eric Blake wrote:
> With this in place, I can (finally!) now do:
>
> virsh blockcommit $dom vda --shallow --wait --verbose --pivot
>
> - /* FIXME: qemu 2.0 supports active commit, but as a
two-stage
> - * process; qemu 2.1 is further improving active commit. We need
> - * to start supporting it in libvirt. */
> if (topSource == disk->src) {
> /* We assume that no one will backport qemu 2.0 active commit
> * to an earlier qemu without also backporting the block job
> - * ready event; but this makes sure of that fact */
> + * ready event; but this makes sure of that fact.
> + *
> + * XXX Also need to check other capability bit(s): qemu 1.7
> + * supports async blockjob but not active commit; and qemu 2.0
> + * active commit misbehaves on 0-byte file. */
How about tying the support to qemu 2.1 if it makes things easier? I
don't see any problem with supporting stuff from later-than-introduced
versions. The only question that remains is whether there's anything
relevant to trigger the capability of.
Testing qemu 2.1 is easier - merely check whether 'block-commit' with an
omitted top argument is accepted or rejected.
I just realized - rather than trying to go for 2.0 to begin with, it may
be easier to just require 2.1 for now; we can always relax things later
if people complain that they are still stuck on 2.0, but right now,
there's enough other things going on at once (such as your relative
backing naming stuff) that also depends on 2.1 that it just feels easier
to stick to a single version as our baseline, rather than delaying this
further.
But if I require qemu 2.1, then I'm in the same boat as you as not
having anything to push until I have an actual commit in qemu.git to
point to.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org