Bug 1124636

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>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.0	CC:	bsarathy, chayang, drjones, hhuang, jcody, juzhang, michen, mkenneth, qzhang, rbalakri, virt-bugs, virt-maint, xfu
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	1124144	Environment:
Last Closed:	2014-11-25 16:02:26 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1124144
Bug Blocks:

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.