[Top][All Lists]

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

Re: [Qemu-block] [PATCH 3/4] block/vpc: give option to force the current

From: Kevin Wolf
Subject: Re: [Qemu-block] [PATCH 3/4] block/vpc: give option to force the current_size field in .bdrv_create
Date: Wed, 24 Feb 2016 14:07:18 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Am 24.02.2016 um 13:44 hat Peter Lieven geschrieben:
> if the size is forced I would set the chs values to max. this way no
> new creator String is needed and it is even backwards compatible. this
> is what disk2vhd does.

Does disk2vhd do it this way even if the size is smaller than the
maximum that can be represented with CHS?

> > Am 24.02.2016 um 13:24 schrieb Jeff Cody <address@hidden>:
> > 
> >> On Wed, Feb 24, 2016 at 11:19:37AM +0100, Kevin Wolf wrote:
> >> Am 24.02.2016 um 01:47 hat Jeff Cody geschrieben:
> >>> When QEMU creates a VHD image, it goes by the original spec,
> >>> calculating the current_size based on the nearest CHS geometry (with an
> >>> exception for disks > 127GB).
> >>> 
> >>> Apparently, Azure will only allow images that are sized to the nearest
> >>> MB, and the current_size as calculated from CHS cannot guarantee that.
> >>> 
> >>> Allow QEMU to create images similar to how Hyper-V creates images, by
> >>> setting current_size to the specified virtual disk size.  This
> >>> introduces an option, force_size, to be passed to the vpc format during
> >>> image creation, e.g.:
> >>> 
> >>>    qemu-img convert -f raw -o force_size -O vpc test.img test.vhd
> >>> 
> >>> Bug reference: https://bugs.launchpad.net/qemu/+bug/1490611
> >>> 
> >>> Signed-off-by: Jeff Cody <address@hidden>
> >> 
> >> We need to set a different creator string here that makes vpc_open()
> >> recognise the image as current_size based.
> >> 
> >> Kevin
> > 
> > How about "qem2"?  I initially thought about just changing the case on
> > "qemu", but I was afraid some other software may treat the app creator
> > string as case-insensitive.
> > 
> > I'll also update patch 1, to recognize that string as well.

I had the same thoughts about our options, and I wasn't fully convinced
of either, so I didn't propose any. I was leaning towards the case
change, though, as I don't think it should make a difference and it
reads nicer. But "qem2" is okay with me, too.


reply via email to

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