Re: [Qemu-devel] [RFC PATCH 22/36] block: add mirror job

[Eric Blake]

On 06/15/2012 09:05 AM, Paolo Bonzini wrote:
> This patch adds the implementation of a new job that mirrors a disk to
> a new image while letting the guest continue using the old image.
> 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).

Is this paragraph still accurate?  At any rate, it sounds a bit
confusing - if I run 'block-job-cancel', do I get a 'complete' or a
'cancelled' event?  Or is it a question of _which_ event I get depending
on how a race goes?


> +
> +        if (bdrv_get_dirty_count(bs) == 0) {
> +            /* We're out of the streaming phase.  From now on, if the
> +             * job is cancelled we will actually complete all pending
> +             * I/O and report completion, so that drive-reopen can be
> +             * used to pivot to the mirroring target.
> +             */

Comment is out of date since you are no longer proposing a drive-reopen,
but block-job-complete.

>  ##
> +# @MirrorSyncMode:
> +#
> +# An enumeration of possible behaviors for the initial synchronization
> +# phase of storage mirroring.
> +#
> +# @top: copies data in the topmost image to the destination
> +#
> +# @full: copies data from all images to the destination

Do we ever want to support partial mirroring, the way we support partial
block-stream?  That is, given:

A <- B <- C

and creating a copy D, 'top' means D has B as a backing file, 'full'
means D has no backing file, but to create D with A as a backing file, I
would instead have to do a 'top' mirror, then complete, then do a
regular block-stream for a partial pull.

Deciding whether to support partial block mirror with anything more than
top but less than full will impact whether my proposed libvirt
virDomainBlockCopy() command needs an extra argument for naming the new
base file in a partial mirror.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature