Bug 1124636 - qemu-img fail to recognize the Hyper-V Virtual Hard Disk (VHD) format image
Summary: qemu-img fail to recognize the Hyper-V Virtual Hard Disk (VHD) format image
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Jeff Cody
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 1124144
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-30 02:16 UTC by Sibiao Luo
Modified: 2014-11-25 16:02 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 1124144
Environment:
Last Closed: 2014-11-25 16:02:26 UTC


Attachments (Terms of Use)

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.


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