Bug 1844926

Summary: virt-v2v cannot use non-admin user to convert guests from ESXI7.0
Product: Red Hat Enterprise Linux 9 Reporter: liuzi <zili>
Component: virt-v2vAssignee: Virtualization Maintenance <virt-maint>
Status: CLOSED CURRENTRELEASE QA Contact: Virtualization Bugs <virt-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: juzhou, mxie, mzhan, ptoscano, rjones, tyan, tzheng, xiaodwan
Target Milestone: betaKeywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-12-08 07:27:12 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
non-admin user without vddk log none

Description liuzi 2020-06-08 03:38:26 UTC
Created attachment 1695972 [details]
non-admin user without vddk log

Description of problem:
virt-v2v cannot use non-admin user to convert guests from ESXI7.0 

Version-Release number of selected components (if applicable):
virt-v2v-1.42.0-4.module+el8.3.0+6798+ad6e66be.x86_64
libguestfs-1.42.0-2.module+el8.3.0+6798+ad6e66be.x86_64
libvirt-6.4.0-1.module+el8.3.0+6881+88468c00.x86_64
qemu-kvm-5.0.0-0.module+el8.3.0+6620+5d5e1420.x86_64
nbdkit-1.20.2-1.module+el8.3.0+6764+cc503f20.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Create non-admin user in VMware7.0  environment with below permission
   Datastore:
      - Browse datastore
      - Low level file operations

   Sessions:
      - Validate session

   Virtual Machine:
     Interaction:
        - Guest operating system management by VIX API
     Provisioning:
        - Allow disk access
        - Allow read-only disk access

2.Use non-admin users to convert guests from ESXI7.0
Scenario 1:Convert the guest from VMware with non-admin vCenter user but without vddk by virt-v2v
#  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.7] Creating an overlay to protect the source from being modified
[   3.3] Opening the overlay
[  43.3] Inspecting the overlay
[ 139.6] Checking for sufficient free disk space in the guest
[ 139.6] Estimating space required on target for each disk
[ 139.6] Converting Red Hat Enterprise Linux 8.2 (Ootpa) to run on KVM
nbdkit: curl[2]: error: pread: curl_easy_perform: HTTP response code said error: The requested URL returned error: 503 Service Unavailable
nbdkit: curl[2]: error: problem doing HEAD request to fetch size of URL [https://10.73.198.169/folder/esx7.0-rhel8.2-x86%5f64/esx7.0-rhel8.2-x86%5f64-flat.vmdk?dcPath=data&dsName=esx7.0-matrix]: HTTP response code said error: The requested URL returned error: 503 Service Unavailable
[...]

Result 1: Conversion failed and virt-v2v kept printing error messages,cannot automated stop conversion.Details pls see non-admin.log

Scenario 2:Convert the guest from VMware with non-admin vCenter user and 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
[   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
[   2.5] Creating an overlay to protect the source from being modified
nbdkit: vddk[1]: error: VixDiskLib_Open: [esx7.0-matrix] esx7.0-win2019-x86_64/esx7.0-win2019-x86_64.vmdk: You do not have access rights to this file
qemu-img: /var/tmp/v2vovld6d13a.qcow2: Requested export not available
Could not open backing image to determine size.
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 [...]

Result2: already exist Bug 1817050 - Can't convert guest from VMware with non-admin vCenter user and vddk by virt-v2v

Additional info:
1.Can use non-admin user to convert guests from ESXI6.7 without vddk successfully.

Comment 1 Richard W.M. Jones 2020-06-08 09:05:04 UTC
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’ ?

Comment 2 Pino Toscano 2020-06-08 09:22:39 UTC
(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.

Comment 3 liuzi 2020-06-11 08:51:08 UTC
> 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.

Comment 5 liuzi 2021-02-23 11:00:28 UTC
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

Comment 6 Richard W.M. Jones 2021-04-27 16:19:45 UTC
I don't believe we've fixed anything here, so magic(!)

Let's move this bug to RHEL 9.

Comment 8 RHEL Program Management 2021-12-08 07:27:12 UTC
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.

Comment 9 Richard W.M. Jones 2021-12-08 10:25:43 UTC
The issue has been fixed in RHEL 9, so setting the correct resolution.