Re: [Qemu-devel] [Bug 1105670] [NEW] Converting vpc image to raw results in an image that is smaller than it should be.

[Stefan Hajnoczi]

On Sat, Jan 26, 2013 at 03:21:27AM -0000, Peter Rehley wrote:
> Public bug reported:

CCed Stefan Weil and Jeff Cody who may be thoughts on this bug.

If you would like to contribute your patch, please see
http://wiki.qemu.org/Contribute/SubmitAPatch.  (Patches attached on the
bug tracker are not reviewed, they must be sent to the
address@hidden mailing list).

> When using qemu-img to convert a 3GB dynamic vhd image to raw, the
> resultant image was smaller than what I was expecting.  I was expecting
> a new raw image of size  3221225472bytes but the size generated was
> 3220955136bytes.  I had similar results when I used a fixed vhd image
> and explicitly specified the format as vpc.
> 
> Details about my configuration
> OS: Centos 5.4, 64bit
> Qemu used 1.1.1-1, but also saw the same behavior on 1.3.3 and the 
> development build.
> 
> Command used for dynamic vhd image file:
> qemu-img convert -O raw inputDynamic.vhd outputFromDynamic.raw
> 
> Command used for fixed vhd image file:
> qemu-img convert f vpc -O raw inputFixed.vhd outputFromFixed.raw
> 
> Both images were first created on hyperv running on windows 2008 r2
> using the hyperv manager interface.  I think I tried their diskpart
> utility and had the same results.
> 
> Output from the following commands (I saw this on Bug#893956)
> $ hexdump -C -n 512 image.VHD
> 00000000  63 6f 6e 65 63 74 69 78  00 00 00 02 00 01 00 00  |conectix........|
> 00000010  00 00 00 00 00 00 02 00  18 25 da 57 77 69 6e 20  |.........%.Wwin |
> 00000020  00 06 00 01 57 69 32 6b  00 00 00 00 c0 00 00 00  |....Wi2k........|
> 00000030  00 00 00 00 c0 00 00 00  18 61 10 3f 00 00 00 03  |.........a.?....|
> 00000040  ff ff ee b1 83 34 83 78  26 0a 13 4f 99 9c 9e e9  |.....4.x&..O....|
> 00000050  dc 93 21 d1 00 00 00 00  00 00 00 00 00 00 00 00  |..!.............|
> 00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> *
> 00000200
> 
> $ hexdump -C -n 512 -s $(($(ls -l image.VHD | awk '{ print $5 }') - 512)) 
> image.VHD
> 56057e00  63 6f 6e 65 63 74 69 78  00 00 00 02 00 01 00 00  |conectix........|
> 56057e10  00 00 00 00 00 00 02 00  18 25 da 57 77 69 6e 20  |.........%.Wwin |
> 56057e20  00 06 00 01 57 69 32 6b  00 00 00 00 c0 00 00 00  |....Wi2k........|
> 56057e30  00 00 00 00 c0 00 00 00  18 61 10 3f 00 00 00 03  |.........a.?....|
> 56057e40  ff ff ee b1 83 34 83 78  26 0a 13 4f 99 9c 9e e9  |.....4.x&..O....|
> 56057e50  dc 93 21 d1 00 00 00 00  00 00 00 00 00 00 00 00  |..!.............|
> 56057e60  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
> *
> 56058000
> -----
> When I investigated this a bit further I found that the disk geometry 
> calculations needed to be one cylinder more than the information stored in 
> the footer size information.  The disk size information in the file was 
> 3221225472 bytes, and the disk geometry was cylinders 6241, heads 10, sectors 
> per cylinder 63.  Multiplying that together and with a sector size of 512 
> gives  3220955136bytes...the size qemu made the image as, but the new image 
> is now smaller than the original image.
> 
> When I added one to the cylinder size I got a size larger than I was
> expecting, but large enough to hold all of the data from the original
> image.
> 
> My suggested fix for this is to add one to the cylinder size when
> reading a vhd image file.  And subtracting one when writing out to a vhd
> file.  I've attached a patch with the suggested fix.
> 
> Please let me know if you need additional information.