Bug 1226697

Hi Richard,

Is there any specific use case this is needed for? (I don't see it mentioned in the mail you referenced.) Backporting it would probably not hurt too bad, but unless there is a specific need I would rather refrain from it.

Max

This seems pretty simple.  I had to backport only these upstream commits:

commit 9c5268127722087eec88c4c41f3363855bb1234b
Author: Max Reitz <mreitz>
Date:   Thu May 8 20:12:39 2014 +0200

    qdict: Add qdict_join()
    
    This function joins two QDicts by absorbing one into the other.
    
    Signed-off-by: Max Reitz <mreitz>
    Reviewed-by: Benoit Canet <benoit>
    Reviewed-by: Eric Blake <eblake>
    Signed-off-by: Kevin Wolf <kwolf>

commit 4993f7ea7e63f18f18880289d6be8a9ab1591409
Author: Max Reitz <mreitz>
Date:   Thu May 8 20:12:41 2014 +0200

    block: Allow JSON filenames
    
    If the filename given to bdrv_open() is prefixed with "json:", parse the
    rest as a JSON object and merge the result into the options QDict. If
    there are conflicts, the options QDict takes precedence.
    
    Signed-off-by: Max Reitz <mreitz>
    Reviewed-by: Eric Blake <eblake>
    Signed-off-by: Kevin Wolf <kwolf>

I didn't bother about 5e5c4f63f4a7f48f571ea5671bf8452fe9655cdd
since it's just a code refactoring and it references a function
(bdrv_fill_options) that does not exist in this version of qemu.

(In reply to Max Reitz from comment #2)
> Hi Richard,
> 
> Is there any specific use case this is needed for? (I don't see it mentioned
> in the mail you referenced.) Backporting it would probably not hurt too bad,
> but unless there is a specific need I would rather refrain from it.

Yes, virt-v2v uses json: filenames throughout to avoid the difficult
escaping problems with passing complex parameters to qemu-img.  A fairly
complex example involving up to 6 parameters is:
https://github.com/libguestfs/libguestfs/blob/master/v2v/input_libvirt_vcenter_https.ml#L249

Very well then, thank you Richard. I'll backport it.

Max

Scratch build containing the backported patches (also
patches for bug 1226684):
http://brewweb.devel.redhat.com/brew/taskinfo?taskID=9288421

Improved scratch build, this time remembering to enable the
drivers in ./configure:
http://brewweb.devel.redhat.com/brew/taskinfo?taskID=9288785

Please see the successful results of my testing here:
https://bugzilla.redhat.com/show_bug.cgi?id=1226684#c6
https://bugzilla.redhat.com/show_bug.cgi?id=1226683#c3

http://post-office.corp.redhat.com/archives/rhvirt-patches/2015-June/thread.html#00134

Fix included in qemu-kvm-1.5.3-92.el7

qemu-kvm-1.5.3-92.el7.x86_64
I've tested this now and it all seems to be working.

Test this bug on qemu-kvm-1.5.3-97.el7.x86_64.

1. Create image with backing file specified by json which file.driver is https, then check the image's information.
# qemu-img create -f qcow2 /home/img -b 'json: {"file.driver":"https","file.url":"https://10.66.9.236/rhel7.2-64.qcow2","file.sslverify":"off", "file.readahead":"64k","file.timeout":2000}'
Formatting '/home/img', fmt=qcow2 size=21474836480 backing_file='json: {"file.driver":"https","file.url":"https://10.66.9.236/rhel7.2-64.qcow2","file.sslverify":"off", "file.readahead":"64k","file.timeout":2000}' encryption=off cluster_size=65536 lazy_refcounts=off

# qemu-img info /home/img 
image: /home/img
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 196K
cluster_size: 65536
backing file: json: {"file.driver":"https","file.url":"https://10.66.9.236/rhel7.2-64.qcow2","file.sslverify":"off", "file.readahead":"64k","file.timeout":2000}
Format specific information:
    compat: 1.1
    lazy refcounts: false

2. Create image with backing file specified by json which file.driver is ssh, then check the image's information.

# qemu-img create -f qcow2 overlay -b 'json: {"file.driver":"ssh","file.host":"10.66.11.16","file.path":"/home/rhel7.2-64.qcow2","file.host_key_check":"no" }'
Formatting 'overlay', fmt=qcow2 size=21474836480 backing_file='json: {"file.driver":"ssh","file.host":"10.66.11.16","file.path":"/home/rhel7.2-64.qcow2","file.host_key_check":"no" }' encryption=off cluster_size=65536 lazy_refcounts=off 

# qemu-img info overlay 
image: overlay
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 196K
cluster_size: 65536
backing file: json: {"file.driver":"ssh","file.host":"10.66.11.16","file.path":"/home/rhel7.2-64.qcow2","file.host_key_check":"no" }
Format specific information:
    compat: 1.1
    lazy refcounts: false


Just one question for file.driver is http/https.
When file.driver is http, qemu-img not complain url with https.
# qemu-img create -f qcow2 /home/img -b 'json: {"file.driver":"http","file.url":"https://10.66.9.236/rhel7.2-64.qcow2","file.sslverify":"off", "file.readahead":"64k","file.timeout":2000}'
Formatting '/home/img', fmt=qcow2 size=21474836480 backing_file='json: {"file.driver":"http","file.url":"https://10.66.9.236/rhel7.2-64.qcow2","file.sslverify":"off", "file.readahead":"64k","file.timeout":2000}' encryption=off cluster_size=65536 lazy_refcounts=off 

or file.driver is https, url is http.
# qemu-img create -f qcow2 /home/img -b 'json: {"file.driver":"https","file.url":"http://10.66.9.236/rhel7.2-64.qcow2","file.sslverify":"off", "file.readahead":"64k","file.timeout":2000}'
Formatting '/home/img', fmt=qcow2 size=21474836480 backing_file='json: {"file.driver":"https","file.url":"http://10.66.9.236/rhel7.2-64.qcow2","file.sslverify":"off", "file.readahead":"64k","file.timeout":2000}' encryption=off cluster_size=65536 lazy_refcounts=off 

Richard, Could you please have a look at above test, is this expected?

Thanks,
Mazhang.

That's (kind of) a "back door", since qemu uses file.driver
to select the curl driver, but then doesn't check that the URL
scheme from file.url matches the scheme from file.driver.
I wouldn't worry about it.

(In reply to Richard W.M. Jones from comment #14)
> That's (kind of) a "back door", since qemu uses file.driver
> to select the curl driver, but then doesn't check that the URL
> scheme from file.url matches the scheme from file.driver.
> I wouldn't worry about it.

Thanks, let's move this bug to verified, if any problem please let me know.

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/RHBA-2015-2213.html