Bug 1124636

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

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!

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.

(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.

Closing this as WONTFIX, as we don't support probing except on the first 2048 (soon to be 512) bytes.