Re: [Qemu-devel] Block job commands in QEMU 1.2 [v2, including support for replication]

[Paolo Bonzini <pbonzini@redhat.com>]

Il 24/05/2012 18:57, Eric Blake ha scritto:
> On 05/24/2012 07:41 AM, Paolo Bonzini wrote:
>> changes from v1:
>> - added per-job iostatus
>> - added description of persistent dirty bitmap
>>
>> The same content is also at
>> http://wiki.qemu.org/Features/LiveBlockMigration/1.2
>>
> 
>> * query-block-jobs: BlockJobInfo gets two new fields, paused and
>> io-status.  The job-specific iostatus is completely separate from the
>> block device iostatus.
> 
> Is it still true that for mirror jobs, whether we are mirroring is still
> determined by whether 'len'=='offset'?

Yes.

>> * block-job-complete: force completion of mirroring and switching of the
>> device to the target, not related to the rest of the proposal.
>> Synchronously opens backing files if needed, asynchronously completes
>> the job.
> 
> Can this be made part of a 'transaction'?  Likewise, can
> 'block-job-cancel' be made part of a 'transaction'?

Both of them are asynchronous so they would not create an atomic
snapshot.  We could add it later, in the meanwhile you can wrap with
fsfreeze/fsthaw.

> But now that you are adding the possibility of mirroring reverting
> to copying, there is a race where I can probe and see that we are
> in mirroring, then issue a 'block-job-cancel' to affect a copy operation,
> but in the meantime things reverted, and the cancel ends up leaving me
> with an incomplete copy.

Hmm, that's right.  But then this can only happen if you have an error
in the target.  I can make block-job-cancel _not_ resume a paused job.
Would that satisfy your needs?

>> Persistent dirty bitmap
>> =======================
>>
>> A persistent dirty bitmap can be used by management for two reasons.
>> When mirroring is used for continuous replication of storage, to record
>> I/O operations that happened while the replication server is not
>> connected or unavailable.  When mirroring is used for storage migration,
>> to check after a management crash whether the VM must be restarted with
>> the source or the destination.
> 
> Is there a particular file format for the dirty bitmap?  Is there a
> header, or is it just straight bitmap, where the size of the file is an
> exact function of size of the file that it maps?

I think it could be just a straight bitmap.

>> management can restart the virtual
>> machine with /mnt/dest/diskname.img.  If it has even a single zero bit,
> 
> s/zero/non-zero/

Doh, of course.

Paolo