Bug 1071058

Yes, this is known. You're probably better off not creating images containing a
colon, too, because using them is more troublesome...

Anyway, in the long run we should allow this. I guess this is something like the
changes we already made to bdrv_open(), so maybe bdrv_create() should follow
suit. The tricky design question is how to mix creation options and (probably
mostly protocol level) open options for underlying BDSes, no top of which the
new image should be created.

I'll move it to 7.1 for now, but this needs considerable upstream work and is
not our highest priority, so it might well end up later.

Tried it on qemu-kvm-rhev-2.1.2-1 with the same steps as comment #0.

host info:
# rpm -qa | grep qemu
qemu-img-rhev-2.1.2-1.el7.x86_64
qemu-kvm-rhev-2.1.2-1.el7.x86_64

step:
1.# qemu-img create -f qcow2 ip-192.168.254.185:asdf 5G
  # qemu-img create -f qcow2 disk:test 5G

Results:
1.# qemu-img create -f qcow2 ip-192.168.254.185:asdf 5G
qemu-img: ip-192.168.254.185:asdf: Unknown protocol 'ip-192.168.254.185:asdf'
  # qemu-img create -f qcow2 disk:test 5G
qemu-img: disk:test: Unknown protocol 'disk:test'


Base on above, this issue did not fixed at all, Re-assign it to fix, thanks.

Best Regards,
chcheng

Hi,

This issue is not fixable like that. "disk:test" designates an object named "test" to be used over a protocol named "disk". This is just how it is. If we were to make all invalid protocol names to be interpreted as file names (i.e., "disk:test" is being interpreted as "file:disk:test" because there is no protocol named "disk"), then you could still create a file named "nbd:test" and that would not work.

So, as stated in comment 5 for bug 1072130, there are (at least) two correct ways to access such files: By using "./disk:test" or by explicitly specifying the desired protocol, i.e. "file:disk:test". The latter is broken in RHEL 6 and RHEL 7 and will not be fixed (because "./disk:test" works just fine); in RHEV 7 on the other hand, it has been fixed (which is why this BZ has not been closed with WONTFIX like BZ 1072130).

Additionally, qemu-io and qemu itself allow an option syntax which makes protocol prefixes obsolete. Therefore, "qemu-io -c 'open -o file.filename=disk:test' -c info" works as well. qemu-img on the other hand does not have this capability, so you need to use "./disk:test" or "file:disk:test" there.

Changing status therefore back to MODIFIED; if this resolution is not considered enough, I will close this BZ with WONTFIX.

Max

Verify:
Version of components:
qemu-kvm-1.5.3-70.el7.x86_64

As comment 7 show, verify this bz as followings:
# qemu-img create -f qcow2 ./ip-192.168.254.185:asdf 5G
Formatting './ip-192.168.254.185:asdf', fmt=qcow2 size=5368709120 encryption=off cluster_size=65536 lazy_refcounts=off 

# qemu-img create -f qcow2 file:ip-192.168.254.185:asdf 5G
Formatting 'file:ip-192.168.254.185:asdf', fmt=qcow2 size=5368709120 encryption=off cluster_size=65536 lazy_refcounts=off

As above show and based on comment 7, this bz has been verified.


Hi Max,

  Could you give the fixed version of qemu-kvm, so QE can use it to reproduce this bz. Thx.

Best Regards,
Jun Li

Verify this bz:
Version of components:
qemu-kvm-rhev-2.1.2-1.el7.x86_64

As comment 7 show, verify this bz as followings:
# qemu-img create -f qcow2 ./ip-192.168.254.185:asdf 5G
Formatting './ip-192.168.254.185:asdf', fmt=qcow2 size=5368709120 encryption=off cluster_size=65536 lazy_refcounts=off 

# qemu-img create -f qcow2 file:ip-192.168.254.185:asdf 5G
Formatting 'file:ip-192.168.254.185:asdf', fmt=qcow2 size=5368709120 encryption=off cluster_size=65536 lazy_refcounts=off 

As above show and based on comment 7, this bz has been verified.

Hi Jun,

as far as I can see, it's contained in any of the RHEV7 qemu versions. That includes qemu-kvm-2.1.2-1.el7, qemu-kvm-rhev-2.0.0-2.el7ev, qemu-kvm-rhev-2.1.0-1.el7 and qemu-kvm-rhev-2.1.2-2.el7.

To test this issue, you should not only create a file with qemu-img, but also verify its filename. Before the fix I'm referring to "qemu-img create -f qcow2 file:foo:bar 64M" would create a file named "file:foo:bar", whereas it should be named "foo:bar".

Max

(In reply to Max Reitz from comment #11)
> Hi Jun,
> 
> as far as I can see, it's contained in any of the RHEV7 qemu versions. That
> includes qemu-kvm-2.1.2-1.el7, qemu-kvm-rhev-2.0.0-2.el7ev,
> qemu-kvm-rhev-2.1.0-1.el7 and qemu-kvm-rhev-2.1.2-2.el7.
> 
> To test this issue, you should not only create a file with qemu-img, but
> also verify its filename. Before the fix I'm referring to "qemu-img create
> -f qcow2 file:foo:bar 64M" would create a file named "file:foo:bar", whereas
> it should be named "foo:bar".
> 
> Max

ok, thanks.

Verify this bz:
Version of components:
qemu-kvm-rhev-2.1.2-1.el7.x86_64

As comment 7 show, verify this bz as followings:
# qemu-img create -f qcow2 ./ip-192.168.254.185:asdf 5G
Formatting './ip-192.168.254.185:asdf', fmt=qcow2 size=5368709120 encryption=off cluster_size=65536 lazy_refcounts=off 

# ll
total 196
-rw-r--r--. 1 root root 197120 Oct 13 14:28 ip-192.168.254.185:asdf

# qemu-img info ./ip-192.168.254.185\:asdf 
image: ./ip-192.168.254.185:asdf
file format: qcow2
virtual size: 5.0G (5368709120 bytes)
disk size: 196K
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false
---
# qemu-img create -f qcow2 file:ip-192.168.254.185:asdf 5G
Formatting 'file:ip-192.168.254.185:asdf', fmt=qcow2 size=5368709120 encryption=off cluster_size=65536 lazy_refcounts=off
 
# ll
total 196
-rw-r--r--. 1 root root 197120 Oct 13 14:31 ip-192.168.254.185:asdf

# qemu-img info file:ip-192.168.254.185:asdf
image: ip-192.168.254.185:asdf
file format: qcow2
virtual size: 5.0G (5368709120 bytes)
disk size: 196K
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: false


As above show and based on comment 7 and comment 11, this bz has been verified.

BTW, based on comment 11, no version of qemu-kvm-rhev to reproduce this bz.

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.

https://rhn.redhat.com/errata/RHSA-2015-0624.html