RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1434651 - libvirt doesn't pass SSH_AUTH_SOCK through to qemu
Summary: libvirt doesn't pass SSH_AUTH_SOCK through to qemu
Keywords:
Status: CLOSED DUPLICATE of bug 1140166
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.4
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Libvirt Maintainers
QA Contact: yafu
URL:
Whiteboard: V2V
Depends On:
Blocks: TRACKER-bugs-affecting-libguestfs
TreeView+ depends on / blocked
 
Reported: 2017-03-22 02:21 UTC by kuwei@redhat.com
Modified: 2017-03-23 10:08 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-03-23 07:47:24 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

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 ***
Note You need to log in before you can comment on or make changes to this bug.