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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).