Re: [Qemu-devel] [PATCH V2 07/12] qmp: add internal snapshot support in qmp_transaction

[Wenchao Xia]

  Will fix the grammar, thanks for checking.


> On 06/14/2013 12:39 PM, Wenchao Xia wrote:
> > Unlike savevm, the qmp_transaction interface will not generate
> > snapshot name automatically, saving trouble to return information
> > of the new created snapshot. The snapshot name should not mess up
> > with snapshot ID, there is a check for it.
> >
> > Although qcow2 support storing multiple snapshots with same name
> > but different ID, here it will fail when an snapshot with that name
> > already exist before the operation. Format such as rbd do not support
> > ID at all, and in most case, it means trouble to user when he faces
> > multiple snapshots with same name, so ban that case.
> >
> > Snapshot ID can't be specified in this interface.
> >
> > Signed-off-by: Wenchao Xia <address@hidden>
> > ---
> >   blockdev.c       |  118 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >   qapi-schema.json |   16 +++++++
> >   qmp-commands.hx  |   32 +++++++++++---
> >   3 files changed, 159 insertions(+), 7 deletions(-)
>
> > +++ b/qapi-schema.json
> > @@ -1613,6 +1613,21 @@
> >   { 'type': 'BlockdevSnapshot',
> >     'data': { 'device': 'str', 'snapshot-file': 'str', '*format': 'str',
> >               '*mode': 'NewImageMode' } }
> > +##
> > +# @BlockdevSnapshotInternal
> > +#
> > +# @device: the name of the device to generate the snapshot from
> > +#
> > +# @name: the name of the internal snapshot to be created
> > +#
> > +# Notes: In transaction, if any snapshot matching @name exists, the operation
> > +#        will fail. If the name is a numeric string, it will also fail. Only
> > +#        some image format support it, for example, qcow2, rbd, and sheepdog.
>
> s/format/formats/
>
> > +#
> > +# Since: 1.6
> > +##
> > +{ 'type': 'BlockdevSnapshotInternal',
> > +  'data': { 'device': 'str', 'name': 'str' } }
> >
> >   ##
> >   # @TransactionAction
> > @@ -1623,6 +1638,7 @@
> >   { 'union': 'TransactionAction',
> >     'data': {
> >          'blockdev-snapshot-sync': 'BlockdevSnapshot'
> > +       'blockdev-snapshot-internal-sync': 'BlockdevSnapshotInternal'
>
> Invalid JSON - you need a comma between name-value pairs. (I _wish_ JSON
> had allowed trailing commas, the way C99 does, because it reduces the
> size of diffs when adding an element at the end...)
  Will fix it. By the way, why the build/run can succeed without comma
in my test....

> Yet another instance of the introspection problem.  Is there some other
> patch in this series that introduces a standalone command that witnesses
> whether this transaction is available?  If so, I'm okay; if not, then
  You mean a command detecting whether
'blockdev-snapshot-internal-sync' is available? No I haven't introduce
it, a standalone command for 'TransactionAction' type detection seems
not so wisely, maybe integration it in qapi capability query.

> libvirt won't know if this transaction is available without
> introspection, or by trying it first and detecting the error when it is
> not available.  For the purposes of transactions, since any failure
> rolls back the entire transaction (including the failure of an unknown
> action within the transaction), the try-and-fail approach may be
> sufficient, even if it is not the prettiest.
>
> > +++ b/qmp-commands.hx
> > @@ -948,13 +948,13 @@ transaction
> >   -----------
> >
> >   Atomically operate on one or more block devices.  The only supported
> > -operation for now is snapshotting.  If there is any failure performing
> > -any of the operations, all snapshots for the group are abandoned, and
> > -the original disks pre-snapshot attempt are used.
> > +operations for now are internal and external snapshotting.  A list of
> > +dictionaries is accepted, that contains the actions to be performed.  The
> > +sequence of the requests will not affect the result.
>
> Not true.  Taking an internal and then an external snapshot has a
> different effect than taking an external and then internal snapshot of
> the same disk.  The sequence of requests is significant, because it
  In external case, the device changes its active image in commit()
stage, so it will not affect internal snapshot. For example:

Taking an internal snapshot sn0 on ide-hd0 with image0.qcow2, then
an external snapshot to create image1.qcow2, result in:
image0.qcow2(sn0)-->image1.qcow2.

Taking an external snapshot to create image1.qcow2 on ide-hd0 with 
image0.qcow2, then an external an internal snapshot sn0 on ide-hd0:
image0.qcow2(sn0)-->image1.qcow2.

  However, the comments reminds me that it maybe different to
take two snapshots sn0, sn1 on same device with different sequence:
the name looks the same, but the actually L1 table contents may
change according to the sequence, although invisible to user.
Maybe I should remove this line in document.

> controls which of two files involved contains the internal snapshot.
>
> > -A list of dictionaries is accepted, that contains the actions to be performed.
> > -For snapshots this is the device, the file to use for the new snapshot,
> > -and the format.  The default format, if not specified, is qcow2.
> > +For external snapshot, The dictionary is the device, the file to use for the
>
> s/snapshot, The/snapshots, the/
> s/dictionary is/dictionary contains/
>
> > +new snapshot, and the format.  The default format, if not specified, is qcow2.
> >
> >   Each new snapshot defaults to being created by QEMU (wiping any
> >   contents if the file already exists), but it is also possible to reuse
> > @@ -963,6 +963,18 @@ the new image file has the same contents as the current 
> > one; QEMU cannot
> >   perform any meaningful check.  Typically this is achieved by using the
> >   current image file as the backing file for the new image.
> >
> > +On fail the original disks pre-snapshot attempt will be used.
> > +
> > +For internal snapshot, The dictionary is the device and the snapshot's name.
>
> s/snapshot, The/snapsohts, the/
> s/dictionary is/dictionary contains/
>
> > +If name is a numeric string which will mess up with ID, the request will be
> > +rejected.  For example, name "99" is not a valid name.  If an internal snapshot
> > +matching name already exists, the request will be also rejected.  Only some
> > +image format support it, for example, qcow2, rbd, and sheepdog.
> > +
> > +On fail, qemu will try delete new created internal snapshot in the
>
> s/fail/failure/
>
> why "try"?  The point of a transaction is that it either completely
> happens or is completely aborted.  If you are leaving behind garbage
> after a failure later in the transaction, then you didn't design the
> transaction correctly.  (And yes, we have an existing bug where external
> snapshots that get aborted after creating an empty destination file are
> leaving behind garbage, but that's pre-existing and unrelated to your
> feature addition.)
  I can't find a perfect way to rollback disks, since it may I/O error.
The same thing happens to external case, try delete seems the best way.
Consider breaking qcow_snapshot_create() into 3 stage, there would not
be much improvement for same reason. The best thing I can see is make
sure it is fixable by qemu-img.

> > +transaction.  When I/O error make delete fail, user need to fix it later
>
> s/make delete fail/causes deletion failure/
> s/user need/the user needs/


--
Best Regards

Wenchao Xia