Re: [Qemu-devel] [RFC PATCH 0/8] job-based mirroring implementation

[Eric Blake]

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   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature