On 04/13/2012 10:23 AM, Paolo Bonzini wrote: > Hi all, > > this is an alternative implementation of mirroring using a block job. > In the end this is the same as Marcelo's original live block copy code, > only done on top of the job infrastructure and coroutines. Here, the > drive-mirror command sets up a job that copies data using the existing > dirty-bitmap functionality. The target is treated as a "black box" > and data is copied from the source to the target in the background. > > The mirror job is never-ending, but it is logically structured into > two phases: 1) copy all data as fast as possible until the target > first gets in sync with the source; 2) keep target in sync and > ensure that reopening to the target gets a correct (full) copy > of the source data. > > The second phase is indicated by the progress in "info block-jobs" > reporting the current offset to be equal to the length of the file. > When the job is cancelled in the second phase, QEMU will run the > job until the source is clean and quiescent, then it will report > successful completion of the job. (Note that it could already happen > that management lost the race against QEMU and got a completion > event instead of cancellation).
I would be happy if even this much made it into qemu 1.1, rather than waiting till 1.2 to take this feature with improvements, provided that we have ways in 1.2 to tell what enhancements have been added. On my wish list of future enhancements, but not showstoppers if we don't have them for 1.1: - it would be nice to have qemu emit a distinct event at the point where it transitions between the two phases, rather than requiring a polling loop in the caller - it would be nice to have 'drive-mirror' as part of 'transaction': this is necessary to let us do 'snapshot+mirror' transactions, in addition to streaming mirror transactions (although the snapshot+mirror design has not proved as palatable to libvirt, it still hasn't been ruled out; libvirt may still end up providing both migration methods in parallel) - it would be nice to have 'drive-reopen' as part of 'transaction': as mentioned before in other threads, 'drive-reopen' currently closes the source before opening the destination, on failure, it then tries to reopen the source, but that can also fail and then you've hosed the domain. But under a transaction, the prepare phase tackles the complex task of figuring out which parts of the chain to open new vs. which parts of the chain remain open, then the commit phase can either flip to the already-open destination and close the remaining unused parts of the chain, or safely revert to the still-open source - it would be nice to have 'block-job-cancel' as part of 'transaction': this would let you take an external copy of multiple disks at the same point in time from the perspective of guest execution (right now, you can suspend, then do a series of block-job-cancel, then resume the guest for the same effect, but how much downtime does that add?) - it would be nice to have 'mode':'relative-paths' for auto-creating a relative backing path, rather than having to pre-create the file and using 'mode':'existing' - I'm wondering if we ever want to borrow from 'block-stream's partial pull. That is, do we want to allow an optional 'base':'str' argument, so that we can go from: base <- snap1 <- snap2 <- snap3 to base <- copy by setting the base argument? With the patch series as-is, you can do this in two steps: base <- snap1 <- snap2 <- snap3 then 'drive-mirror' with 'full':false base <- snap1 <- snap2 <- copy then 'block-stream' with 'base':'base' base <- copy but that is not as efficient. And if that sounds like something we will want to add in the future, I want to code that into libvirt's proposed virDomainBlockCopy API, even if we don't support it right away. > I'm not really sure Kevin would welcome this functionality in 1.1; but > I've been asked to post it for comments, so I'm doing it before the soft > feature freeze. It depends on the other patches in my queue, and in > particular on those moving generic functionality out of block/stream.c. > > These patches do not make drive-mirror a transactionable command, but > this is just for simplicity. It can be added on top. Yep - what you have posted before the soft freeze is sufficient to play with (I should know, since I've already been playing with it and loving it!), so while I can't make the decision for including this in 1.1, you have my vote, and as I said above, delaying things like making this transactionable until the 1.2 release won't be too bad, as long as we also have a way in 1.2 to tell when those improvements have been added. -- Eric Blake ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
