From: Eric Blake <eblake@redhat.com>
To: Max Reitz <mreitz@redhat.com>, Alberto Garcia <berto@igalia.com>,
qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>,
qemu-block@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 1/1] block: Allow passing BlockdevOptions to blockdev-snapshot-sync
Date: Mon, 31 Aug 2015 14:05:08 -0600 [thread overview]
Message-ID: <55E4B374.70800@redhat.com> (raw)
In-Reply-To: <55E4B0CC.6070906@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 3255 bytes --]
On 08/31/2015 01:53 PM, Max Reitz wrote:
> Design question: Would it make sense to instead add a "reference" mode
> to blockdev-snapshot-sync where you can specify a BDS's node-name
> instead of snapshot-file to use an existing BDS as the new top layer,
> ideally an empty one?
Indeed - then blockdev-add can be used to create an unattached BDS (with
all appropriate options), and blockdev-snapshot-sync would then attach
that BDS as the snapshot-file that wraps an existing BDS (without
needing to worry about options).
>
> What we'd then need is a QMP command for creating images. But as far as
> I know we'll need that anyway sooner or later...
Can't blockdev-add already be used for that (at least, for supported
file types)? If not, what would it take to get it there?
>
>
> Comments on the patch itself below.
>
>
> With has_format == false, format will be set to "qcow2" by default. So,
> if the user does not specify the format explicitly, the "driver" field
> has to be set to "qcow2".
>
> I'd rather make specifying @format and @options exclusive, and if
> @options has been specified, its "driver" field should override the
> "format" default.
>
>> +++ b/qapi/block-core.json
>> @@ -697,11 +697,18 @@
>> #
>> # @mode: #optional whether and how QEMU should create a new image, default is
>> # 'absolute-paths'.
>> +#
>> +# @options: #optional options for the new device, with the following
>> +# restrictions for the fields: 'driver' must match the value
>> +# of @format,
>
> As said above, I'd rather make specifying both @options and @format
> exclusive.
>
> Maybe there is even some QAPI magic to enforce that (and for
> 'node-name', too), I don't know...
Not that I know of at the moment, but not to say we can't add some. The
closest we can get is with a flat union, but that requires a
non-optional discriminator field. Maybe we can tweak qapi to make the
discriminator optional (with a default value). Thankfully, it sounds
like Markus' work on introspection would at least let management apps
learn about a new 'options' argument.
>> 'node-name' and @snapshot-node-name cannot be
>> +# specified at the same time, and 'file' can only contain an
>> +# empty string (Since 2.5)
I really don't like the idea of requiring the user to pass in an empty
string. Can we make the field optional instead, and require it to be
omitted in the context where it would otherwise need to be empty, while
still requiring it to be present in existing clients that weren't
prepared for it to be optional? It also feels a bit ad hoc that you
describe that driver/format must be identical, but that other fields
must be mutually exclusive or the empty string; consistency would argue
that since you already handle duplication of driver/format by requiring
them to be the same, that you should also allow duplication and
validation of identical other fields that overlap. (But even better
would be finding a way to not allow overlapping fields to appear in the
first place).
--
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: 604 bytes --]
next prev parent reply other threads:[~2015-08-31 20:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-31 10:00 [Qemu-devel] [PATCH 0/1] Allow passing BlockdevOptions to blockdev-snapshot-sync Alberto Garcia
2015-08-31 10:00 ` [Qemu-devel] [PATCH 1/1] block: " Alberto Garcia
2015-08-31 19:53 ` Max Reitz
2015-08-31 20:05 ` Eric Blake [this message]
2015-08-31 20:12 ` Max Reitz
2015-09-01 11:33 ` Kevin Wolf
2015-09-01 11:31 ` Kevin Wolf
2015-09-01 14:22 ` Alberto Garcia
2015-09-01 14:40 ` Kevin Wolf
2015-09-02 7:04 ` Markus Armbruster
2015-09-02 14:23 ` Alberto Garcia
2015-09-02 15:43 ` Eric Blake
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=55E4B374.70800@redhat.com \
--to=eblake@redhat.com \
--cc=berto@igalia.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.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).