Hide Forgot
+++ This bug was initially created as a clone of Bug #811649 +++ Reported by Igor Lvovsky. This affects RHEV-M, so is important. libguestfs cannot open a disk image where the file is a symlink to a filename that contains a colon character. Example: $ qemu-img create -f qcow2 normal 1G $ mv normal contains:colon $ ln -s contains\:colon symlink $ ls -l contains\:colon symlink -rw-r--r--. 1 rjones rjones 197120 Apr 12 19:07 contains:colon lrwxrwxrwx. 1 rjones rjones 14 Apr 12 19:08 symlink -> contains:colon $ guestfish -a symlink run $ echo $? 1 There are two, related problems. (1) It is not possible to specify a filename that contains a colon character on the qemu command line. This is simply a bug in qemu. (2) libguestfs normalizes paths by calling 'realpath(3)'. In the example above, (2) converts the filename 'symlink' to a qemu command line option such as: qemu-kvm -drive file=/tmp/contains:colon,... and that cannot be opened by qemu because of (1). If we didn't normalize the paths, then this we wouldn't hit the qemu problem, because the filename 'symlink' doesn't contain a colon character. It turns out that RHEV paths are always symlinks to filenames that contain colons, so this bug especially affects RHEV. Note also that this is a regression over RHEL 6.2.
Patch series posted here: https://www.redhat.com/archives/libguestfs/2012-April/msg00060.html
The regression test had a bug so a fifth patch is also needed: https://github.com/libguestfs/libguestfs/commit/4b0e525d1dcabe5ffc9b323103ee757be397abb0
Verified with libguestfs-tools-1.16.18-2.el6.x86_64. Before fix (libguestfs-tools-1.16.15-1.el6.x86_64): 1. a symlink (which does not contain colon) to a filename that contains a colon. # qemu-img create -f qcow2 normal 1G # mv normal contains:colon # ln -s contains\:colon symlink # guestfish -a symlink run # echo $? 1 2. a symlink (whick contains conlon) to a filename that does not contains a colon. # dd if=/dev/zero of=test1.img bs=1M count=10 10+0 records in 10+0 records out 10485760 bytes (10 MB) copied, 0.0162689 s, 645 MB/s # ln -s test1.img file:file # guestfish -a file\:file run # echo $? 0 3. a filename contains a colon # cp test1.img test1:1.img # guestfish -a test1\:1.img run # echo $? 1 After fix: 1. a symlink (which does not contain colon) to a filename that contains a colon. # qemu-img create -f qcow2 normal 1G # mv normal contains:colon # ln -s contains\:colon symlink # guestfish -a symlink run # echo $? 0 2. a symlink (whick contains conlon) to a filename that does not contains a colon. (proper error message shows up) # dd if=/dev/zero of=test1.img bs=1M count=10 10+0 records in 10+0 records out 10485760 bytes (10 MB) copied, 0.0162689 s, 645 MB/s # ln -s test1.img file:file # guestfish -a file\:file run libguestfs: error: filename cannot contain ':' (colon) character. This is a limitation of qemu. 3. a filename contains a colon. (proper error message shows up) # cp test1.img test1:1.img # guestfish -a test1\:1.img run libguestfs: error: filename cannot contain ':' (colon) character. This is a limitation of qemu.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause: qemu cannot open any disk image file that contains a ':' character. In addition, there were various bugs in libguestfs's handling and escaping of special characters in filenames. Consequence: libguestfs would sometimes invoke qemu incorrectly resulting in qemu failing to run, and libguestfs itself would sometimes refuse to open a disk image file even though it ought to be able to. Fix: All of the bugs in handling of filenames have been fixed. Result: Any filename can now be opened, except filenames that contains a ':' character (because qemu cannot open these: there is no fix for this qemu bug). libguestfs gives correct diagnostic messages when presented with a filename that contains a ':' character, and doesn't complain about any other character.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2012-0774.html