This is probably caused by the new "cookie header" functionality.

Xinyu - please could you attach the virt-v2v debugging log.  Run the same
virt-v2v command with the extra -v -x parameters and attach the full
log output to the bug.

Created attachment 1782669 [details]
v2v execution log

I did the easy fix:
https://github.com/libguestfs/virt-v2v/commit/8abc07a8589a48c79cc65159640e0d8ab3c9b261

It forces the user to use -ip when importing from VMware over HTTPS.

Test the bug with below builds:
virt-v2v-1.45.97-4.el9.x86_64
libguestfs-1.46.1-2.el9.x86_64
guestfs-tools-1.46.1-6.el9.x86_64


Steps:
1.Check the man page of virt-v2v-input-vmware about -ip password for vCenter
# man virt-v2v-input-vmware 
vCenter: URI
       The libvirt URI of a vCenter server looks something like this:

        vpx://user@server/Datacenter/esxi
           ....
           The user's password must be supplied in a local file using the separate -ip parameter.
......
vCenter: Supplying the password
       The vCenter password (usually for the root account, or the account specified by "user@" in the vpx URL)
       has to be written to a local file, and the name of that file specified on the virt-v2v command line
       using -ip passwordfile.
vCenter: Importing a guest
       To import a particular guest from vCenter Server, do:

        $ virt-v2v -ic 'vpx://root.com/Datacenter/esxi?no_verify=1' \
          -ip passwordfile \
          "Windows 2003" \
          -o local -os /var/tmp
       ....
       Note that you may be asked for the vCenter password twice.  This happens once because libvirt needs it,
       and a second time because virt-v2v itself connects directly to the server.  Use -ip filename to supply
       a password via a file.


2.Convert a guest from VMwarev(Center) without vddk and don't set any option about vmware password in v2v command line. 

#  virt-v2v -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-rhel8.5-x86_64 -o local -os /home
[   0.0] Setting up the source: -i libvirt -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 esx7.0-rhel8.5-x86_64
virt-v2v: error: -i libvirt: expecting -ip passwordfile parameter for 
vCenter connection

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

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


3.Convert a guest from VMware(vCenter) with vddk and don't set any option about vmware password in v2v command line. Then input the correct password for password prompt

# virt-v2v -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 -it vddk -io vddk-libdir=/home/vddk7.0.2 -io  vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78  -o rhv-upload -of qcow2 -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api  -op /home/rhvpasswd  -os nfs_data -b ovirtmgmt  esx7.0-rhel8.5-x86_64 
[   0.0] Setting up the source: -i libvirt -ic vpx://root.198.169/data/10.73.199.217/?no_verify=1 -it vddk esx7.0-rhel8.5-x86_64
Enter root's password for 10.73.198.169: 
password: 
[  14.8] Opening the source
[  20.2] Inspecting the source
[  35.5] Checking for sufficient free disk space in the guest
[  35.5] Converting Red Hat Enterprise Linux 8.5 (Ootpa) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[ 170.0] Mapping filesystem data to avoid copying unused and blank areas
[ 170.9] Closing the overlay
[ 171.2] Assigning disks to buses
[ 171.2] Checking if the guest needs BIOS or UEFI to boot
[ 171.2] Setting up the destination: -o rhv-upload -oc https://dell-per740-22.lab.eng.pek2.redhat.com/ovirt-engine/api -os nfs_data
[ 191.9] Copying disk 1/1
█ 100% [****************************************]
[ 948.3] Creating output metadata
[1011.5] Finishing off


