From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37260) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S21r3-0003nU-Nn for qemu-devel@nongnu.org; Mon, 27 Feb 2012 09:47:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S21qx-0001Ez-O3 for qemu-devel@nongnu.org; Mon, 27 Feb 2012 09:47:09 -0500 Received: from mail-pz0-f45.google.com ([209.85.210.45]:37549) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S21qx-0001Eu-Hc for qemu-devel@nongnu.org; Mon, 27 Feb 2012 09:47:03 -0500 Received: by dadp14 with SMTP id p14so6352070dad.4 for ; Mon, 27 Feb 2012 06:47:02 -0800 (PST) Message-ID: <4F4B9761.3010601@codemonkey.ws> Date: Mon, 27 Feb 2012 08:46:57 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <20120224170143.78f55d3e@doriath.home> <8eaeb022-ea20-4823-886a-e629bce1c776@zmail16.collab.prod.int.phx2.redhat.com> <20120227091215.7849e558@doriath.home> <4F4B7BCD.6000808@redhat.com> <20120227100645.3f36d52d@doriath.home> <4F4B95A5.3000804@redhat.com> In-Reply-To: <4F4B95A5.3000804@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] drive transactions (was Re: [PATCH 2/2 v2] Add the blockdev-reopen and blockdev-migrate commands) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: kwolf@redhat.com, Jeff Cody , mtosatti@redhat.com, armbru@redhat.com, qemu-devel@nongnu.org, Federico Simoncelli , Luiz Capitulino 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