Bug 847425 - qemu-img misleading says it can't open a vmdk image
qemu-img misleading says it can't open a vmdk image
Status: CLOSED DEFERRED
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
6.3
x86_64 Linux
unspecified Severity high
: rc
: ---
Assigned To: Kevin Wolf
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-11 00:19 EDT by bugz
Modified: 2013-11-08 01:00 EST (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-13 10:37:48 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description bugz 2012-08-11 00:19:03 EDT
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:
Comment 2 Ademar Reis 2012-08-13 09:54:56 EDT
RHEL6's qemu-img support for VMDK files is not complete, but you're right the error message is misleading and could be improved.
Comment 3 Kevin Wolf 2012-08-13 10:26:56 EDT
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.
Comment 4 Ademar Reis 2012-08-13 10:37:48 EDT
(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@js.id.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.
Comment 5 bugz 2012-08-13 20:10:20 EDT
(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.
Comment 6 Amit Shah 2012-08-14 00:21:06 EDT
(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.
Comment 7 Thorsten Hesemeyer 2013-10-29 16:06:08 EDT
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

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