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