RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1457088 - rbd/iscsi: json: pseudo-protocol format is incompatible with 7.3
Summary: rbd/iscsi: json: pseudo-protocol format is incompatible with 7.3
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.4
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Jeff Cody
QA Contact: Longxiang Lyu
URL:
Whiteboard:
Depends On:
Blocks: 1134878 1371758 1375408 1456511
TreeView+ depends on / blocked
 
Reported: 2017-05-31 05:57 UTC by Han Han
Modified: 2018-08-01 14:13 UTC (History)
21 users (show)

Fixed In Version: qemu-kvm-rhev-2.9.0-12.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-02 04:41:00 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:2392 0 normal SHIPPED_LIVE Important: qemu-kvm-rhev security, bug fix, and enhancement update 2017-08-01 20:04:36 UTC

Description Han Han 2017-05-31 05:57:16 UTC 
Description of problem:
Some json backing images create in RHEL7.3 couldn't be used because of compatibility problem.

Version-Release number of selected component (if applicable):
qemu-kvm-rhev-2.9.0-6.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Create a json backing file in RHEL7.3
# qemu-img create /tmp/xx.img -b 'json:{"file.driver":"rbd","file.filename":"rbd:rbd/rbd.img:mon_host=XX.XX.XX.XX"}' -f qcow2
Formatting '/tmp/xx.img', fmt=qcow2 size=5368709120 backing_file=json:{"file.driver":"rbd",,"file.filename":"rbd:rbd/rbd.img:mon_host=XX.XX.XX.XX"} encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16

2. Try to load it in RHEL7.4.
# /usr/libexec/qemu-kvm /tmp/xx.img
qemu-kvm: Could not open backing file: Parameters 'pool' and 'image' are required

# qemu-img info /tmp/xx.img --backing-chain
qemu-img: Could not open 'json:{"file.driver":"rbd","file.filename":"rbd:rbd/rbd.img:mon_host=10.73.75.52"}': Parameters 'pool' and 'image' are required

But it could be load in RHEL7.3.

Actual results:
As above.

Expected results:
Qemu in RHEL7.4 could parse the json backing files create in RHEL7.3. Otherwise， customers may find some images created before couldn't be used.

Additional info:
Comment 3 Han Han 2017-05-31 06:44:31 UTC 
The bug blocks RHEL7.3's new feature BZ1134878 and RHEL7.4's new feature BZ1371758.
Comment 4 Richard W.M. Jones 2017-05-31 09:18:39 UTC 
If changes are made to libvirt, there are implications for virt-v2v too.

This virt-v2v commit may need to be changed in RHEL 7.4:
https://github.com/libguestfs/libguestfs/commit/ecbf09385033ba0acf14e914927ec81ad20a5308

At the very least we'll need to retest to ensure the libvirt
change doesn't break anything.  If it narrowly only affects
Ceph then we may be fine.
Comment 5 Kevin Wolf 2017-05-31 10:39:06 UTC 
It's probably since commit c7cacb3e that this doesn't work any more.

Of course, "file.filename" was never supposed to be the final interface, but in
theory I think bdrv_file_open() should handle this and parse the "filename" key
into individual options.
Comment 6 Han Han 2017-06-01 01:58:58 UTC 
(In reply to Richard W.M. Jones from comment #4)
> If changes are made to libvirt, there are implications for virt-v2v too.
> 
> This virt-v2v commit may need to be changed in RHEL 7.4:
> https://github.com/libguestfs/libguestfs/commit/
> ecbf09385033ba0acf14e914927ec81ad20a5308
> 
> At the very least we'll need to retest to ensure the libvirt
> change doesn't break anything.  If it narrowly only affects
> Ceph then we may be fine.

It doesn't only affects ceph, but also iscsi and nbd.
Comment 7 Han Han 2017-06-01 02:57:54 UTC 
As I test, only iscsi and rbd don't work. Nbd has no problem because it couldn't use file.filename in RHEL7.3.
For iscsi:
# qemu-img info iscsi.qcow2 
image: iscsi.qcow2
file format: qcow2
virtual size: 30G (32212254720 bytes)
disk size: 196K
cluster_size: 65536
backing file: json:{"file.driver":"iscsi", "file.filename":"iscsi://10.66.5.92:3260/iqn.2016-12.com.virttest:emulated-iscsi-noauth.target0/0"}
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

# /usr/libexec/qemu-kvm iscsi.qcow2
qemu-kvm: Could not open backing file: Need all of transport, portal and target options
Comment 10 Jeff Cody 2017-06-09 15:47:53 UTC 
I have patches that will parse a filename parameter, if present.  Currently, I give precedence to the 'filename' encoded options over passed options.  I am wondering if that is the opposite of how it should be, however.  I'll send patches upstream, and see what qemu-devel has to say.
Comment 11 Jeff Cody 2017-06-12 12:07:05 UTC 
RFC patches posted: https://lists.nongnu.org/archive/html/qemu-devel/2017-06/msg02724.html
Comment 14 Miroslav Rezanina 2017-06-20 06:02:33 UTC 
Fix included in qemu-kvm-rhev-2.9.0-12.el7
Comment 16 Suqin Huang 2017-06-21 02:26:06 UTC 
1. ceph

Reproduce with 

qemu-kvm-rhev-2.9.0-10.el7.x86_64

1). Create snapshot with qemu-img-rhev-2.6.0-28.el7_3.2.x86_64.rpm

