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

[Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>]

On Fri, May 25, 2012 at 01:17:04PM +0200, Paolo Bonzini wrote:
> Il 25/05/2012 11:43, Stefan Hajnoczi ha scritto:
> > On Thu, May 24, 2012 at 03:41:29PM +0200, Paolo Bonzini wrote:
> >> 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.
> > 
> > For incremental backups we also need a dirty bitmap API.  This allows
> > backup software to determine which blocks are "dirty" in a snapshot.
> > The backup software will only copy out the dirty blocks.
> > 
> > (For external snapshots the "dirty bitmap" is actually the qemu-io -c
> > map of is_allocated clusters.  But for internal snapshots it would be a
> > diff of image metadata which results in a real bitmap.)
> 
> Perhaps that be simply a new qemu-img subcommand?  It should be possible
> to run it while the VM is offline.  Then the file that is produced could
> be fed to blockdev-dirty-enable.

For both continuous replication and incremental backups we cannot
require that the guest is shut down in order to collect the dirty
bitmap, I think.

Also, anything to do with internal snapshots needs to be online since
QEMU will still have the image file open and be writing to it.  With
backing files we have a little bit more wiggle room when QEMU has
backing files open read-only.

I think we really need a libvirt API because a local file not only has
permissions issues but also is not network transparent.  The continuous
replication server runs on another machine, how will it access the dirty
bitmap file?

Stefan