The latest (as of 26th June 2019) version on vCenter Server Appliance is 6.7u2b. This may come as somewhat of a suprise – as that is not available as a download from VMware.
We discovered this after deploying 6.7u2, then allowing the update process to patch the VCSA.
But then when we go to internalize external PSCs, we get a failure with the the build versions from ISO not matching….
From the converge.log
2019-06-12T03:39:19.839Z INFO converge Downloading RPMs
2019-06-12T03:39:19.839Z INFO converge Collected client:rest as a part of Telemetry
2019-06-12T03:39:19.960Z INFO converge VCSA ISO is mounted. Copying RPMs from the ISO.
2019-06-12T03:39:19.991Z INFO converge ISO version : VMware-vCenter-Server-Appliance-6.7.0.31000-13643870
2019-06-12T03:39:19.991Z INFO converge VC version : VMware-vCenter-Server-Appliance-6.7.0.31100-13843380
2019-06-12T03:39:19.992Z ERROR converge The version of the ISO doesn't match to the version of the VCSA.
VMware support supplied an new ISO: VMware-VCSA-all-6.7.0-13843380
All good.
But deploying a new test VCSA using that iso was always failing with LDAP error.
“Could not connect to VMware Directory Service via LDAP. Verify VMware Directory Service is running on the appropriate system and is reachable from this host.”
Same as detailed here: https://communities.vmware.com/thread/601788
Turns out that during part 2 or the setup – it edits the /etc/hosts file and loses the references to localhost
At end of part1 (deployment) Before Part2 (setup):
VAMI_EDIT_BEGIN
Generated by Studio VAMI service. Do not modify manually.
127.0.0.1 vcsa.xxxx.xxxx vcsa localhost
::1 vcsa.xxxx.xxxx vcsa localhost ipv6-localhost ipv6-loopback
VAMI_EDIT_END
After Part2 (failed install):
Begin /etc/hosts (network card version)
End /etc/hosts (network card version)
VAMI_EDIT_BEGIN
Generated by Studio VAMI service. Do not modify manually.
xxx.xxx.xxx.xxx vcsa.xxxx.xxxx vcsa
xxx.xxx.xxx.xxx vcsa.xxxx.xxxxvcsa
VAMI_EDIT_END
As you can see, the localhost entries for IPv4 and IPv6 are completely wiped out. So no service starts – because it can’t talk to itself.
So we need to fix this by logging into the shell after part 1, and before starting part 2 and append the localhost info after the VAMI_EDIT_END block
VAMI_EDIT_END
127.0.0.1 localhost.localdom localhost
::1 localhost.localdom localhost ipv6-localhost ipv6-loopback
I don’t see how this would ever work. Looks like a regression of an issue that was fixed in 6.7u1 https://docs.vmware.com/en/VMware-vSphere/6.7/rn/vsphere-vcenter-server-671-release-notes.html
and was an issue at 6.5 as well: https://cstan.io/?p=8962&lang=en
THANK YOU!!
Needed this still with the latest version of VCSA 6.7 (as of 2020 Feb 3’rd)
Unbelievable!!
Thanks man! As of this date, 4/18/2020, that damn /etc/hosts regression bug still exists! I was installing VCSA 7.0.0 from ISO today and stumbled upon this. Took me all damn day to find this article. Funny thing was that I started the installer again from a stage 1 snapshot for the fourth time and luckily, I edited /etc/hosts right before the usual crapout at the 4% mark.
THANK YOU!
‘sodo
I’d also like to say that VMware needs to simplify the product line and get their quality assurance testing act together. I’m a newbie to VMware ESX and VCSA on Linux and setup has been a nightmare.
8/13/20 and still exists (at least on the virtual appliance deploy). This worked for me, thanks man!
Even I installed using 6.7 U1 version ==> VMware-VCSA-all-6.7.0-10244745.iso, I am having issue still. What I did was during the parameter entry, I left the FQDN blank. It goes through stage 1 and stage 2. Else my server becomes my FQDN name which is wrong. I am not why. It seems to be a bug.
Once stage 2 completed, then I rename server name and DNS correctly again.
/opt/vmware/share/vami/vami_config_net
Restart VCSA and and it is working. I reconfigure all the information and working.
Hope this help those having the issue.