|Summary:||qemu-img fail to recognize the Hyper-V Virtual Hard Disk (VHD) format image|
|Product:||Red Hat Enterprise Linux 7||Reporter:||Sibiao Luo <sluo>|
|Component:||qemu-kvm||Assignee:||Jeff Cody <jcody>|
|Status:||CLOSED WONTFIX||QA Contact:||Virtualization Bugs <virt-bugs>|
|Version:||7.0||CC:||bsarathy, chayang, drjones, hhuang, jcody, juzhang, michen, mkenneth, qzhang, rbalakri, virt-bugs, virt-maint, xfu|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2014-11-25 16:02:26 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:||1124144|
Comment 1 Sibiao Luo 2014-07-30 02:18:12 UTC
host info: # uname -r && rpm -q qemu-kvm-rhev 3.10.0-128.el7.x86_64 qemu-kvm-rhev-1.5.3-60.el7ev.x86_64 Results: # qemu-img info sluo1-fixed-size.vhd image: sluo1-fixed-size.vhd file format: raw <----------------- should be vpc virtual size: 1.0G (1073742336 bytes) disk size: 1.0G # qemu-img info sluo2-dynamically-expanding.vhd image: sluo2-dynamically-expanding.vhd file format: vpc virtual size: 1.0G (1073479680 bytes) disk size: 8.0K cluster_size: 2097152 # qemu-img info sluo3-fixed-size.vhdx image: sluo3-fixed-size.vhdx file format: vhdx virtual size: 1.0G (1073741824 bytes) disk size: 1.0G cluster_size: 33554432 # qemu-img info sluo4-dynamically-expanding.vhdx image: sluo4-dynamically-expanding.vhdx file format: vhdx virtual size: 1.0G (1073741824 bytes) disk size: 4.0M cluster_size: 33554432 Best Regards, sluo
Comment 3 Levente Kurusa 2014-07-31 08:38:49 UTC
By default VPC images have a footer, however dynamically growing images have a mirror of it as a header. The original author of the code probably misunderstood the spec and assumed that fixed size images have a header too. (The specs are quite easy to misinterpret...). Since this bug reproduces on upstream as well, I created a patchset which fixes this issue and I will send it to the mailing list soon. Thanks!
Comment 5 Andrew Jones 2014-11-04 10:48:57 UTC
There was a lengthy qemu-devel thread on image format probing that was triggered by Levente's upstream post. I'll reassign this to virt-maint for an image person to pick-up as I'm not sure what the result of the discussion is.
Comment 6 Jeff Cody 2014-11-07 20:45:09 UTC
(In reply to Andrew Jones from comment #5) > There was a lengthy qemu-devel thread on image format probing that was > triggered by Levente's upstream post. I'll reassign this to virt-maint for > an image person to pick-up as I'm not sure what the result of the discussion > is. We probe on the header of an image, and don't open the image up to allow the driver to read the image, which would be required for footer probing. There are existing security issues around the concept of probing, and solutions are still being worked out upstream. I do not think we will support probing of formats that don't contain identifiable information in the first sector or so of the image. For a format such as fixed vhd/vpc, that means the format will need to be explicitly specified. I'll leave this bug open, however, until the probing discussion settles upstream.
Comment 7 Jeff Cody 2014-11-25 16:02:26 UTC
Closing this as WONTFIX, as we don't support probing except on the first 2048 (soon to be 512) bytes.