On 04/18/2012 08:42 AM, Paolo Bonzini wrote:
Il 18/04/2012 16:18, Jiri Denemark ha scritto:
However, the question is whether we feel comfortable enough with pushing this with the risk that qemu implementation is not upstream yet. I think the API is sane but the history of pushing something that qemu ended up implementing in a different way worries me a bit.
FWIW, the worries on the QEMU side aren't really with the API but with the implementation. We are not sure of the drive-reopen API, but the mirroring abstractions (apart from transactions, i.e. patches 19-23) should be fine.
Given the various comments, I've gone ahead and pushed patches 4-6 (the API changes); I'll wait for a bit longer for any further word on the qemu side before pushing any qemu implementation patches, but at this point, I think we're now committed to supporting as much of live storage copy as qemu will let us support at the time of the libvirt 0.9.12 release. I'll probably repost a v6 later today, with only minor tweaks for rebasing the qemu implementation to latest; at this point, any changes I make to the patch series will be limited to a possible rewrite of 12/23 (if upstream will let us call block-job-set-speed prior to block-stream or drive-mirror), a possible split of 8/23 (if we are sure that upstream will take drive-mirror but not drive-reopen in time for qemu 1.1), and adding a new patch 14.5/23 to pause and resume the domain around any block-reopen call (to ensure that we know when the guest has pivoted, even if libvirtd is restarted at an inopportune time, based on whether the guest is still paused). -- Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org