# qemu-img create ceph.img -b 'json:{"file.driver":"rbd","file.filename":"rbd:kvm-test/rhel74-virtio.raw:mon_host=10.73.199.64"}' -f qcow2
Formatting 'ceph.img', fmt=qcow2 size=21474836480 backing_file=json:{"file.driver":"rbd",,"file.filename":"rbd:kvm-test/rhel74-virtio.raw:mon_host=10.73.199.64"} encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16

2). boot up snapshot with qemu-kvm-rhev-2.9.0-10.el7.x86_64

qemu-kvm: -drive id=drive_image1,if=none,cache=none,snapshot=off,aio=native,format=qcow2,file=ceph.img: Could not open backing file: Parameters 'pool' and 'image' are required



Fixed with qemu-kvm-rhev-2.9.0-12.el7.x86_64

1). boot up and login snapshot successfully


cmd:
    -drive id=drive_image1,if=none,cache=none,snapshot=off,aio=native,format=qcow2,file=ceph.img \
    -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,addr=03 \
Comment 17 Han Han 2017-06-21 02:30:19 UTC 
(In reply to Suqin Huang from comment #16)
> 1. ceph
> 
> Reproduce with 
> 
> qemu-kvm-rhev-2.9.0-10.el7.x86_64
> 
> 1). Create snapshot with qemu-img-rhev-2.6.0-28.el7_3.2.x86_64.rpm
> 
> # qemu-img create ceph.img -b
> 'json:{"file.driver":"rbd","file.filename":"rbd:kvm-test/rhel74-virtio.raw:
> mon_host=10.73.199.64"}' -f qcow2
> Formatting 'ceph.img', fmt=qcow2 size=21474836480
> backing_file=json:{"file.driver":"rbd",,"file.filename":"rbd:kvm-test/rhel74-
> virtio.raw:mon_host=10.73.199.64"} encryption=off cluster_size=65536
> lazy_refcounts=off refcount_bits=16
> 
> 2). boot up snapshot with qemu-kvm-rhev-2.9.0-10.el7.x86_64
> 
> qemu-kvm: -drive
> id=drive_image1,if=none,cache=none,snapshot=off,aio=native,format=qcow2,
> file=ceph.img: Could not open backing file: Parameters 'pool' and 'image'
> are required
> 
> 
> 
> Fixed with qemu-kvm-rhev-2.9.0-12.el7.x86_64
> 
> 1). boot up and login snapshot successfully
> 
> 
> cmd:
>     -drive
> id=drive_image1,if=none,cache=none,snapshot=off,aio=native,format=qcow2,
> file=ceph.img \
>     -device
> virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,addr=03 \

Pls try gluster with inet type as https://bugzilla.redhat.com/show_bug.cgi?id=1451557#c3 says. This element is added since qemu-2.9, too.
Comment 18 Suqin Huang 2017-06-21 02:32:21 UTC 
2. iscsi

1). reproduce with qemu-kvm-rhev-2.9.0-10.el7.x86_64

qemu-kvm: -drive id=drive_image1,if=none,cache=none,snapshot=off,aio=native,format=qcow2,file=iscsi.img: Could not open backing file: iSCSI: Failed to connect to LUN : Failed to log in to target

