Bug 847425
| Summary: | qemu-img misleading says it can't open a vmdk image | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | bugz |
| Component: | qemu-kvm | Assignee: | Kevin Wolf <kwolf> |
| Status: | CLOSED DEFERRED | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.3 | CC: | acathrow, amit.shah, areis, bsarathy, dyasny, hesemeyt, jraju, juzhang, michen, mkenneth, qzhang, sluo, virt-maint |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-08-13 14:37:48 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: | |||
RHEL6's qemu-img support for VMDK files is not complete, but you're right the error message is misleading and could be improved. Not sure if I agree. qemu failed to open the image, and opening an image includes more than just opening the file on the OS level. So I think the current message is correct (and noone else has complained about it so far). I would agree with adding some more specific error text to it (like "subformat foo not supported"), but this would require a better error infrastructure and isn't nearly as trivial as it may look from the outside. I'm confident that eventually it will happen upstream, but I doubt it's something for RHEL 6. And of course, improved VMDK support would be nice, too, but it doesn't look as if we'd be willing to invest the effort to do this in RHEL 6 either. (In reply to comment #3) > Not sure if I agree. qemu failed to open the image, and opening an image > includes more than just opening the file on the OS level. So I think the > current message is correct (and noone else has complained about it so far). > I would agree with adding some more specific error text to it (like > "subformat foo not supported"), but this would require a better error > infrastructure and isn't nearly as trivial as it may look from the outside. > I'm confident that eventually it will happen upstream, but I doubt it's > something for RHEL 6. That's a fair point: it can't open the image because it can't handle it, not because it doesn't exist. > > And of course, improved VMDK support would be nice, too, but it doesn't look > as if we'd be willing to invest the effort to do this in RHEL 6 either. Indeed. bugz.au, thanks for your report, but we won't be able to fix this on RHEL6 due to limited infrastructure on qemu error-reporting and the support for VMDK is missing. Support for vmdk should be OK in RHEL7. (In reply to comment #3) > Not sure if I agree. qemu failed to open the image, and opening an image > includes more than just opening the file on the OS level. So I think the > current message is correct (and noone else has complained about it so far). > I would agree with adding some more specific error text to it (like > "subformat foo not supported"), but this would require a better error > infrastructure and isn't nearly as trivial as it may look from the outside. > I'm confident that eventually it will happen upstream, but I doubt it's > something for RHEL 6. > > And of course, improved VMDK support would be nice, too, but it doesn't look > as if we'd be willing to invest the effort to do this in RHEL 6 either. If you want to speak a different language, don't expect your users to understand you. I believe, and I am sure most users would agree, that in the context given, open refers to the operating system's open function, not to something internal to the application. The documentation says that ovf files are supported. No ifs, no buts. The documentation and the program should agree, discrepancies fixed. I am trying to move from Debian to RHEL-clone because Debian has problems whic past experience suggests won't be fixed, and I expected it to be fairly easy to do it. I can, of course, use virtualbox or (maybe) VMWare, but that's not what I expected. If there's a workaround that will tide your customers over until RHEL7, this would be a good place to document it or point to the documentation for it. As for "nobody else has complained," that really means nothing at all. I haven't reported any bugs at all to Debian in years as I just said, and my experience here isn't very encouraging. I have a couple of other bugs I haven't quite nailed to the post yet, I wonder whether it's worth the trouble. (In reply to comment #5) > The documentation says that ovf files are supported. No ifs, no buts. The > documentation and the program should agree, discrepancies fixed. Can you point to the place where this is mentioned? > I am trying to move from Debian to RHEL-clone because Debian has problems > whic past experience suggests won't be fixed, and I expected it to be fairly > easy to do it. I can, of course, use virtualbox or (maybe) VMWare, but > that's not what I expected. > > If there's a workaround that will tide your customers over until RHEL7, this > would be a good place to document it or point to the documentation for it. There are a few options for you to consider: * Contact your customer support representative, and ask this bug to be fixed at a high priority. That input will help us prioritize things accordingly for RHEL6. or * Modify this bug report for the documentation to be updated instead of the code to ensure the docs and code are in sync. or * Submit patches upstream which fix this behaviour, and point out the commit ids here so we can look at backporting the patches. Thank you for reporting this bug. I found this page because I searched for the error message "qemu-img: Could not open". The error message "could not open" lead me to these actions: * Verified the file exists and the path is correct * Changed the file permissions to ensure it's not a permission problem * Googled the error message text to find out what this message means. I agree - this is not the right message. I would have expected some message like: "file format not supported" or similar. Kind regards, Thorsten Hesemeyer |
Description of problem: qemu-img misleadingly says it cannot open the specified file Version-Release number of selected component (if applicable): qemu-img-0.12.1.2-2.295.el6.x86_64 How reproducible: Alays Steps to Reproduce: 1. I have some virtualbox machines I am trying to convert to KVM, 2. I exported them as .ofv images. 3. I tried this command, one line: qemu-img convert -O raw /media/9a237ce7-ffd6-4872-acc6-d0966783f992/exports/kstest/kstest-disk1.vmdk /tmp/kstest-disk1.img Actual results: Here, I'm running it under strace: 11:58 root@Boomer# strace -f -e trace=open qemu-img convert -O raw /media/9a237ce7-ffd6-4872-acc6-d0966783f992/exports/kstest/kstest-disk1.vmdk /tmp/kstest-disk1.img open("/etc/ld.so.cache", O_RDONLY) = 3 open("/lib64/librt.so.1", O_RDONLY) = 3 open("/lib64/libpthread.so.0", O_RDONLY) = 3 open("/lib64/libglib-2.0.so.0", O_RDONLY) = 3 open("/lib64/libaio.so.1", O_RDONLY) = 3 open("/usr/lib64/libusbredirparser.so.0", O_RDONLY) = 3 open("/lib64/libz.so.1", O_RDONLY) = 3 open("/lib64/libc.so.6", O_RDONLY) = 3 open("/media/9a237ce7-ffd6-4872-acc6-d0966783f992/exports/kstest/kstest-disk1.vmdk", O_RDONLY|O_NONBLOCK) = 3 open("/media/9a237ce7-ffd6-4872-acc6-d0966783f992/exports/kstest/kstest-disk1.vmdk", O_RDONLY|O_DSYNC|O_CLOEXEC) = 3 Process 5199 attached [pid 5198] open("/media/9a237ce7-ffd6-4872-acc6-d0966783f992/exports/kstest/kstest-disk1.vmdk", O_RDONLY|O_NONBLOCK) = 3 [pid 5198] open("/media/9a237ce7-ffd6-4872-acc6-d0966783f992/exports/kstest/kstest-disk1.vmdk", O_RDONLY|O_CLOEXEC) = 3 qemu-img: Could not open '/media/9a237ce7-ffd6-4872-acc6-d0966783f992/exports/kstest/kstest-disk1.vmdk' qemu-img: Could not open '/media/9a237ce7-ffd6-4872-acc6-d0966783f992/exports/kstest/kstest-disk1.vmdk' 11:59 root@Boomer# file /media/9a237ce7-ffd6-4872-acc6-d0966783f992/exports/kstest/kstest-disk1.vmdk /media/9a237ce7-ffd6-4872-acc6-d0966783f992/exports/kstest/kstest-disk1.vmdk: VMware4 disk image 12:07 root@Boomer# Whatever the problem, it's passed the usual definition of "open." If there's a problem with the content of the disk image, it should diagnose that problem correctly and report that. "Could not open" is wrong and misleading. Expected results: Converted image, maybe with a summary saying all went well. Additional info: