[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Bug 1105670] [NEW] Converting vpc image to raw results
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [Bug 1105670] [NEW] Converting vpc image to raw results in an image that is smaller than it should be. |
Date: |
Wed, 30 Jan 2013 10:24:44 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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.