2). Fixed in qemu-kvm-rhev-2.9.0-12.el7.x86_64

boot up and login snapshot successfully
Comment 19 Suqin Huang 2017-06-21 03:04:43 UTC 
> Pls try gluster with inet type as
> https://bugzilla.redhat.com/show_bug.cgi?id=1451557#c3 says. This element is
> added since qemu-2.9, too.

Hi Hanhan,

is it qemu issue? I could not reproduce with qemu-kvm-rhev-2.9.0-10.el7.x86_64

1. Create snapshot 

#qemu-img create -f qcow2 gluster.img -b 'json:{"file.driver":"gluster","file.volume":"gv0","file.path":"rhel74-64-virtio.qcow2","file.logfile":"/tmp/log","file.debug":9,"file.server":[ {"type":"inet","host":"10.73.199.200","port":"24007"}]}' 

Formatting 'gluster.img', fmt=qcow2 size=21474836480 backing_file=json:{"file.driver":"gluster",,"file.volume":"gv0",,"file.path":"rhel74-64-virtio.qcow2",,"file.logfile":"/tmp/log",,"file.debug":9,,"file.server":[ {"type":"inet",,"host":"10.73.199.200",,"port":"24007"}]} encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16

2. boot up and login the snapshot successfully

    -drive id=drive_image1,if=none,cache=none,snapshot=off,aio=native,format=qcow2,file=gluster.img \
    -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,addr=03 \
