Description of problem: If you spawn qemu using -drive parameter, and tell it to use format=qcow2, but then have file=/path/to/a/RAW-FILE point to a non-QCow2 file, it gives a meaningless error message $ qemu-img info ~/rootdisk.img image: /home/berrange/rootdisk.img file format: raw virtual size: 1.4M (1474560 bytes) disk size: 1.4M $ ~/usr/qemu-git/bin/qemu -drive file=/home/berrange/rootdisk.img,format=qcow2 qemu: could not open disk image /home/berrange/rootdisk.img: Success It should tell us that this is not a valid QCow2 file. I've not tested, but I suspect other driver formats might have similar problems Version-Release number of selected component (if applicable): qemu-system-x86-0.12.1.2-3.fc12.x86_64 How reproducible: Always Steps to Reproduce: 1. Pass a raw file, but tell qemu it is a qcow2 file 2. 3. Actual results: qemu: could not open disk image /home/berrange/rootdisk.img: Success Expected results: qemu: could not open disk image /home/berrange/rootdisk.img: Not a QCow2 format file Additional info:
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Upstream is a bit different: sudo ./x86_64-softmmu/qemu-system-x86_64 -drive file=/mnt/data/devel/images/winxp.img,format=qcow2 qemu-system-x86_64: -drive file=/mnt/data/devel/images/winxp.img,format=qcow2: could not open disk image /mnt/data/devel/images/winxp.img: Invalid argument ,format=vdi exists with 'Operation not permitted'. So these could still use some work. Reassigning to rawhide for now but probably a good candidate for just moving to the upstream tracker.
Since this was just lingering for years, I've moved it to the upstream qemu tracker: https://bugs.launchpad.net/qemu/+bug/1090600 Closing.