I have been working on few VMware vCenter Server High Availability Deployment Projects also known as VCHA, which was recently introduced with 6.5 release. We have seen few issues with these vSphere 6.5 environments and this is one of the issues, which I came across with few vCenter servers (6.5) configured with VCHA. I thought to share this real experience with my fellow readers to mitigate such similar issues in their environments.
After sometime of enabling VCHA (VMware vCenter High Availability,) we saw below configuration issue in the vCenter HA configuration.
vCenter HA has an invalid configuration. Click the remove button to destroy the current vCenter HA Cluster configuration
In few instances, it was not noticed and we were shocked to discover that the vCenter server totally out of the network and we were not even to ping to the IP address. So, it didn’t failover to the secondary node properly.
On the other hand, we had some issues with VCHA deployments due to the NFS v3 Datastore configuration, which I described in this article. Deployment was not succeeded and we didn’t notice that few configuration parts were sitting behind without the proper configuration of this feature. We rebooted the vCenter server and it totally went out from the network and “eth x” (x – value of the appliance network interface) didn’t appear in the “ifconfig”.
Luckily, we destroyed the VCHA cluster configuration as I describe in my previous article, and vCenter suddenly came in to the network and started to response.
So I think, there is a learning point and this article will give some heads up to all my vSphere admins to think twice to check the VCHA configuration before re-start the vCenter Server.
Honestly, I’m not quite sure this is some environment specific issue or something to do with the VCHA backend configuration with vCenter Server itself. It is something to find out and, it’s obvious that this wonderful VCHA feature will continue to evolve.
