qemu-devel
[Top][All Lists]
Advanced

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

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


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH V2 07/12] qmp: add internal snapshot support in qmp_transaction
Date: Sat, 15 Jun 2013 10:40:13 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6

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...)

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
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
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.)

> +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/

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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