Bug 1138359 - RFE: Enable ssh driver in qemu-kvm-rhev
Summary: RFE: Enable ssh driver in qemu-kvm-rhev
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Markus Armbruster
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 1132569 1147343
Blocks: 1138504
TreeView+ depends on / blocked
 
Reported: 2014-09-04 15:10 UTC by Richard W.M. Jones
Modified: 2015-03-05 09:54 UTC (History)
16 users (show)

Fixed In Version: qemu-kvm-rhev-2.1.0-5.el7
Doc Type: Enhancement
Doc Text:
Clone Of: 1132569
Environment:
Last Closed: 2015-03-05 09:54:31 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0624 normal SHIPPED_LIVE Important: qemu-kvm-rhev security, bug fix, and enhancement update 2015-03-05 14:37:36 UTC

Description Richard W.M. Jones 2014-09-04 15:10:43 UTC
Description of problem:

The rewritten virt-v2v which we'll be rolling out to a limited
audience in RHEL 7.1 can convert from RHEL 5 Xen servers to
KVM and/or RHEV.  When it converts from Xen, it has to access
the source disks from the Xen host over ssh.

The previous version of virt-v2v (up to RHEL 6) had an SSH
client built in, so it would download the whole disk to a
temporary directory on the conversion server.  This was slow,
inefficient and required a lot of storage on the conversion
server (disk images are BIG, 100s GB / TBs not unusual).

The new version is smarter about this.  It creates a qcow2
overlay with the source as a backing file, ie. something
like this:

  qemu-img create -f qcow2 overlay -b ssh://xen/...

It then opens the disk image using libguestfs (ie. qemu).

So therefore this means we'd like the ssh driver enabled in
qemu-kvm-rhev (readonly).

Version-Release number of selected component (if applicable):

qemu-kvm-rhev in RHEL 7.1

Additional notes:

This is a companion feature to ESX support (bug 1132569).  Of the
two, this bug (ssh) is a lot less critical, but if it was rejected
for RHEL 7.1 then we'd have to patch virt-v2v to remove the "offer"
of Xen support, in the documentation etc.

Comment 2 Miroslav Rezanina 2014-09-24 09:20:34 UTC
Fix included in qemu-kvm-rhev-2.1.0-5.el7

Comment 4 Jun Li 2014-09-29 04:55:30 UTC
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

Comment 5 Richard W.M. Jones 2014-09-29 07:39:57 UTC
(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

Comment 6 Jun Li 2014-09-30 04:11:00 UTC
(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

Comment 7 Richard W.M. Jones 2014-09-30 07:37:45 UTC
(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.

Comment 8 Jun Li 2014-09-30 09:14:34 UTC
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.

Comment 11 errata-xmlrpc 2015-03-05 09:54:31 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://rhn.redhat.com/errata/RHSA-2015-0624.html


Note You need to log in before you can comment on or make changes to this bug.