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@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list