Bug 1434651

Summary:	libvirt doesn't pass SSH_AUTH_SOCK through to qemu
Product:	Red Hat Enterprise Linux 7	Reporter:	kuwei <kuwei>
Component:	libvirt	Assignee:	Libvirt Maintainers <libvirt-maint>
Status:	CLOSED DUPLICATE	QA Contact:	yafu <yafu>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.4	CC:	dyuan, juzhou, mxie, mzhan, pkrempa, ptoscano, rbalakri, rjones, tzheng, xiaodwan, xuzhang, yafu, zpeng
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:	V2V
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-03-23 07:47:24 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:
Bug Depends On:
Bug Blocks:	910269

Description kuwei@redhat.com 2017-03-22 02:21:17 UTC

Description of problem:
Virt-v2v convert a guest from Xen server should not report ssh-agent error when ssh-agent has set up 

Version-Release number of selected component (if applicable):
virt-v2v-1.36.2-2.el7.x86_64
libguestfs-1.36.2-2.el7.x86_64
libvirt-3.1.0-2.el7.x86_64
qemu-kvm-rhev-2.8.0-6.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1:First to set up ssh-agent,and can be ssh to xen server straight into the shell
2:Convert a guest from xen server by virt-v2v
#virt-v2v -ic xen+ssh://root.3.21 xen-hvm-rhel7.2-x86_64  -o rhev -os 10.73.131.93:/home/nfs_export -of raw
[   0.0] Opening the source -i libvirt -ic xen+ssh://root.3.21 xen-hvm-rhel7.2-x86_64
[   0.4] Creating an overlay to protect the source from being modified
[   1.1] Initializing the target -o rhv -os 10.73.131.93:/home/nfs_export
[   1.4] Opening the overlay
virt-v2v: error: libguestfs error: could not create appliance through 
libvirt.

Try running qemu directly without libvirt using this environment variable:
export LIBGUESTFS_BACKEND=direct

Original error from libvirt: internal error: qemu unexpectedly closed the 
monitor: 2017-03-21T12:42:27.780311Z qemu-kvm: -drive 
file=/var/tmp/v2vovl3d97ce.qcow2,format=qcow2,if=none,id=drive-scsi0-0-0-0,cache=unsafe,discard=unmap: 
could not open disk image /var/tmp/v2vovl3d97ce.qcow2: Could not open 
backing file: failed to connect to ssh-agent: no auth sock variable 
(libssh2 error code: -39) [code=1 int1=-1]

If reporting bugs, run virt-v2v with debugging enabled and include the 
complete output:

  virt-v2v -v -x [...]

3:Then running the below command:
#export LIBGUESTFS_BACKEND=direct

4:After steps 3,below conversion will be successfully.
# virt-v2v -ic xen+ssh://root.3.21 xen-hvm-rhel7.2-x86_64  -o rhev -os 10.73.131.93:/home/nfs_export -of raw



Actual results:
as above

Expected results:
virt-v2v should be ran successfully.

Additional info:

Comment 2 Richard W.M. Jones 2017-03-22 15:15:08 UTC

Finally I'm able to reproduce this bug myself.

Comment 3 Richard W.M. Jones 2017-03-22 15:35:50 UTC

This is a bug in libvirt.

When a 'ssh' drive is requested (which also applies if the drive
is a qcow2 file with an ssh backing file as in this case), libvirt
must pass the SSH_AUTH_SOCK environment variable through to qemu.
That is fundamentally how the libssh2 driver in qemu works.

An example:

You'll first need to set up passwordless (ssh-agent) access to
a remote server (192.168.0.87 in the example below), and create a
disk image of some kind on that remote server (/tmp/disk.img in
the example below).  SSH_AUTH_SOCK should be set in your local
environment.

$ qemu-img create -f qcow2 test1.qcow2 \
    -b 'json: { "file.user": "root", 
                "file.driver": "ssh", 
                "file.path": "/tmp/disk.img", 
                "file.host": "192.168.0.87", 
                "file.host_key_check": "no" }'

Now attach test1.qcow2 to a guest and start the guest in libvirt.

You should see the error:

test1.qcow2: Could not open backing file: failed to connect to
ssh-agent: no auth sock variable  (libssh2 error code: -39)

This error comes from qemu and happens because SSH_AUTH_SOCK is
not set in qemu's environment (it should have been passed through
from your environment).  Note that I'm doing all of this testing
as non-root and it can depend on whether libvirtd is running already
or not (see also long-standing libvirt bug 856619).

Comment 5 Peter Krempa 2017-03-23 07:47:24 UTC

This will need to become a parameter in the XML. There's no way for libvirt to pass through the client environment to libvirt as connections can be remote. This should be addressed when adding support for the ssh backend.

*** This bug has been marked as a duplicate of bug 1140166 ***