Re: [Qemu-devel] [PATCH 3/4] block/vpc: give option to force the current_size field in .bdrv_create

[Peter Lieven <pl@kamp.de>]

Am 24.02.2016 um 14:40 schrieb Jeff Cody:
> On Wed, Feb 24, 2016 at 02:07:18PM +0100, Kevin Wolf wrote:
>> 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?
>>
> I don't know about disk2vhd, but I just created a 5G dynamic VHD
> image on Hyper-V, and it produced:
>
> cyl: 10402, heads: 16, secs: 63
> virtual size: 5.0G (5368709120 bytes)
>
> (the virtual size as calculated by CHS in that case would have been
> 5368430592 bytes)
>
> I then tested the reverse - I modified qemu to create a VHD image with
> 5G as the current_size, but maxed out CHS parameters.  I imported it
> into Hyper-V, and it worked fine - just recognized as a 5G disk with
> 5368709120 bytes.

So the idea to set CHS to MAX is not that bad.

>
> But with all that, it seems like it may be better to mimic the Hyper-V
> behavior, and use a new creator app string, with the normal CHS
> values.

But this means that it is not backwards compatible. Maxing out CHS
when forcing the size would mean all old qemu version would look
at current size and not CHS.

Might it be that Hyper-V and others use CHS when an ATA disk is emulated
and the cur_size otherwise? I think this is what virtualbox does.

Peter