Description of problem: Creating an overlay image with a backing file that resides on a remote storage fails with: "qemu-img: overlay1: Cannot use relative backing file...Could not open backing image to determine size.". I.e. 1. Invoke on a web server: $ qemu-img create -f raw backing.raw 10M Formatting 'backing.raw', fmt=raw size=10485760 $ qemu-img create -f qcow2 -o backing_file=backing.raw,backing_fmt=raw test.qcow2 Formatting 'test.qcow2', fmt=qcow2 size=10485760 backing_file='backing.raw' backing_fmt='raw' encryption=off cluster_size=65536 2. Create the overlay: $ qemu-img create -f qcow2 -o backing_file=http://tick/tmp/test.qcow2,backing_fmt=qcow2 overlay1 qemu-img: overlay1: Cannot use relative backing file names for 'json:{"url": "http://tick/tmp/test.qcow2", "driver": "http"}' Could not open backing image to determine size.
Jeffrey, isn't this the same issue as https://bugzilla.redhat.com/show_bug.cgi?id=1397870#c30
Hi, Daniel Could you update what is your host kernel version and qemu-kvm-rhev (or qemu-kvm) version? And which architecture? Thanks, Qunfang
(In reply to Qunfang Zhang from comment #3) > Hi, Daniel > > Could you update what is your host kernel version and qemu-kvm-rhev (or > qemu-kvm) version? And which architecture? > > Thanks, > Qunfang Checked on fc26: qemu-kvm-2.10.0-4.fc26.x86_64 kernel-core-4.13.9-200.fc26.x86_64
So the expected behaviour in the example would be that qemu combines the URL 'http://tick/tmp/test.qcow2' and the relative backing file name 'backing.raw' into a new URL 'http://tick/tmp/backing.raw' and access that, right? I believe implementing this becomes possible with some of Max's pending patches, so I'm reassigning the bug. In any case, this is not a bug, but an RFE, so I'm also moving it to 7.6.
(In reply to Kevin Wolf from comment #6) > So the expected behaviour in the example would be that qemu combines the URL > 'http://tick/tmp/test.qcow2' and the relative backing file name 'backing.raw' > into a new URL 'http://tick/tmp/backing.raw' and access that, right? Right, same way gluster: urls are handled now.
This is blocking our ability to provide smart state analysis for CFME and single file backups in API for backup vendors in RHV. I would want to see it in RHEL 7.5, if possible.
Retest this issue in latest 8.1.0-av, there is no the issue any more. So will close this bug. Correct me if there is anything wrong, please. Tested with: qemu-kvm-4.0.0-4.module+el8.1.0+3356+cda7f1ee kernel-4.18.0-100.el8 Steps: 1. Create images in http server: # pwd /var/www/html/tmp # qemu-img create -f raw backing.img 20M Formatting 'backing.img', fmt=raw size=20971520 # qemu-img create -f qcow2 -o backing_file=backing.img,backing_fmt=raw overlay.qcow2 Formatting 'overlay.qcow2', fmt=qcow2 size=20971520 backing_file=backing.img backing_fmt=raw cluster_size=65536 lazy_refcounts=off refcount_bits=16 2. Create overlay in local # qemu-img --version qemu-img version 4.0.0 (qemu-kvm-4.0.0-4.module+el8.1.0+3356+cda7f1ee) Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers # qemu-img create -f qcow2 -o backing_file=http://$http_server_ip/tmp/overlay.qcow2,backing_fmt=qcow2 sn.qcow2 Formatting 'sn.qcow2', fmt=qcow2 size=20971520 backing_file=http://$http_server_ip/tmp/overlay.qcow2 backing_fmt=qcow2 cluster_size=65536 lazy_refcounts=off refcount_bits=16 # qemu-img info sn.qcow2 image: sn.qcow2 file format: qcow2 virtual size: 20M (20971520 bytes) disk size: 196K cluster_size: 65536 backing file: http://$http_server_ip/tmp/overlay.qcow2 backing file format: qcow2 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false