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-v2v | Assignee: | Virtualization Maintenance <virt-maint> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Virtualization Bugs <virt-bugs> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | unspecified | CC: | juzhou, mxie, mzhan, ptoscano, rjones, tyan, tzheng, xiaodwan | ||||
Target Milestone: | beta | Keywords: | 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
liuzi
2020-06-08 03:38:26 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’ ? (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. |