Bug 528678 - qemu-img does not correctly roundtrip data for VPC image format
qemu-img does not correctly roundtrip data for VPC image format
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: qemu (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Kevin Wolf
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F12VirtTarget
  Show dependency treegraph
 
Reported: 2009-10-13 06:52 EDT by Daniel Berrange
Modified: 2009-10-13 15:40 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-10-13 08:32:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Example failure when testing libvirt cloning API (4.34 KB, text/plain)
2009-10-13 07:16 EDT, Daniel Berrange
no flags Details

  None (edit)
Description Daniel Berrange 2009-10-13 06:52:53 EDT
Description of problem:
If you create a raw file, convert it to VPC format with qemu-img, and then convert it back to raw format, the resulting raw file is not the same as the original. All the other disk formats roundtrip reliably, but not VPC.

Version-Release number of selected component (if applicable):


How reproducible:
qemu-0.11.0-6.fc11.i586

Steps to Reproduce:
1. dd if=/dev/zero of=input.img bs=1M count=50
2. qemu-img convert -f raw -O vpc input.img output.img
3. qemu-img convert -f vpc -O raw output.img input2.img
4. md5sum input.img 
5. md5sum input2.img 
6. ls -l input.img 
7. ls -l input2.img 


Actual results:
25e317773f308e446cc84c503a6d1f85  input.img
b699e19dd8d468dbd7264df67ca7f798  input2.img
-rw-rw-r--. 1 berrange berrange 52428800 2009-10-13 11:44 input.img
-rw-r--r--. 1 berrange berrange 52432896 2009-10-13 11:45 input2.img


Expected results:
input.img and input2.img should be identical in everyway.

Additional info:
Comment 1 Daniel Berrange 2009-10-13 07:16:32 EDT
Created attachment 364572 [details]
Example failure when testing libvirt cloning API

FYI, the original way we discovered this bug was via the libvirt TCK's storage cloning tests. That tests creates a raw volume with a special data pattern, and then tests conversion to & from every QEMU writable disk format. We currently have to mark the VPC tests as TODO, since we get md5sum mis-matches after VPC -> raw conversion with unexpected extra NULL bytes appended on the final raw file.
Comment 2 Mark McLoughlin 2009-10-13 07:22:58 EDT
kevin: sounds like something you could sort out quickly if you had some time to spare :-)
Comment 3 Kevin Wolf 2009-10-13 08:32:59 EDT
This is known problem, but I think this is not a qemu bug but a shortcoming of the VHD format (or VirtualPC's handling of that format) where we are doomed to do it wrong at some place. Adding zeros seemed to be the least wrong thing when I implemented it.

For reference, I explained the behaviour in http://lists.gnu.org/archive/html/qemu-devel/2009-08/msg00570.html:
> I think this depends on the definition of "correct". VPC unfortunately
> seems to like contradicting values in its image - CHS geometry and image
> size rarely match. The guest seemed to see the CHS geometry, so I
> changed the code to take the geometry instead of the size header field
> to calculate the image size.

If we didn't round up to the next matching CHS values and used the exact value, our images would seem to be truncated in VirtualPC. You shouldn't observe the problem when you choose the image size so that its size can be represented exactly in a CHS geometry.
Comment 4 Daniel Berrange 2009-10-13 15:40:40 EDT
Worked around the patch in this commit, by adding 4k to the disk size to make it a nice size for CHS geom

http://libvirt.org/git/?p=libvirt-tck.git;a=commit;h=9eedd1ed9887fe294c8d856fc7142c6716799216

Note You need to log in before you can comment on or make changes to this bug.