Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Descriptionkuwei@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 2Richard W.M. Jones
2017-03-22 15:15:08 UTC
Finally I'm able to reproduce this bug myself.
Comment 3Richard 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).
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 ***