[libvirt] [PATCH 0/6] atomic snapshots, rounds 4 and 5

[Paolo Bonzini]

Il 23/03/2012 05:17, Eric Blake ha scritto:
> I was originally going to send this as two rounds, one for
> the XML additions of adding mirrors, and one for the flag
> addition to virDomainSnapshotDelete for mapping to drive-reopen;
> but it turned out that testing is easier if I finish the series.
> 
> Note that this is minimally tested at the moment; I'm posting it
> to get review started, but I plan on hammering it tomorrow, and
> possibly coming up with slight alterations for a v2.
> 
> This assumes that rounds 1-3 (ending here) have been applied:
> https://www.redhat.com/archives/libvir-list/2012-March/msg00846.html
> 
> This should finish out my RFC here:
> https://www.redhat.com/archives/libvir-list/2012-March/msg00578.html
> but with one major caveat:
> https://lists.gnu.org/archive/html/qemu-devel/2012-03/msg01524.html
> Upstream qemu has not yet committed the 'drive-mirror' or 'drive-reopen'
> monitor commands, which this series (rounds 4-5) depends on.  There are
> still bugs being worked out under the hood on the qemu side, and there
> is a slight possibility that fixing those bugs may change the public
> interface.  Therefore, part of the review of this series should be to
> determine whether we take the risk of applying the patch now, or
> waiting for qemu to stabilize a bit further.
> 
> I will probably push rounds 1-3 tomorrow, since they have been ACK'd
> (well, round 3 is still awaiting review), and since qemu has committed
> to the 'transaction' monitor command for qemu 1.1.
> 
> For reference, it is likely that RHEL 6.3 will not wait for qemu 1.1,
> but will instead provide RHEL-specific monitor commands named
> __com.redhat_drive-mirror and __com.redhat_drive-reopen; I have
> hopefully structured things well enough that it will be a couple
> lines of patching to qemu_monitor_json.c to recognize that alternate
> command name.

NACK.

RHEL can have all the hacks you want, but upstream oVirt is just another
client of libvirt and QEMU and things should be done properly there
using a new API based on block_stream.  Such a new API would also be
extensible in the future to non-shared-storage migration with NBD +
qemu-nbd.

Paolo