On Tue, Apr 10, 2012 at 01:17:44PM -0400, Laine Stump wrote:
On 04/09/2012 11:52 PM, Eric Blake wrote:
The new block copy storage migration sequence requires both the 'drive-mirror' action in 'transaction' (present if the 'drive-mirror' standalone monitor command also exists) and the 'drive-reopen' monitor command (it would be nice if that were also part of a 'transaction', but the initial qemu implementation has it standalone only).
Furthermore, qemu 1.1 will be adding 'block_job_cancel' as an asynchronous command, but an earlier implementation (that supported only the qed file format) existed which was synchronous only. If 'drive-mirror' is added in time, then we can safely use 'drive-mirror' as the witness of whether 'block_job_cancel' is synchronous or asynchronous.
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 :-( Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|