Fix included in qemu-kvm-rhev-2.1.0-5.el7

Reproduce:
Version of components:
qemu-kvm-rhev-2.1.0-2.el7.x86_64

# qemu-img create -f qcow2 overlay -b ssh://xen/
qemu-img: overlay: Could not open 'ssh://xen/': Unknown protocol: Invalid argument

----
Verify:
Version of components:
qemu-kvm-rhev-2.1.0-5.el7.x86_64
---
# qemu-img create -f qcow2 overlay -b ssh://xen/
Segmentation fault (core dumped)

(gdb) bt
#0  0x00007ffff6cbe0a0 in _libssh2_session_set_blocking ()
   from /usr/lib64/libssh2.so.1
#1  0x00005555555e70c3 in ssh_file_open ()
#2  0x0000555555589d13 in bdrv_open ()
#3  0x000055555558a81c in bdrv_open_image ()
#4  0x00005555555899a0 in bdrv_open ()
#5  0x000055555558b27b in bdrv_img_create ()
#6  0x000055555557affd in img_create ()
#7  0x00007ffff441daf5 in __libc_start_main ()
   from /usr/lib64/libc.so.6
#8  0x000055555557a88d in _start ()


So based on above testing, when verify this bz, it is blocked by bz1147343. 


Hi Richard, 

  when QE verify this bz, it need a "ssh storage". But QE do not know which storage is suitable for this bz. Could you tell how to prepare a storage for this testing. Does it just like the xen storage when libvirt using it to do v2v.
Thanks very much.

Best Regards,
Jun Li

(In reply to Jun Li from comment #4)
>   when QE verify this bz, it need a "ssh storage". But QE do not know which
> storage is suitable for this bz. Could you tell how to prepare a storage for
> this testing. Does it just like the xen storage when libvirt using it to do
> v2v.

Here is one way to test this:

$ cd /tmp
$ virt-builder fedora-20
$ qemu-img create -f qcow2 overlay \
    -b 'json: { "file.driver":"ssh",
                "file.host":"localhost",
                "file.path":"/tmp/fedora-20.img",
                "file.host_key_check":"no" }'

Now you can run various (read-only) commands against /tmp/overlay, and it
will use the ssh driver to read the underlying file.

eg:

$ LIBGUESTFS_BACKEND=direct virt-inspector -a /tmp/overlay

Notes:

- libvirt doesn't support the ssh backend (bug 1134592)
- it will obviously be a lot slower than local file access
- you could also locate the disk image on a remote machine to test "real" ssh

