On 7/6/2015 at 06:42 PM, in message <address@hidden>, Peter Lieven
<address@hidden> wrote:
Am 06.07.2015 um 11:44 schrieb Chun Yan Liu:
While testing with a 1GB VHD file created on win7, found that the VHD file
size reported on Windows is different from that is reported by qemu-img
info or within a Linux KVM guest.
Created a dynamic VHD file on win7, on Windows, it is reported 1024MB
(2097152 sectors). But with qemu-img info or within a Linux KVM guest,
it is reported 1023MB (2096640 sectors).
The values in the footer_buf are as follows:
creator_app: "win "
cylinders: 0x820 (2080)
heads: 0x10 (16)
cyl/sec: 0x3f (63)
current_size: 0x40000000 (1G)
So, if using current_size, it's correct; but using CHS will get a smaller
size.
Should we add a check in this case and use "current_size" instead of
CHS?
As far as I remember the issue was and still is that there is no official
spec that says
use current_size in case A and CHS in case B.
Understand.
If currrent_size is greater than CHS and Windows would use CHS (we don't
know that) we might run into issues if Qemu uses current_size. In this
cas we would write data beyond the end of the container (from Windows
perspective).
That's right. The fact is in our testing we found Windows does not use CHS
but current_size (from testing result), we create and get the VHD parted on
Windows, then take the VHD file into Linux KVM guest, it fails to show partition
table (since the reported disk size is shrinking, some of the partitions extend
beyond the end of the disk).