Hello all,
I'm having some issues converting our test environment Windows vCenter 5.5 server to the 6.0U2 appliance using the migration assistant.
Quick background:
Converted our (HA) Windows SSO servers to PSC's successfully. After the conversion, we set them up as intermediate CA's (Configuring the vSphere 6.0 U1b or later VMware Certificate Authority as a Subordinate Certificate A...) based off our internal CA. Next up was configuring the PSCs in HA mode: Configuring PSC 6.0 High Availability for vSphere 6.0 using vCenter Server 6.0 Appliance (2113315) |.... This appears to have gone smoothly and function as expected. I can't really find solid doco on doing deep health checks on PSCs (please provide some links if you know of anything!)
Problem:
Now we're trying to convert our test environment vCenter servers from 5.5U3 to the 6.0U2 using the migration assistant. When we reach the "Exporting VMware License service data" stage, the wizard hangs. It sits there showing 0 movement in progress. The log files on the source and destination vCenter servers do not update until 60 minutes after the export started at which point the migration assistant reports that the export took longer than 60 seconds and has timed out.
I've also noticed that the ls.log file on the source vCenter server has the following log entries:
Caused by: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at sun.security.ssl.SSLSessionImpl.getPeerCertificates(Unknown Source)
at com.vmware.vim.vmomi.client.http.impl.ThumbprintTrustManager$HostnameVerifier.verify(ThumbprintTrustManager.java:206)
... 32 more
[2017-01-13 11:46:54,690 Timer-0 ERROR com.vmware.vim.license.service.check.impl.LicenseCheckerImpl] Cannot obtain license assignments:
- com.vmware.vim.license.dao.usage.fault.LicenseUsageDaoException: com.vmware.vim.license.vc.VcUnableToConnectException: com.vmware.vim.vmomi.client.exception.SslException: com.vmware.vim.vmomi.core.exception.CertificateValidationException: Server certificate chain not verified
at com.vmware.vim.license.dao.usage.impl.CurrentLicenseUsageDaoImpl.getPrimaryAssignmentsLicenseUsage(CurrentLicenseUsageDaoImpl.java:136)
at com.vmware.vim.license.dao.usage.impl.CurrentLicenseUsageDaoImpl.getLicenseUsage(CurrentLicenseUsageDaoImpl.java:111)
at com.vmware.vim.license.dao.usage.impl.CurrentLicenseUsageDaoImpl.getLicenseUsage(CurrentLicenseUsageDaoImpl.java:48)
at com.vmware.vim.license.service.check.impl.LicenseCheckerImpl.getLicenseUsage(LicenseCheckerImpl.java:125)
at com.vmware.vim.license.service.check.impl.LicenseCheckerImpl.tryDoLicenseChecking(LicenseCheckerImpl.java:95)
at com.vmware.vim.license.service.check.impl.LicenseCheckingTimerTaskImpl.execute(LicenseCheckingTimerTaskImpl.java:28)
at com.vmware.vim.license.service.impl.TimerTaskImpl.run(TimerTaskImpl.java:37)
at java.util.TimerThread.mainLoop(Unknown Source)
at java.util.TimerThread.run(Unknown Source)
Attempted fixes:
- Tried 're-trusting' SSO using the ssl-certificate-tool, command succeeds but doesn't resolve the issue.
- VMware support suggested clearing the VPX_LIC* tables from the vCenter DB: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=10294.... This didn't resolve my problem
- Tried installing the PSC intermediate VMCA certificates into the computer certificate store on the Windows vCenter server, didn’t fix the problem.
- VMware support suggested deleting the serenityDB folder from the vsphere web client server directory. Unsurprisingly this didn't fix the problem.
- Noticed the appliance kept trying to configure IPv6 and was failing. Noticed that the source vCenter had IPv6 disabled. I re-enabled IPv6 and attempted the migration again, but it failed at the same spot.
Really looking for some help from the community here, as it's holding up our migration off of Windows as well as onto vSphere 6.0. I have a SR with VMware support but as this isn't actually affecting my existing vCenter server they're not too rushed to fix this.
P.S - Redeployment of vCenter is out of the question. We have VMware solutions as well as 3rd party products that point to our vCenter servers (specifically vCloud Director) that would not tolerate a vCenter re-deployment. That's why I've run this in our test environment and need to make sure that we can migrate not just rebuild. If we COULD rebuild we would've done it already.
Message was edited by: AusSTY
Added SSO HA comment
