We did some debugging on the issue that prevents vCenter to be recovered, and it seems that the problem comes because the Dnslookup of the vCenter web interface returns a hostname that is different from the FQDN of the machine. Different shared resources on this server that also has an ILO (remote control) interface . Because of the web server redirect is not succeeding; it always redirects to FQDN and only works for the perfect FQDN , the remoteexecution from Beacon is not caching the 443 websso authentication as expected.
Setting the fqdn on the /etc/hosts has no effect as the nslookup talks only at DNS level.
There is any alternative to force the dnslookup resolution of the beacon to overwrite a hostname with another?. Any additional suggestion?.
Thanks for your effort, the ICMP ping is succeding either with the IP address, or the DNS name. Also the 443 standard ssl port is accessible by IP address or dns name. The problem comes because the customer has an ILO on that machine, and the first DNSlookup response from the IP is coming back for the other service name, not either the hostname.
The certificate validations on the https server of the vCenter are that strict, that only allow connections from one strict FQDN, the one that is not returned from DNS, and here there are multiple entries for the IP.
