qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Max Reitz <mreitz@redhat.com>
Cc: qemu-block@nongnu.org, den@openvz.org, jcody@redhat.com,
	eblake@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 7/7] vpc: Support .bdrv_co_create
Date: Tue, 13 Mar 2018 12:32:34 +0100	[thread overview]
Message-ID: <20180313113234.GB4642@localhost.localdomain> (raw)
In-Reply-To: <11f93eeb-19f3-9f3e-edb9-00c1bfb86b37@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 3389 bytes --]

Am 12.03.2018 um 22:49 hat Max Reitz geschrieben:
> On 2018-03-09 22:46, Kevin Wolf wrote:
> > This adds the .bdrv_co_create driver callback to vpc, which
> > enables image creation over QMP.
> > 
> > Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> > ---
> >  qapi/block-core.json |  33 ++++++++++-
> >  block/vpc.c          | 152 ++++++++++++++++++++++++++++++++++++++-------------
> >  2 files changed, 147 insertions(+), 38 deletions(-)
> > 
> > diff --git a/qapi/block-core.json b/qapi/block-core.json
> > index 3a65909c47..ca645a0067 100644
> > --- a/qapi/block-core.json
> > +++ b/qapi/block-core.json
> > @@ -3734,6 +3734,37 @@
> >              '*block-state-zero':    'bool' } }
> >  
> >  ##
> > +# @BlockdevVpcSubformat:
> > +#
> > +# @dynamic: Growing image file
> > +# @fixed:   Preallocated fixed-size imge file
> 
> s/imge/image/
> 
> > +#
> > +# Since: 2.12
> > +##
> > +{ 'enum': 'BlockdevVpcSubformat',
> > +  'data': [ 'dynamic', 'fixed' ] }
> > +
> > +##
> > +# @BlockdevCreateOptionsVpc:
> > +#
> > +# Driver specific image creation options for vpc (VHD).
> > +#
> > +# @file             Node to create the image format on
> > +# @size             Size of the virtual disk in bytes
> > +# @subformat        vhdx subformat (default: dynamic)
> > +# @force-size       Force use of the exact byte size instead of rounding to the
> > +#                   next size that can be represented in CHS geometry
> > +#                   (default: false)
> 
> Now that's weird, again considering your previous approach of only
> rounding things in the legacy path and instead throwing errors from
> blockdev-create.  If you think this is OK to have here, than that's OK
> with me, but I'm not sure this is the ideal way.

Hmm... That's a tough one.

There are a two major differences between VHD and the other image
formats: The first is that rounding is part of the VHD spec. The other
is that while other drivers have reasonable alignment restrictions that
never cause a problem anyway (because people say just '8G' instead of
some odd number), CHS alignment is not reasonable (because '8G' and
similar things will most probably fail).

And then there's the well-known problem that MS is inconsistent with
itself, so force-size=off is required to make images that work with
Virtual PC, but force-size=on may be needed for unaligned image sizes
that HyperV allows, iirc.

> Alternatives:
> 
> 1. Swap the default, not sure this is such a good idea either.
> 
> 2. Maybe add an enum instead.  Default: If the given size doesn't fit
> CHS, generate an error.  Second choice: Use the given size, even if it
> doesn't fit.  Third choice: Round to CHS.

Maybe we should keep force-size, but make it an error if the size isn't
already aligned (consistent with other block drivers).

The legacy code path could still round, but print a deprecation warning.
Once we get rid of the legacy path, users will have to specify sizes
with correct alignment. The error message could suggest using the
rounded value for Virtual PC compatibility or force-share=on otherwise.

That wouldn't be very nice to use, but maybe it's the best we can make
out of a messed up format like VHD.

> I don't want to be stuck up, but once it's a public interface...

The good thing is that it's still x-blockdev-create.

Kevin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

  reply	other threads:[~2018-03-13 11:32 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-09 21:46 [Qemu-devel] [PATCH 0/7] block: .bdrv_co_create for format drivers Kevin Wolf
2018-03-09 21:46 ` [Qemu-devel] [PATCH 1/7] parallels: Support .bdrv_co_create Kevin Wolf
2018-03-12 16:40   ` Max Reitz
2018-03-12 21:30   ` Jeff Cody
2018-03-09 21:46 ` [Qemu-devel] [PATCH 2/7] qemu-iotests: Enable write tests for parallels Kevin Wolf
2018-03-12 16:42   ` Max Reitz
2018-03-12 21:31   ` Jeff Cody
2018-03-09 21:46 ` [Qemu-devel] [PATCH 3/7] qcow: Support .bdrv_co_create Kevin Wolf
2018-03-09 21:58   ` Eric Blake
2018-03-12 12:20     ` Kevin Wolf
2018-03-12 16:49   ` Max Reitz
2018-03-12 21:31   ` Jeff Cody
2018-03-14 11:16   ` Eric Blake
2018-03-14 11:19     ` Daniel P. Berrangé
2018-03-09 21:46 ` [Qemu-devel] [PATCH 4/7] qed: " Kevin Wolf
2018-03-09 22:01   ` Eric Blake
2018-03-12 21:20   ` Max Reitz
2018-03-09 21:46 ` [Qemu-devel] [PATCH 5/7] vdi: " Kevin Wolf
2018-03-12 21:22   ` Max Reitz
2018-03-09 21:46 ` [Qemu-devel] [PATCH 6/7] vhdx: " Kevin Wolf
2018-03-12 19:37   ` Jeff Cody
2018-03-12 21:38   ` Max Reitz
2018-03-09 21:46 ` [Qemu-devel] [PATCH 7/7] vpc: " Kevin Wolf
2018-03-12 21:49   ` Max Reitz
2018-03-13 11:32     ` Kevin Wolf [this message]
2018-03-13 12:25       ` Max Reitz

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=20180313113234.GB4642@localhost.localdomain \
    --to=kwolf@redhat.com \
    --cc=den@openvz.org \
    --cc=eblake@redhat.com \
    --cc=jcody@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /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).