Bug 1226683

Summary: [virt-v2v] Backport upstream ssh driver to qemu-kvm
Product: Red Hat Enterprise Linux 7 Reporter: Richard W.M. Jones <rjones>
Component: qemu-kvmAssignee: Markus Armbruster <armbru>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.1CC: danken, huding, juzhang, knoel, rbalakri, virt-maint, xfu
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: qemu-kvm-1.5.3-91.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-11-19 05:03:16 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
differences between ssh.c in our 1.5.3 and ssh.c upstream none

Description Richard W.M. Jones 2015-05-31 18:31:21 UTC
Description of problem:

For background on this request, please see this virt-devel posting:
https://post-office.corp.redhat.com/mailman/private/virt-devel/2015-May/msg00338.html

We need to backport the upstream ssh driver to qemu-kvm, that
is to say, the file 'block/ssh.c' from qemu.git.

We will also need to change ./configure to add:
  --enable-libssh2
  --block-drv-ro-whitelist=... [add ssh to this list]

Note virt-v2v only wants read-only ssh.

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

qemu-kvm-1.5.3-89.el7,

Additional info:

Description from https://bugzilla.redhat.com/show_bug.cgi?id=1138359
- the original enablement request for qemu-kvm-rhev:

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).

Comment 2 Richard W.M. Jones 2015-06-01 14:02:37 UTC
Created attachment 1033361 [details]
differences between ssh.c in our 1.5.3 and ssh.c upstream

The differences don't look that large, although there is some
enhanced error checking which I think is there to avoid
segfaults.  However for now I'm going to test if the existing
ssh driver will just work with virt-v2v.

Comment 3 Richard W.M. Jones 2015-06-02 08:40:51 UTC
I scratch-built a qemu-kvm RPM which makes no changes to block/ssh.c
but does enable it in the ./configure line:
http://brewweb.devel.redhat.com/brew/taskinfo?taskID=9288785
(This also enables the curl driver and json: URL format, see
bug 1226684 and bug 1226697).

I then performed a virt-v2v transfer from a RHEL 5 Xen server.
This tests:

 - ssh driver
    * file.user
    * file.path
    * file.host
    * file.host_key_check
    * file.driver == ssh
 - copy-on-read
 - fstrim
 - qemu-img json: URLs (bug 1226697)

The virt-v2v operation was successful.

Comment 6 Miroslav Rezanina 2015-06-15 14:09:37 UTC
Fix included in qemu-kvm-1.5.3-91.el7

Comment 8 Richard W.M. Jones 2015-06-17 16:19:35 UTC
qemu-kvm-1.5.3-92.el7.x86_64
I've tested this now and it all seems to be working.

Comment 9 Jun Li 2015-06-30 17:37:37 UTC
Ref bz1138359 comment 8, verify this bz as followings:

Verify:
Steps as followings:
0,
# ssh-keygen
# ssh-copy-id root@localhost
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.2-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.2-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.2-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-1.5.3-94.el7.x86_64

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

Comment 12 errata-xmlrpc 2015-11-19 05:03:16 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/RHBA-2015-2213.html