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
