Re: [Qemu-devel] [PATCH for 1.4] block/vpc: Fix size calculation

[Stefan Weil]

Am 12.02.2013 16:18, schrieb Jeff Cody:
> On Tue, Feb 12, 2013 at 03:47:38PM +0100, Stefan Weil wrote:
>> Am 11.02.2013 22:20, schrieb Jeff Cody:
>>> On Mon, Feb 11, 2013 at 03:14:36PM -0600, Anthony Liguori wrote:
>>>> Paolo Bonzini <address@hidden> writes:
>>>>
>>>>> Il 11/02/2013 21:13, Anthony Liguori ha scritto:
>>>>>> Applied.  Thanks.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Anthony Liguori
>>>>> I guess this was a mistake, please revert.
>>>> No, it wasn't.  The patch was reviewed and tested.  What's the problem.
>>>> It's proposed for 1.4 so it's now or never.
>>>>
>>>> I saw some discussion about improving the detection for the different
>>>> varients of VHD...
>>>>
>>>> I don't mind reverting it, but just want to understand what the issue
>>>> is.
>>>>
>>> Hi Anthony,
>>>
>>> It was tested, the problem is that this will break existing support
>>> for Virtual PC VHD files under certain conditions (most likely
>>> exporting from qemu to VPC, but I don't know if we could guarantee
>>> that is the only way).
>>>
>>>
>>> Jeff
>> Hi Jeff,
>>
>> exporting from QEMU to VPCwill work because QEMU uses
>> images where real size = CHS size, so those images work
>> no matter whether the patch was applied or not.
>>
>> See my separate mail for more reasoning.
>>
>> I see no way how the patch could break a realistic test scenario,
>> but I know such scenarios which are broken without the patch.
>>
>>
>> Stefan
>>
> Hi Stefan,
>
> I should have been clearer when I said export - I am talking about
> qemu modifying an existing VHD image created by VPC, and then trying
> to use image in VPC again.
>
> Here is a simple way to see how the proposed patch breaks current VHD
> compatibility:
>
> 1.) Under VPC, define a new VM that boots from a live dvd iso (I used
> a puppy linux iso because it was small and quick to test:
> http://puppylinux.org). For the hard drive for the machine, define a
> 128GB dynamic drive.  (test.vhd).  You don't need to boot this VM yet.
>
> 2.) Now, under QEMU, boot again to a live iso or existing linux image,
> and use the newly created test.vhd.  Create a single partition, using
> the fdisk defaults for the maximum size.  Shutdown.
>
> 3.) Use that same VHD image and boot the live iso with your VPC
> machine.  Try to mount the partition you created under qemu with the
> guest in VPC.  It will fail to detect the partition, and complain
> about invalid geometry.
>
> I think your patch is definitely needed, don't get me wrong, and I can
> verify that it works - for the bug report, I even came to the same
> conclusion.  I just think it needs to be done such that we don't break
> something that used to work, and testing shows that it does,
> unfortunately.
>
> Thanks,
> Jeff


Hi Jeff,

the scenario which you describe here is not one which I'd call
"realistic". Why should a user create a VHD image with VPC
and then create the partitions using QEMU?Yes, if this is
done, the image is no longer compatible with VPC as soon as
blocks after the CHS size are used. The same kind of problem
would occur if Hyper-V or VirtualBox were use instead of QEMU.

I expect that the common use case is a user who creates and uses
a VHD image with VPC (this includes partitioning). This kind of
image can later be used with QEMU, VirtualBox or Hyper-V without
problems as long as the partitions are not modified to use the
additional blocks which are available after the CHS size.

This restriction seems acceptable for me. I see no way to avoid it.

The same kind of restriction exists for real hardware since the
introduction of LBA as soon as software (BIOS, bootloaders,
DOS, ...) tried using CHS.

Regards,

Stefan