Re: [Qemu-devel] drive transactions (was Re: [PATCH 2/2 v2] Add the blockdev-reopen and blockdev-migrate commands)

[Anthony Liguori <anthony@codemonkey.ws>]

On 02/27/2012 08:39 AM, Paolo Bonzini wrote:
> On 02/27/2012 02:06 PM, Luiz Capitulino wrote:
>> IMHO, this is asking for two commands, where cases 1&  2 is one of them
>> and cases 3&  4 is the other one. Note how 'incremental' goes away and
>> 'new_image_file' really becomes an optional.
>
> I really would have no idea on naming except perhaps "drive_migrate" and
> "funny_drive_migrate_for_ovirt".  But actually I must admit that it's a
> rat's nest.
>
> First, there's no reason why live-snapshotting to new_image_file
> shouldn't be handled within QEMU.  That would make the above table much
> more orthogonal.  However, oVirt likes to create its own snapshots.
>
> Perhaps we do need to rethink this together with group snapshots.
>
> There are four kinds of operations that we do on block devices:
> (a) create an image.  This is part of what blockdev-snapshot does.
> (b) switch a block device to a new image.  drive-reopen does this.
> (c) add mirroring to a new destination.
> (d) activate streaming from a base image
>
> drive-migrate does (b) and (c), will do (a) and (d) when we add
> pre-copy, and should do (a) right now if Federico wasn't an oVirt
> developer. :)
>
> Thinking more about it, the commands we _do_ need are:
> - start a transaction
> - switch to a new image
> - add mirroring to a new destination
> - commit a transaction
> - rollback a transaction
> - query transaction errors

I think a better way to think of this is as a batch submission.  It would be 
relatively easy to model in QMP too (just have a batch-command that has a list 
of commands as it's argument).

The difference between batch submission and a transaction is atomic rollback. 
But I don't think atomic rollback is really needed here.

Regards,

Anthony Liguori