4. Convert a guest from VMware(ESXi host) with vddk and don't set any option about vmware password in v2v command line. Then input the correct password for password prompt
# virt-v2v  -ic esx://root.75.219/?no_verify=1 -it vddk -io vddk-libdir=/home/vddk6.7 -io vddk-thumbprint=FE:D7:15:39:47:F8:E8:5A:48:C8:CF:95:20:D4:16:F3:99:AF:58:55 esx6.7-rhel8.5-x86_64
[   0.0] Setting up the source: -i libvirt -ic esx://root.75.219/?no_verify=1 -it vddk esx6.7-rhel8.5-x86_64
Enter root's password for 10.73.75.219: 
password: 
[   7.0] Opening the source
[  12.1] Inspecting the source
[  25.8] Checking for sufficient free disk space in the guest
[  25.8] Converting Red Hat Enterprise Linux 8.5 (Ootpa) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[ 154.3] Mapping filesystem data to avoid copying unused and blank areas
[ 155.3] Closing the overlay
[ 155.6] Assigning disks to buses
[ 155.6] Checking if the guest needs BIOS or UEFI to boot
[ 155.6] Setting up the destination: -o libvirt
[ 157.6] Copying disk 1/1
█ 100% [****************************************]
[ 333.1] Creating output metadata
[ 333.2] Finishing off



Hi Richard,

  (1)Please check the result of step1, I think the sentences 'Note that you may be asked for the vCenter password twice.  This happens once because libvirt needs it,and a second time because virt-v2v itself connects directly to the server.  Use -ip filename to supply a password via a file.' should be deleted from 'vCenter: Importing a guest'  part

  (2)Please check the result of step3, '-ip passwordfile' is not required option when convert guest from VMware  vCenter with vddk, is it expected?

(In reply to mxie from comment #9)
>   (1)Please check the result of step1, I think the sentences 'Note that you
> may be asked for the vCenter password twice.  This happens once because
> libvirt needs it,and a second time because virt-v2v itself connects directly
> to the server.  Use -ip filename to supply a password via a file.' should be
> deleted from 'vCenter: Importing a guest'  part

I'll tidy up the text a bit in a follow-up commit.

>   (2)Please check the result of step3, '-ip passwordfile' is not required
> option when convert guest from VMware  vCenter with vddk, is it expected?

This bug is only about VMware imports over HTTPS and only affects those, not
VDDK.  For VDDK, -ip is not required because nbdkit is able to ask for it.
(nbdkit cannot ask for the curl password up front because of complicated
reasons to do with having to reauthenticate periodically from a script).
So this isn't a bug.

Updated in:
https://github.com/libguestfs/virt-v2v/commit/66b0a40406effd1c63c0ab47a271aa5240a77638

Verify the bug with below builds
virt-v2v-1.45.98-1.el9.x86_64
libguestfs-1.46.1-2.el9.x86_64
guestfs-tools-1.46.1-6.el9.x86_64
libvirt-libs-8.0.0-4.el9.x86_64
qemu-img-6.2.0-7.el9.x86_64
virtio-win-1.9.19-5.el9_b.noarch

Steps:
1.Check the man page of virt-v2v-input-vmware, the wrong sentences which are mentioned in comment9 have been deleted
# man virt-v2v-input-vmware 
vCenter: URI
.....
        vpx://user@server/Datacenter/esxi
           ....
           The user's password must be supplied in a local file using the separate -ip parameter.
......
vCenter: Supplying the password
       The vCenter password (usually for the root account, or the account specified by "user@" in the vpx URL)
       has to be written to a local file, and the name of that file specified on the virt-v2v command line
       using -ip passwordfile.
.....

2.Convert a guest from VMwarev(Center) without vddk and don't set any option about vmware password in v2v command line. v2v can report correct error info
# virt-v2v  -ic vpx://vsphere.local%5cAdministrator.73.141/data/10.73.75.219/?no_verify=1  Auto-esx6.7-win2019-x86_64-efi
[   0.0] Setting up the source: -i libvirt -ic vpx://vsphere.local%5cAdministrator.73.141/data/10.73.75.219/?no_verify=1 Auto-esx6.7-win2019-x86_64-efi
virt-v2v: error: -i libvirt: expecting -ip passwordfile parameter for 
vCenter connection

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

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


Result:
   No problem found, move the bug from ON_QA to VERIFIED

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 (new packages: virt-v2v), 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/RHEA-2022:2566