Re: [Qemu-devel] [RFC] block-trace Low Level Command Supporting Disk Introspection

[Stefan Hajnoczi]

On Mon, May 13, 2013 at 05:21:54PM -0400, Wolfgang Richter wrote:
> I'm working on a new patch series which will add a new QMP command,
> block-trace, which turns on tracing of writes for a specified block device
> and
> sends the stream unmodified to another block device.  The 'trace' is meant
> to
> be precise meaning that writes are not lost, which differentiates this
> command
> from others.  It can be turned on and off depending on when it is needed.
> 
> 
> 
> How is this different from block-backup or drive-mirror?
> --------------------------------------------------------
> 
> block-backup is designed to create point-in-time snapshots and not clone the
> entire write stream of a VM to a particular device.  It implements
> copy-on-write to create a snapshot.  Thus whenever a write occurs,
> block-backup
> is designed to send the original data and not the contents of the new write.
> 
> drive-mirror is designed to mirror a disk to another location.  It operates
> by
> periodically scanning a dirty bitmap and cloning blocks when dirtied.  This
> is
> efficient as it allows for batching of writes, but it does not maintain the
> order in which guest writes occurred and it can miss intermediate writes
> when
> they go to the same location on disk.
> 
> 
> 
> How can block-trace be used?
> ----------------------------
> 
> (1) Disk introspection - systems which analyze the writes going to a disk
> for
> introspection require a perfect clone of the write stream to an original
> disk
> to stay in-sync with updates to guest file systems.
> 
> (2) Replicated block device - two block devices could be maintained as exact
> copies of each other up to a point in the disk write stream that has
> successfully been written to the destination block device.

CCed Benoit Canet, who implemented the quorum block driver to mirror I/O
to multiple images and verify data integrity.

QEMU is accumulating many different approaches to snapshots and
mirroring.  They all have their pros and cons so it's not possible to
support only one approach for all use cases.

The suggested approach is writing a BlockDriver which mirrors I/O to two
BlockDriverStates.  There has been discussion around breaking
BlockDriver into smaller interfaces, including a BlockFilter for
intercepting I/O, but this has not been implemented.  blkverify is an
example of a BlockDriver that manages two child BlockDriverStates and
may be a good starting point.