qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] drive transactions (was Re: [PATCH 2/2 v2] Add the bloc


From: Anthony Liguori
Subject: Re: [Qemu-devel] drive transactions (was Re: [PATCH 2/2 v2] Add the blockdev-reopen and blockdev-migrate commands)
Date: Mon, 27 Feb 2012 08:46:57 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]