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(a)redhat.com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org