From: Eric Blake <eblake@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: kwolf@redhat.com, fsimonce@redhat.com, qemu-devel@nongnu.org,
stefanha@linux.vnet.ibm.com, lcapitulino@redhat.com
Subject: Re: [Qemu-devel] [PATCH v3 4/8] add mode field to blockdev-snapshot-sync transaction item
Date: Mon, 05 Mar 2012 11:45:33 -0700 [thread overview]
Message-ID: <4F5509CD.6050000@redhat.com> (raw)
In-Reply-To: <1330968842-24635-5-git-send-email-pbonzini@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 3302 bytes --]
On 03/05/2012 10:33 AM, Paolo Bonzini wrote:
> The mode field lets a management application create the snapshot
> destination outside QEMU.
>
> Right now, the only modes are "existing" and "absolute-paths". Mirroring
> introduces "no-backing-file". In the future "relative-paths" could be
> implemented too.
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> blockdev.c | 25 ++++++++++++++++---------
> qapi-schema.json | 21 ++++++++++++++++++++-
> qmp-commands.hx | 10 ++++++++++
> 3 files changed, 46 insertions(+), 10 deletions(-)
>
>
> ##
> +# @NewImageMode
> +#
> +# An enumeration that tells QEMU how to set the backing file path in
> +# a new image file.
> +#
> +# @existing: QEMU should look for an existing image file.
> +#
> +# @absolute-paths: QEMU should create a new image with absolute paths
> +# for the backing file.
> +#
> +# @no-backing-file: QEMU should create a new image with no backing file.
Not present in this patch. Does it need to be rebased into the correct
part of the series?
> +#
> +# Since: 1.1
> +##
> +{ 'enum': 'NewImageMode'
> + 'data': [ 'existing', 'absolute-paths' ] }
> +
> +##
> # @BlockdevSnapshot
> #
> # @device: the name of the device to generate the snapshot from.
> @@ -1127,7 +1145,8 @@
> # @format: #optional the format of the snapshot image, default is 'qcow2'.
> ##
> { 'type': 'BlockdevSnapshot',
> - 'data': { 'device': 'str', 'snapshot-file': 'str', '*format': 'str' } }
> + 'data': { 'device': 'str', 'snapshot-file': 'str', '*format': 'str',
> + '*mode': 'NewImageMode' } }
>
> ##
> # @BlockdevAction
> diff --git a/qmp-commands.hx b/qmp-commands.hx
> index fb4f1df..7c03b62 100644
> --- a/qmp-commands.hx
> +++ b/qmp-commands.hx
> @@ -705,6 +705,13 @@ 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.
>
> +Each new snapshot defaults to being created by QEMU (wiping any
> +contents if the file already exists),
so this is mode of 'absolute-paths', which is the default if mode is not
present,
> but it is also possible to reuse
> +an externally-created file. In the latter case, you should ensure that
> +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.
and this is mode 'existing'. Correct? If so, let's actually call that
out in the wording.
> +
> Arguments:
>
> actions array:
> @@ -715,6 +722,8 @@ actions array:
> - "device": device name to snapshot (json-string)
> - "snapshot-file": name of new image file (json-string)
> - "format": format of new image (json-string, optional)
> + - "mode": whether and how QEMU should create the snapshot file
> + (NewImageMode, optional, default "absolute-paths")
Well, this solves one of my two comments about the above wording, by
calling out the default.
--
Eric Blake eblake@redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]
next prev parent reply other threads:[~2012-03-05 18:46 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-05 17:33 [Qemu-devel] [PATCH v3 0/8] Mirrored block writes Paolo Bonzini
2012-03-05 17:33 ` [Qemu-devel] [PATCH v3 1/8] fix format name for backing file Paolo Bonzini
2012-03-05 17:33 ` [Qemu-devel] [PATCH v3 2/8] qapi: complete implementation of unions Paolo Bonzini
2012-03-06 7:16 ` Mark Wu
2012-03-06 8:14 ` Paolo Bonzini
2012-03-06 8:19 ` Mark Wu
2012-03-06 8:31 ` Paolo Bonzini
2012-03-06 9:41 ` Mark Wu
2012-03-06 10:00 ` Paolo Bonzini
2012-03-05 17:33 ` [Qemu-devel] [PATCH v3 3/8] rename blockdev-group-snapshot-sync Paolo Bonzini
2012-03-05 17:33 ` [Qemu-devel] [PATCH v3 4/8] add mode field to blockdev-snapshot-sync transaction item Paolo Bonzini
2012-03-05 18:45 ` Eric Blake [this message]
2012-03-05 17:33 ` [Qemu-devel] [PATCH v3 5/8] qmp: convert blockdev-snapshot-sync to a wrapper around transactions Paolo Bonzini
2012-03-05 18:55 ` Eric Blake
2012-03-05 19:44 ` Paolo Bonzini
2012-03-05 21:16 ` Paolo Bonzini
2012-03-06 11:30 ` Luiz Capitulino
2012-03-05 17:34 ` [Qemu-devel] [PATCH v3 6/8] Add blkmirror block driver Paolo Bonzini
2012-03-05 17:34 ` [Qemu-devel] [PATCH v3 7/8] add mirroring to transaction Paolo Bonzini
2012-03-05 19:04 ` Eric Blake
2012-03-05 17:34 ` [Qemu-devel] [PATCH v3 8/8] add drive-mirror command and HMP equivalent Paolo Bonzini
2012-03-06 8:02 ` [Qemu-devel] [PATCH v3 9/8] Add the drive-reopen command Paolo Bonzini
2012-03-06 8:52 ` [Qemu-devel] [PATCH v3 10/8] use QSIMPLEQ_FOREACH_SAFE when freeing list elements Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F5509CD.6050000@redhat.com \
--to=eblake@redhat.com \
--cc=fsimonce@redhat.com \
--cc=kwolf@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.