Launching soon: The world's first vendor agnostic bug scrubLearn more & join waitlist
OPERATIONAL DEFECT DATABASE
...
...
Cold-migration from On-premises Vcenter to Cloud Vcenter fails at the compute resource validation screen with the error: Authenticity of the hosts's SSL certificates is not verifiedCold-migration woks within the respective Vcenters. i.e. you can migrate the same VM within different ESXi hosts in the On-premises Vcenter without any issues. Cold-migration works for VMs from Cloud Vcenter to On-premises Vcenter.This issue is not VM specific and is consistent across the whole environment.You have Self-Signed Vcenter certificate on the On-Premises side and the cloud Vcenter certificate also shows as valid.On-Premises vpxd logs show the below exception: --> [backtrace end]vpxd[] [Originator@6876 sub=vpxLro opID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx-xxxxx] [VpxLRO] – FINISH session[xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx-xxxxx]vpxd[] [Originator@6876 sub=Default opID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx-xxxxx] [VpxLRO] – ERROR session[xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx-xxxxx – ProvChecker – vim.vm.check.ProvisioningChecker.checkRelocate: vim.fault.SSLVerifyFault: --> Result: --> (vim.fault.SSLVerifyFault) { --> faultCause = (vmodl.MethodFault) null, --> faultMessage = <unset>, --> selfSigned = false, --> thumbprint = "<SSL THUMBPRINT>" --> msg = "" --> } --> Args: --> --> Arg vm: --> 'vim.VirtualMachine: <VM_UUID>' --> Arg spec: --> (vim.vm.RelocateSpec) { --> service = (vim.ServiceLocator) { --> instanceUuid = ",<UUID>", --> url = "https://vCenterFQDN:443/sdk", --> credential = (vim.ServiceLocator.SAMLCredential) { --> token = (not shown) --> } , --> sslThumbprint = "<SSL THUMBPRINT>" --> }, --> folder = <unset>, --> datastore = <unset>, --> diskMoveType = <unset>, --> pool = 'vim.ResourcePool:', --> host = <unset>, --> disk = <unset>, --> transform = <unset>, --> deviceChange = <unset>, --> profile = <unset> --> } --> Arg testType: --> (string) [ --> "sourceTests", --> "resourcePoolTests", --> "hostTests" --> ]
This issue can be experienced because of DNS issues. Make sure the On-Premises DNS which is being leveraged by the On-Premises Vcenter and the Cloud Vcenter is able to resolve the Public FQDN of the Cloud Vcenter.
Make sure the On-Premises DNS which is being leveraged by the On-Premises Vcenter and the Cloud Vcenter is able to resolve the Public FQDN of the Cloud Vcenter. Note:Primary requirement for DNS under MGW is to resolve On-Prem FQDNs, so that features such as HLM can be configured successfully. For the other way round, primarily the cloud side vCenter URL has to be resolved by the On-Prem components. this record is set in DynDNS service, so if the On-Prem DNS server is capable of resolving public names it should automatically be able to resolve Vcenter URL to private IP (if Vcenter name resolution is set to private in VMware Cloud on AWS portal under DNS).If required a forward lookup zone and reverse lookup zone can also be created for vmc.vmware.com on the On-prem DNS server so that the On-Prem management components are able to resolve the Cloud Vcenter on both IPs (Private and Public)