I don't have a VMware 7 instance to test against.  We need someone
with access to an instance to go through all the permissions and
work out which one(s) are missing, which will take forever.  Or
to try to find the log file on the VMware side which logs the actual
missing permission - I don't think in the past we ever identified
such a log file, or even if VMware logs this information at all.

By the way does it work if you add ‘-io vddk-transports=nbd’ ?

(In reply to Richard W.M. Jones from comment #1)
> Or to try to find the log file on the VMware side which logs the actual
> missing permission

At least in VMware 6.5, these issues are logged in the VCSA (Server Appliance),
in /var/log/vmware/vpxd/vpxd.log, with an ERROR block with the details of
vim.fault.NoPermission.

> By the way does it work if you add ‘-io vddk-transports=nbd’ ?
For scenario2 :use vddk:
#  virt-v2v -ic vpx://vsphere.local%5clz.198.169/data/10.73.199.217/?no_verify=1  esx7.0-win2019-x86_64   -o rhv-upload -os nfs_data -of raw -b ovirtmgmt -it vddk -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78   -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -op /home/rhvpasswd -oo rhv-cluster=Default -oo rhv-direct -ip /home/passwd -oo rhv-verifypeer=true -oo rhv-cafile=/home/ca.pem  -io vddk-transports=nbd
[   0.8] Opening the source -i libvirt -ic vpx://vsphere.local%5clz.198.169/data/10.73.199.217/?no_verify=1 esx7.0-win2019-x86_64 -it vddk  -io vddk-libdir=/home/vmware-vix-disklib-distrib -io vddk-thumbprint=B5:52:1F:B4:21:09:45:24:51:32:56:F6:63:6A:93:5D:54:08:2D:78 -io vddk-transports=nbd
[   2.6] Creating an overlay to protect the source from being modified
[   5.6] Opening the overlay
[  21.1] Inspecting the overlay
[  26.1] Checking for sufficient free disk space in the guest
[  26.1] Estimating space required on target for each disk
[  26.1] Converting Windows Server 2019 Standard to run on KVM
virt-v2v: warning: /usr/share/virt-tools/pnp_wait.exe is missing.  
Firstboot scripts may conflict with PnP.
virt-v2v: warning: there is no QXL driver for this version of Windows (10.0 
x86_64).  virt-v2v looks for this driver in 
/usr/share/virtio-win/virtio-win.iso

The guest will be configured to use a basic VGA display driver.
virt-v2v: This guest has virtio drivers installed.
[  42.9] Mapping filesystem data to avoid copying unused and blank areas
[  43.9] Closing the overlay
[  44.1] Assigning disks to buses
[  44.1] Checking if the guest needs BIOS or UEFI to boot
[  44.1] Initializing the target -o rhv-upload -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -op /home/rhvpasswd -os nfs_data
[  45.6] Copying disk 1/1 to qemu URI json:{ "file.driver": "nbd", "file.path": "/tmp/v2vnbdkit.TNaV1m/nbdkit4.sock", "file.export": "/" } (raw)
    (100.00/100%)
[1326.3] Creating output metadata
[1327.9] Finishing off

Additional,for scenario 1 :without vddk,I think it's not a problem about access right.

Cannot reproduce the bug in rhel9 builds:
nbdkit-1.25.2-1.el9.x86_64
virt-v2v-1.43.3-2.el9.x86_64
libvirt-7.0.0-4.el9.x86_64
qemu-kvm-5.2.0-7.el9.x86_64

#  virt-v2v -ic  vpx://vsphere.local%5clz.198.169/data/10.73.199.217/?no_verify=1  esx7.0-rhel8.2-x86_64 -o rhv -os 10.66.144.40:/home/nfs_export -ip /home/passwd
[   0.0] Opening the source -i libvirt -ic vpx://vsphere.local%5clz.198.169/data/10.73.199.217/?no_verify=1 esx7.0-rhel8.2-x86_64
[   2.3] Creating an overlay to protect the source from being modified
[   3.3] Opening the overlay
[  46.9] Inspecting the overlay
[ 350.3] Checking for sufficient free disk space in the guest
[ 350.3] Estimating space required on target for each disk
[ 350.3] Converting Red Hat Enterprise Linux 8.2 (Ootpa) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[2052.1] Mapping filesystem data to avoid copying unused and blank areas
[2055.6] Closing the overlay
[2055.9] Assigning disks to buses
[2055.9] Checking if the guest needs BIOS or UEFI to boot
[2055.9] Initializing the target -o rhv -os 10.66.144.40:/home/nfs_export
[2056.7] Copying disk 1/1 to /tmp/v2v.RigA3p/2d3ba741-81a8-4204-8c10-c976a088cf95/images/ad6e69a5-49f2-4834-ab34-ddf4a4ce71ee/9bbcaa8c-f111-45c1-8a7c-fa24e492903d (raw)
    (100.00/100%)
[4914.4] Creating output metadata
[4914.5] Finishing off

I don't believe we've fixed anything here, so magic(!)

Let's move this bug to RHEL 9.

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.

The issue has been fixed in RHEL 9, so setting the correct resolution.