Comment 20 Suqin Huang 2017-06-21 03:49:59 UTC 
According to comment16, comment18 and comment19, update bug status to VERIFIED
Comment 21 Han Han 2017-06-21 07:12:45 UTC 
(In reply to Suqin Huang from comment #19)
> > Pls try gluster with inet type as
> > https://bugzilla.redhat.com/show_bug.cgi?id=1451557#c3 says. This element is
> > added since qemu-2.9, too.
> 
> Hi Hanhan,
> 
> is it qemu issue? I could not reproduce with
> qemu-kvm-rhev-2.9.0-10.el7.x86_64
> 
> 1. Create snapshot 
> 
> #qemu-img create -f qcow2 gluster.img -b
> 'json:{"file.driver":"gluster","file.volume":"gv0","file.path":"rhel74-64-
> virtio.qcow2","file.logfile":"/tmp/log","file.debug":9,"file.server":[
> {"type":"inet","host":"10.73.199.200","port":"24007"}]}' 
> 
> Formatting 'gluster.img', fmt=qcow2 size=21474836480
> backing_file=json:{"file.driver":"gluster",,"file.volume":"gv0",,"file.path":
> "rhel74-64-virtio.qcow2",,"file.logfile":"/tmp/log",,"file.debug":9,,"file.
> server":[ {"type":"inet",,"host":"10.73.199.200",,"port":"24007"}]}
> encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16
> 
> 2. boot up and login the snapshot successfully
> 
>     -drive
> id=drive_image1,if=none,cache=none,snapshot=off,aio=native,format=qcow2,
> file=gluster.img \
>     -device
> virtio-blk-pci,id=image1,drive=drive_image1,bootindex=0,bus=pci.0,addr=03 \

I am sorry. I misunderstood it. It is not a qemu issue.I should try it in libvirt.
Comment 22 Han Han 2017-06-22 00:57:28 UTC 
Hi Jeff,
When use sheepdog url format:
# qemu-img create -f qcow2 -b 'json:{"file.driver":"sheepdog","file.filename":"sheepdog://10.66.5.92:7000/Alice"}' /var/lib/libvirt/images/sheepdog.qcow2
qemu-img: /var/lib/libvirt/images/sheepdog.qcow2: Parameter 'type' is missing

When using the new format:
# qemu-img create -f qcow2 -b 'json:{"driver": "raw", "file": {"server.host": "10.66.5.92", "server.port": "7000", "tag": "", "driver": "sheepdog", "server.type": "inet", "vdi": "Alice"}}' /var/lib/libvirt/images/sheepdog.qcow2
Formatting '/var/lib/libvirt/images/sheepdog.qcow2', fmt=qcow2 size=5368709120 backing_file=json:{"driver": "raw",, "file": {"server.host": "10.66.5.92",, "server.port": "7000",, "tag": "",, "driver": "sheepdog",, "server.type": "inet",, "vdi": "Alice"}} encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16

# virsh pool-dumpxml default      
<pool type='dir'>
  <name>default</name>
  <uuid>38795621-2398-4e87-8602-31ae5907db67</uuid>
  <capacity unit='bytes'>0</capacity>
  <allocation unit='bytes'>0</allocation>
  <available unit='bytes'>0</available>
  <source>
  </source>
  <target>
    <path>/var/lib/libvirt/images</path>
  </target>
</pool>

# virsh pool-start default
error: Failed to start pool default
error: invalid argument: missing remote server specification in JSON backing volume definition

I think qemu-img should support sheepdog url format because libvirt in RHEL7.4 cannot parse the new sheepdog format.
What's your idea?
Comment 23 Ademar Reis 2017-06-22 01:08:00 UTC 
Han Han, sheepdog is not supported in RHEL and therefore is not in the whitelist.
Comment 24 Jeff Cody 2017-06-22 14:05:20 UTC 
(In reply to Ademar Reis from comment #23)
> Han Han, sheepdog is not supported in RHEL and therefore is not in the
> whitelist.

While not in the whitelist, qemu-img does not use the whitelist and can create / modify all image formats.  However, the use of 'file.filename' in the json is not supported, and it was a bug that it ever actually worked.

Since rbd and iscsi are supported in RHEV, there is a workaround so that existing images could be opened per this BZ, but that is not needed as far as RHEL/RHEV is concerned.

Upstream, sheepdog should probably get the same fix that rbd/iscsi received.
Comment 26 errata-xmlrpc 2017-08-02 04:41:00 UTC 
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://access.redhat.com/errata/RHSA-2017:2392
Comment 27 Longxiang Lyu 2018-07-22 11:56:25 UTC 
Hi, jeff, I recently used the format of 7.3 and found out:
#  qemu-img create test.qcow2 -b 'json:{"file.driver":"rbd","file.filename":"rbd:rbd/data.raw"}' -f qcow2
qemu-img: test.qcow2: Parameter 'pool' is missing
Could not open backing image to determine size.

is this format obsolete now? If so, I will modify current test cases of rbd.
Comment 28 Longxiang Lyu 2018-07-22 12:07:52 UTC 
# qemu-img --version
qemu-img version 2.6.0 (qemu-kvm-rhev-2.6.0-28.el7_3.14), Copyright (c) 2004-2008 Fabrice Bellard
# qemu-img create -f qcow2 -b 'json:{"file.driver":"rbd","file.filename":"rbd:rbd/test.raw"}' test.qcow2
Formatting 'test.qcow2', fmt=qcow2 size=21474836480 backing_file=json:{"file.driver":"rbd",,"file.filename":"rbd:rbd/test.raw"} encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16
# qemu-img info test.qcow2
image: test.qcow2
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 196K
cluster_size: 65536
backing file: json:{"file.driver":"rbd","file.filename":"rbd:rbd/test.raw"}
Format specific information:
    compat: 1.1
    lazy refcounts: false
    refcount bits: 16
    corrupt: false

upgrade to latest qemu-kvm
# qemu-img --version
qemu-img version 2.12.0 (qemu-kvm-rhev-2.12.0-7.el7)
# qemu-img check test.qcow2
qemu-img: Could not open 'test.qcow2': Could not open backing file: Parameter 'pool' is missing

I believe this issue is regressed.
Comment 29 Markus Armbruster 2018-07-23 09:13:26 UTC 
Support for "filename" was dropped upstream in commit bb9f762ff35.  It's been deprecated since commit 91589d9e5ca, v2.10.0.

We brought it back downstream in commit 91589d9e5ca.  However, bdrv_file_open() seems to ignore it anyways.  @parse_filename remains false.

Jeff, please have a closer look.  If this indeed a regression (seems likely), update BZ status accordingly.
Comment 32 Jeff Cody 2018-08-01 14:13:13 UTC 
(In reply to Markus Armbruster from comment #29)

> Jeff, please have a closer look.  If this indeed a regression (seems
> likely), update BZ status accordingly.

I think it is as well.  I've gone ahead and taken BZ #1610605 for this issue.
Note You need to log in before you can comment on or make changes to this bug.