(In reply to Richard W.M. Jones from comment #5)
> (In reply to Jun Li from comment #4)
> >   when QE verify this bz, it need a "ssh storage". But QE do not know which
> > storage is suitable for this bz. Could you tell how to prepare a storage for
> > this testing. Does it just like the xen storage when libvirt using it to do
> > v2v.
> 
> Here is one way to test this:
> 
> $ cd /tmp
> $ virt-builder fedora-20
> $ qemu-img create -f qcow2 overlay \
>     -b 'json: { "file.driver":"ssh",
>                 "file.host":"localhost",
>                 "file.path":"/tmp/fedora-20.img",
>                 "file.host_key_check":"no" }'
> 
> Now you can run various (read-only) commands against /tmp/overlay, and it
> will use the ssh driver to read the underlying file.
> 
> eg:
> 
> $ LIBGUESTFS_BACKEND=direct virt-inspector -a /tmp/overlay
> 
> Notes:
> 
> - libvirt doesn't support the ssh backend (bug 1134592)
> - it will obviously be a lot slower than local file access
> - you could also locate the disk image on a remote machine to test "real" ssh

Ok, thanks Richard.

Following is my steps:
1.
# iptables -F
2.
# setenforce 0
3.
# ssh-copy-id root@localhost
4.
# qemu-img create -f qcow2 overlay -b 'json: { "file.driver":"ssh","file.host":"localhost","file.path":"/home/RHEL-Server-7.0-64-virtio.qcow2","file.host_key_check":"no" }'

qemu-img: overlay: Could not open 'json: { "file.driver":"ssh","file.host":"localhost","file.path":"/home/RHEL-Server-7.0-64-virtio.qcow2","file.host_key_check":"no" }': failed to connect to ssh-agent: no auth sock variable (libssh2 error code: -39): Connection refused

As above, QE do not know why "libssh2" refused to connect. Could you help to check above issue. Thx.

Version of components:
# rpm -qa|grep libssh2
libssh2-1.4.3-8.el7.x86_64
qemu-kvm-rhev-2.1.0-5.el7.x86_64


Best Regards,
Jun Li

(In reply to Jun Li from comment #6)
> (In reply to Richard W.M. Jones from comment #5)
> > (In reply to Jun Li from comment #4)
> > >   when QE verify this bz, it need a "ssh storage". But QE do not know which
> > > storage is suitable for this bz. Could you tell how to prepare a storage for
> > > this testing. Does it just like the xen storage when libvirt using it to do
> > > v2v.
> > 
> > Here is one way to test this:
> > 
> > $ cd /tmp
> > $ virt-builder fedora-20
> > $ qemu-img create -f qcow2 overlay \
> >     -b 'json: { "file.driver":"ssh",
> >                 "file.host":"localhost",
> >                 "file.path":"/tmp/fedora-20.img",
> >                 "file.host_key_check":"no" }'
> > 
> > Now you can run various (read-only) commands against /tmp/overlay, and it
> > will use the ssh driver to read the underlying file.
> > 
> > eg:
> > 
> > $ LIBGUESTFS_BACKEND=direct virt-inspector -a /tmp/overlay
> > 
> > Notes:
> > 
> > - libvirt doesn't support the ssh backend (bug 1134592)
> > - it will obviously be a lot slower than local file access
> > - you could also locate the disk image on a remote machine to test "real" ssh
> 
> Ok, thanks Richard.
> 
> Following is my steps:
> 1.
> # iptables -F
> 2.
> # setenforce 0

Why are you doing this?  The ssh driver should work with a firewall
and SELinux both enabled.  If it doesn't that's a bug.

> 3.
> # ssh-copy-id root@localhost
> 4.
> # qemu-img create -f qcow2 overlay -b 'json: {
> "file.driver":"ssh","file.host":"localhost","file.path":"/home/RHEL-Server-7.
> 0-64-virtio.qcow2","file.host_key_check":"no" }'
> 
> qemu-img: overlay: Could not open 'json: {
> "file.driver":"ssh","file.host":"localhost","file.path":"/home/RHEL-Server-7.
> 0-64-virtio.qcow2","file.host_key_check":"no" }': failed to connect to
> ssh-agent: no auth sock variable (libssh2 error code: -39): Connection
> refused
> 
> As above, QE do not know why "libssh2" refused to connect. Could you help to
> check above issue. Thx.

I forgot to mention in comment 5 that it only works if ssh-agent is set up.
You'll have to ensure that ssh-agent is configured to allow you to log in
to localhost (or a remote machine) without a password.  Note that Kerberos
is not supported.

Verify:
Steps as followings:
1, 
# exec /usr/bin/ssh-agent $SHELL
2, 
# ssh-add
3, 
# qemu-img create -f qcow2 overlay -b 'json: { "file.driver":"ssh","file.host":"localhost","file.path":"/home/RHEL-Server-7.0-64-virtio.qcow2","file.host_key_check":"no" }'
4,
# qemu-img info /root/overlay
5,boot qemu-kvm using this image /root/overlay as system image(make sure readonly=on).
# /usr/libexec/qemu-kvm \
-m 2G -monitor stdio -vnc :1 \
-drive file=/root/overlay,if=none,id=img,readonly=on,snapshot=on \
-device virtio-blk-pci,drive=img,id=sys-img
6, check whether this guest can boot up as normal.

Results:
###after step3,
Formatting 'overlay', fmt=qcow2 size=21474836480 backing_file='json: { "file.driver":"ssh","file.host":"localhost","file.path":"/home/RHEL-Server-7.0-64-virtio.qcow2","file.host_key_check":"no" }' encryption=off cluster_size=65536 lazy_refcounts=off

###After step4,
image: /root/overlay
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 196K
cluster_size: 65536
backing file: json: { "file.driver":"ssh","file.host":"localhost","file.path":"/home/RHEL-Server-7.0-64-virtio.qcow2","file.host_key_check":"no" }
Format specific information:
    compat: 1.1
    lazy refcounts: false

###after step6,
guest boot up as normal, no error in dmesg.

Version of components:
qemu-kvm-rhev-2.1.0-5.el7.x86_64

Based on above testing, from kvm QE side, this bz has been verified.

Thanks Richard.

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