Re: [Qemu-devel] [RFC 4/8] block: add block_backup QMP command

[Stefan Hajnoczi <stefanha@gmail.com>]

On Thu, Mar 14, 2013 at 03:52:16PM -0600, Eric Blake wrote:
> On 03/09/2013 03:22 PM, Stefan Hajnoczi wrote:
> > @block-backup
> > 
> > Start a point-in-time copy of a block device to a new destination.
> > 
> 
> I'm trying to figure out how this is different from drive-mirror.  If I
> understand correctly:
> 
> After starting drive-mirror, a write to the block device is also written
> to the mirror, so that the destination sees the new data
> 
> After starting block-backup, a write to the block device flushes the old
> data to the destination, so that the destination sees the old data
> 
> Timing-wise, I can accomplish a backup through either command, with the
> following differences:
> 
> With drive-mirror, I start a job, wait for it to hit sync'd state, then
> cancel the job. The copy is tied to the point where I cancel, and the
> moment I cancel, I no longer have to worry about keeping the destination
> writable (that is, the bulk of the copying is done prior to the point in
> time).
> 
> With block-backup, I start a job, then wait for it to complete.  The
> copy is tied to the point where I started the job, but as that may take
> some time, I have to keep the destination writable until the job
> completes (that is, the bulk of the work is done after the point in time).
> 
> The concept is indeed useful; more so if we can wire this into
> 'transaction' to capture multiple disks at the same point in time.

Although drive-mirror can be used in a similar way, the problem is that
you have to reach sync state before you can make the "point-in-time"
copy.  In other words, you need to plan ahead.

With block-backup the point-in-time copy is made the instant you issue
the command - this is much more practical.  Nevertheless, at one point I
think I asked Paolo if the block-backup code could be a sub-mode of
drive-mirror.  It seems that keeping them as separate block jobs is
reasonable since they work differently.

Regarding 'transaction', I agree.  It is handy to support 'block-backup'
as a 'transaction' action.  It can simplify QMP client error handling
since it is not necessary to manually cancel block jobs that have been
started when the last one fails to start.  Another consideration is that
'transaction' eliminates QMP round-trips and can therefore reduce guest
downtime when 'block-backup' is used after 'migrate' (guest is paused).

Stefan