Description of problem: While performing V2V migration I've noticed that it fails if VMWare hypervisor isn't configured as cluster member but it is located directly under datacenter. When hypervisor is located in Datacenter -> Hypervisor (I don't have the exact error now, sadly I can't replicate it now, but it was something like this:) libvirt: ESX Driver error : invalid argument: Path '/Datacenter/host/1.2.3.5/1.2.3.5?no_verify=1' ends with an excess item When hypervisor is located in Datacenter -> Cluster -> Hypervisor # oc logs kubevirt-v2v-conversion-rhel8test-64kj4 | grep "Opening the source" 2020-05-28 20:14:03,350 - root - DEBUG - b'[ 0.0] Opening the source -i libvirt -ic vpx://administrator%40rafal.vmware.3.4/Datacenter/host/Cluster/1.2.3.5?no_verify=1 rhel8test -it vddk -io vddk-libdir=/opt/vmware-vix-disklib-distrib -io vddk-thumbprint=39:06:99:13:33:BF:F5:4F:99:EF:85:64:FF:BB:65:DD:B2:93:A7:85\n' Version-Release number of selected component (if applicable): OCP 4.4.4 CNV 2.3 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
(In reply to Rafal Szmigiel from comment #0) > When hypervisor is located in Datacenter -> Hypervisor > (I don't have the exact error now, sadly I can't replicate it now, but it > was something like this:) > > libvirt: ESX Driver error : invalid argument: Path > '/Datacenter/host/1.2.3.5/1.2.3.5?no_verify=1' ends with an excess item If this is the path passed to the tooling then it is wrong. Marek, what are the rules for constructing the URI for VMware connection? From the tooling POV it should not matter whether the host is in cluser or not. Whether it is required by the UI I cannot tell. But judging from the fact that it got to the conversion POD it is not a hard requirement (or a bug).
It follows these rules: https://libvirt.org/drvesx.html The actual value is composed via: vmware_uri: `vpx://${username}@${hostname}${vm?.detail?.hostPath}?no_verify=1` Unfortunately the code has been multiple times refactored since I last touched it months ago which make me difficult to track down actual setting of the hostPath value now. Filip, do you have an environment to try it? Can you please verify how the hostPath is set?
the UI doesn't touches that; it takes the hostPath straight from V2VVmware CR for example: spec.vms[5].detail.hostPath
@Filip, not sure I understand where "cluster" is a dependency if we are only connecting to the host. Can you verify?
The hostPath variable contains for example already mentioned `/Datacenter/host/Cluster/1.2.3.5` or `/Datacenter/host/1.2.3.5/1.2.3.5` and this is entirely resolved by kubevirt-vmware controller which I do not have an insight into.
Piotr, can you please investigate how is the `hostPath` constructed when the host is not assigned to Cluster?
Tomas, It is a matter of checking how we can build hostPath. We use vmware api to get it -> https://github.com/ManageIQ/manageiq-v2v-conversion_host/blob/master/kubevirt-vmware/pkg/controller/v2vvmware/client.go#L94 It seems that this call do not provide correct information (a bug in vmware api?). We could explore whether there is any other way to get this information but unfortunately I do not have an access to vcenter.
Apparently vmware uses host name as cluster name in this situation. I pushed a PR with a fix which removes duplication from hostPath. @Tomas please verify that it works correctly.
It works properly now, thanks.
Verified on latest CNV-2.4 (June 28 2020). RHEL7 VM import from VMware - VM placed under Datacenter, and not under cluster, was successful.
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, 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/RHSA-2020:3194