Re: [Qemu-devel] [PATCH 5/7] block/vpc: Fix size calculation

[Stefan Weil]

Am 05.02.2013 14:02, schrieb Jeff Cody:
> Hi Kevin,
>
> I can verify the issue he is seeing (see my comments on Bug 1105670
> (https://bugs.launchpad.net/qemu/+bug/1105670/comments/3), at least
> using Hyper-V.  I haven't tried it against VPC from Win7.
>
> Jeff


Hi Kevin,

a rebased version of this patch was just sent to qemu-devel.
It is needed to fix the bug mentioned above and should be
applied to QEMU 1.4 and also earlier branches.

Here is the test scenario which I have run:

* Create a (dynamic) 3 GiB VHD image with MS tools (command line
  or explorer with Windows 7 or newer).

* Run a VM (Linux guest) which uses the new VHD image as 2nd disk.

* Check the disk size from the guest's point of view.
  Either run dmesg (look for /dev/sdb), a partitioning tool
  like fdisk or cfdisk, or simply dump the whole disk using
  od or dd,

I used VirtualBox and latest QEMU for the VM.

The VHD image can also be created using VirtualBox.
This gives identical results.

Here are my results:

* The expected size is 3 GiB = 3 * 1024 * 1024 * 1024 Byte = 3221225472 
Byte.

* Linux on VirtualBox reports 3221225472 Byte (correct)
  (tested with dmesg, fdisk, cfdisk and od - all give same value).

* Linux on QEMU reports 3220955136 Byte (wrong)
  (tested with dmesg, fdisk, cfdisk and od - all give same value).

* qemu-img (unpatched) reports 3220955136 Byte (wrong).

With the patch for block/vpc.c applied, Linux on QEMU and qemu-img
report the correct size.

To summarize,

* Guests using unpatched QEMU only see part of the VHD image.
  This is bad for images written with other emulators like VirtualBox,
  because the last blocks are invisible for QEMU.
  It works with images which were created by unpatched qemu-img and which
  were used only with unpatched QEMU.

* Unpatched qemu-img only converts part of the VHD image.
  This also can result in a corrupt file system because of missing
  last blocks.

* Unpatched qemu-img creates images which are larger than required
  because it increased the size until the unpatched QEMU got enough
  blocks. This won't do any harm beside using too much resources
  as long as those images are only used with unpatched QEMU.
  Guests running on other emulators or on the patched QEMU will see
  a larger disk. If they use the additional blocks, that image
  must no longer used with unpatched QEMU.

* As long as users only switch from unpatched to patched versions,
  they won't have a problem. Switching from patched to unpatched
  can be fatal, and the same already applies to switching from
  other VHD tools / emulators to unpatched QEMU.

=> All branches with VHD support (vpc.c) should be fixed.

=> Delaying the patch increases the problem, as VHD is quite common.

Regards

Stefan W.