This is already implemented upstream, so it would be a backport:

https://github.com/libguestfs/libguestfs/commit/4ad6e184a96a40278f7de9db07517903841f0fdd

I had a go at backporting this and it's pretty rough.  It requires the whole
nbdkit series that was implemented here:

https://www.redhat.com/archives/libguestfs/2019-July/msg00200.html

(You can see that the patch we need is in fact the very last commit
in that sequence, but it really does depend on all the others).

I myself and quite happy with that series, although it was a bit
controversial at the time.  But it's a large upstream change and my
feeling here is it would be better to wait for a rebase.

Let's see what Pino thinks.

(In reply to Richard W.M. Jones from comment #2)
> I had a go at backporting this and it's pretty rough.  It requires the whole
> nbdkit series that was implemented here:
> 
> https://www.redhat.com/archives/libguestfs/2019-July/msg00200.html
> 
> (You can see that the patch we need is in fact the very last commit
> in that sequence, but it really does depend on all the others).
> 
> I myself and quite happy with that series, although it was a bit
> controversial at the time.  But it's a large upstream change and my
> feeling here is it would be better to wait for a rebase.

From my POV, this patch series changes too many things, and TBH it was pushed upstream with almost no review [*].
Even assuming it was done now, there is not much time left before the next AV release (8.2.0) to fullt test it, and ensure there are no regressions. The series touches too many things inside virt-v2v.

[*] partially my fault for not having reviewed it, however that's what happens when certain LPs (hello IMS!) ask your team to do the work of 5 people at once

Even assuming it was easy and doable, there is a detail that is being forgotten:

(In reply to Fabien Dupont from comment #0)
> For example:
> $ virt-v2v -i vmx -it ssh -ip /tmp/passwd \
>     'ssh://root@esxi/vmfs/volumes/datastore1/Windows/Windows.vmx' -o null

Both the copying of the vmx file from the ESXi server and the check for the existance (always on the ESXi datastore) are done spawning ssh(1) manually, the password file specified with -ip does not apply to them, and thus the SSH password is still asked (twice).
A possible solution is to use libssh to do these connections, and I have a possible draft for it. Again, see [*] above for the "why it is not done already.

---

Bottom like: let's test this upstream _properly_, and have it picked in future rebases of virt-v2v.
(Explicitly said: NACK from me.)

I'm fine with waiting for rebase.
It would be a great enhancement, but we have a working process in IMS. No need to rush.

PS: I plead guilty on IMS behalf.

Note: after the rebase of virt-v2v to 1.42.0:
- Xen should be fully covered by -ip
- vmx via ssh transport still asks for the password twice, for the reasons mentioned in the second half of comment 3

I'm ACKing this because I think it should already have been fixed
when we rebased to virt-v2v 1.42.

mxie: Could you QA ack this please?

Sorry for misunderstanding the bug,retest the bug with builds:
virt-v2v-1.42.0-12.module+el8.5.0+10976+d40a93e9.x86_64

Steps:
Not set ssh-agent

Scenario 1:Convert guest from xen host:
#  virt-v2v -ic xen+ssh://root.224.33 xen-hvm-rhel7.9-x86_64 -of raw -ip /home/rhvpasswd
virt-v2v: error: ssh-agent authentication has not been set up 
($SSH_AUTH_SOCK is not set).  This is required by qemu to do passwordless 
ssh access.  See the virt-v2v(1) man page for more information.

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

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

Result 1: virt-v2v still cannot use password to convert guests from xen host

Scenario 2: convert a guest from ESXI7.0 server
#  virt-v2v -i vmx  -it ssh ssh://root.199.217/vmfs/volumes/esx7.0-matrix/esx7.0-win2019-x86_64/esx7.0-win2019-x86_64.vmx  -o rhv-upload -oc https://hp-dl360eg8-03.lab.eng.pek2.redhat.com/ovirt-engine/api -os iscsi_data -op /home/rhvpasswd -oo rhv-cafile=/home/ca.pem -of raw -b ovirtmgmt -oa preallocated -oo rhv-cluster=ISCSI -oo rhv-verifypeer=false -ip /home/rhvpasswd 
[   0.5] Opening the source -i vmx ssh://root.199.217/vmfs/volumes/esx7.0-matrix/esx7.0-win2019-x86_64/esx7.0-win2019-x86_64.vmx
Password: 
Password: 
[  10.7] Creating an overlay to protect the source from being modified
nbdkit: ssh[1]: error: all possible authentication methods failed
qemu-img: /var/tmp/v2vovl5d4459.qcow2: Requested export not available
Could not open backing image.
virt-v2v: error: qemu-img command failed, see earlier errors

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

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

Result 2:virt-v2v cannot use password to convert guests from ESXI7.0

Scenario 3: convert guest from ESXI6.7 server
# virt-v2v -i vmx -it ssh ssh://root.75.219/vmfs/volumes/esx6.7-matrix/esx6.7-win10-x86_64-efi/esx6.7-win10-x86_64-efi.vmx -ip /home/esxpw 
[   0.0] Opening the source -i vmx ssh://root.75.219/vmfs/volumes/esx6.7-matrix/esx6.7-win10-x86_64-efi/esx6.7-win10-x86_64-efi.vmx
Password: 
Password: 
[  17.0] Creating an overlay to protect the source from being modified
[  17.2] Opening the overlay
[  25.9] Inspecting the overlay
[...]
[ 759.7] Finishing off

Result 3:virt-v2v can use password to convert guests from ESXI6.7

Also test other ESXI server,result as below:

Result:
XEN       FAIL
ESXI7.0   FAIL
ESXI6.7   PASS
ESXI6.5   PASS
ESXI6.0   FAIL
ESXI5.5   FAIL


Hi,Rjones
Pls help to check the result.
Thanks!

This has obviously not been fixed/implemented properly.  I'm
putting it back on the backlog and moving to RHEL 9 (as we
want to do as little as possible for RHEL 8 and certainly not
add features).

Clearing ITR, DTM, ITM - more completeness.

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

This bug was closed in error by a process that we do not control.
Reopening.

Given that this BZ has been moved to RHEL9, and we've recently taken multiple stabs at this in bug 1854275, I'm closing this one as a duplicate of bug 1854275. Summary of the status (all documented in the virt-v2v manual):

- xen+ssh: if the server enables PasswordAuthentication, then "-ip" works.
- vmx+ssh: even if the server enables PasswordAuthentication and "-ip" is passed on the command line, the vmx input module with ssh transport still asks twice for the password, because the "scp" and "ssh" invocations we have in there cannot be convinced to take the password otherwise. This could only be mitigated by an internal SFTP client, which is too much work (= too little capacity) for the requested feature. Use ssh-agent please. The manual is also clear about this (now).

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