Bug 1379240

Maybe the expected result should depend on libvirt's version.
In case some users libvirt packget maybe is old, It should continue to report error and give corresponding workaround for old libvirt versions.

(In reply to xiaodwan from comment #1)
> Maybe the expected result should depend on libvirt's version.
> In case some users libvirt packget maybe is old, It should continue to
> report error and give corresponding workaround for old libvirt versions.

Yes, this is the approach that was implemented one month ago.

https://github.com/libguestfs/libguestfs/commit/ecbf09385033ba0acf14e914927ec81ad20a5308
for libguestfs >= 1.35.2

https://github.com/libguestfs/libguestfs/commit/e9d27e848d17ef1c4705e388b17196aa994f12d6
for libguestfs >= 1.34.1

This most probably will come in RHEL 7.4 with the planned rebase, aka bug 1359086.

I can reproduce the error like comment 5  with below builds:
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

(In reply to kuwei from comment #8)
> I can reproduce the error like comment 5  with below builds:
> 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

What about when using qemu-kvm (non-rhev) from RHEL?

(In reply to kuwei from comment #8)
> I can reproduce the error like comment 5  with below builds:
> 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

The error in comment 5 is:

Could not open backing file: failed to connect to ssh-agent: no auth sock 
variable (libssh2 error code: -39) [code=1 int1=-1]

This happens because you didn't set up ssh-agent before
running the command:

http://libguestfs.org/virt-v2v.1.html#xen:-set-up-ssh-agent-access-to-xen-host

It's not related to this bug.

No,i am sure have set up ssh-agent.and if ssh-agent not setted,it will shows:
# 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
virt-v2v: error: ssh-agent authentication has not been set up 
($SSH_AUTH_SOCK is not set).  Please read "INPUT FROM RHEL 5 XEN" in the 
virt-v2v(1) man page.

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

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


When i using qemu-kvm:
qemu-kvm-1.5.3-133.el7.x86_64
virt-v2v-1.36.2-2.el7.x86_64

steps:
1:First to Set up ssh-agent,and can be ssh to xen server straight into the shell .
2:#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:When i run the 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

So,from comment 10, it is not because we didn't set up ssh-agent .

Unfortunately we need to disable libvirt for xen+ssh conversions.
See my reasoning and patch here:
https://www.redhat.com/archives/libguestfs/2017-March/msg00249.html

Pino:

This commit is required for RHEL 7.4:

https://github.com/libguestfs/libguestfs/commit/7cf85ace19231085e514b980bd13b7976e21a242

Because of a libvirt bug, the xen+ssh input source had to be disabled again.

Since the VMware was actually enabled, I've just split the xen+ssh part into bug 1435162, changing this to reflect it is for VMware only.

Verify the bug with below builds:
virt-v2v-1.36.2-3.el7.x86_64
libguestfs-1.36.2-3.el7.x86_64

Steps:
Convert a guest from ESX server to libvirt.

# virt-v2v -ic vpx://root.75.182/data/10.73.3.19/?no_verify=1 esx5.5-rhel7.2-x86_64  --password-file /tmp/passwd -on tees1
[   0.0] Opening the source -i libvirt -ic vpx://root.75.182/data/10.73.3.19/?no_verify=1 esx5.5-rhel7.2-x86_64
[   1.3] Creating an overlay to protect the source from being modified
[   2.0] Initializing the target -o libvirt -os default
[   2.0] Opening the overlay
[  56.3] Inspecting the overlay
[ 212.2] Checking for sufficient free disk space in the guest
[ 212.2] Estimating space required on target for each disk
[ 212.2] Converting Red Hat Enterprise Linux Server 7.2 (Maipo) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[1782.7] Mapping filesystem data to avoid copying unused and blank areas
[1803.5] Closing the overlay
[1803.9] Checking if the guest needs BIOS or UEFI to boot
[1803.9] Assigning disks to buses
[1803.9] Copying disk 1/1 to /var/lib/libvirt/images/tees1-sda (raw)
    (100.00/100%)
[1990.3] Creating output metadata
Pool default refreshed

Domain tees1 defined from /tmp/v2vlibvirt440248.xml

[1991.0] Finishing off

Result:The conversion successfully with no export error any more



From comment 14,the bug only for Vmware ,so move the bug to VERIFIED

Set that this bug blocks bug 1370055 -- mostly for tracking purposes.

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://access.redhat.com/errata/RHBA-2017:2023