VMware Cloud Community
Ardak
Contributor
Contributor
Jump to solution

Configure vCenter 6.5 HA with the Advanced Option

Dears,

Issue:

After deployment of VCSA 6.5 with embedded PSC, I started HA configuration with the advanced option with different subnets for HA network(private) due to Disaster Recovery Site requirements. During vCenter HA configuration, I choose "Advanced Option", and supplied IP address and subnet information for the Passive and Witness nodes(without override failover management IP Option), and get error when clicking Next. Error: The operation is not allowed in the current state. Failed to get management network information. Verify if management interface (NIC0) is configured correctly and is reachable, and another issue when I'm trying via SSH. Error: Unable to get hostname resolved IP address for eth0. Any ideas?

ErrorViaWeb.PNGErrorViaSSH.PNG

Checklist:

DNS(hostA, PTR) records exist.

No duplicated  DNS records

All hostnames are resolved(via SSH too)

NTP configured, Time is correct.

No gateway on second interface(VNIC1)

SSH is enabled

Details:
Public(Stretched VLAN)

vCenter Name: vcenter01.domain.com

vCenter IP: 10.1.129.107/24

DNS/NTP: 10.1.26.25


Private(HA):

Primary Site:

Node: A

Hostname: vcenter01A.domain.com

IP: 10.1.128.21/24

DR Site:

Node: B

Hostname: vcenter01B.domain.com

IP: 10.1.113.107/24

3rd Site:

Node: Witness

Hostname: vcenter01W.domain.com

IP: 10.1.240.22/24



1 Solution

Accepted Solutions
Ardak
Contributor
Contributor
Jump to solution

Solution:

After analysis of iputil.py script, we found that rootcaust of issue is that vcenter name was created with uppercase(VCENTER01.domain.com), and DNS(HostA) record was created also with uppercase. But, unfortunately DNS reverse resolving(ip2fqdn) provides lowercase, and here is mismatch of records, cause for linux they are not the same, and there is no check for it, which definitely needs to be fixed with next release. So finally, I've just rebuild my vcenter 6.5 with lowercase and VOILA!!! PROBLEM IS FIXED!!!

View solution in original post

9 Replies
Ardak
Contributor
Contributor
Jump to solution

Solution:

After analysis of iputil.py script, we found that rootcaust of issue is that vcenter name was created with uppercase(VCENTER01.domain.com), and DNS(HostA) record was created also with uppercase. But, unfortunately DNS reverse resolving(ip2fqdn) provides lowercase, and here is mismatch of records, cause for linux they are not the same, and there is no check for it, which definitely needs to be fixed with next release. So finally, I've just rebuild my vcenter 6.5 with lowercase and VOILA!!! PROBLEM IS FIXED!!!

Zarathustra82
Contributor
Contributor
Jump to solution

This is annoying. I cannot enable vCenter HA and I can't just reinstall the vCenter with lower case letters. Is there a solution without having to rebuild the entire vCenter appliance? I see that version 6.5 has been released in a very "agile" way, so brace yourselves for more bugs. We're all beta testers now.

Reply
0 Kudos
georgesburke
Contributor
Contributor
Jump to solution

There is a workaround to resolve this issue:

SSH into the vCSA appliance and cd into /etc/vmware, and look for the file named systemname_info.json, and then run "cat systemname_info.json |grep -i VM_NAME" where VM_NAME is the name of your vCSA appliance.

If the above command comes back with capitals we will need to modify the entry for all lowercase letters.

To do so:

take a snapshot of the vCSA, and back up the systemname_info.json file by making a copy of it. To make a backup copy, run this command:

cp systemname_info.json systemname_info.json_backup

using vi, edit the original systemname_info.json file, correcting the hostname to be all in lower case.

Once that's done, reboot the vCSA appliance and try configuring vCenter HA again.

robert_23
Contributor
Contributor
Jump to solution

Hello Ardak,

in your configuration you use different subnets at the three nodes's HA ports. How can they communicate with each other without a HA port default route? Did you use static routes?

Reply
0 Kudos
Ardak
Contributor
Contributor
Jump to solution

Hello Robert,

Yeap, you have to add routes to eth1(second nic) file in /etc/systemd/network via ssh

root@XXXXXXXX [ /etc/systemd/network ]# cat 10-eth1.network

[Match]

Name=eth1

[Network]

Address=10.XXX.XXX.XXX/24

[Route]

Destination=10.XXX.XXX.XXX/32

Gateway=10.XXX.XXX.XXX

[Route]

Destination=10..XXX.XXX.XXX/32

Gateway=10.XXX.XXX.XXX

DHCP=no

robert_23
Contributor
Contributor
Jump to solution

Thanks Ardak, it works. Smiley Happy

Reply
0 Kudos
mediumrare
Enthusiast
Enthusiast
Jump to solution

There is another big pitfall...

VMware requires you to allow a TCP connection to your DNS servers

If your firewall permits UDP only, the setup will fail.

You can see it in the iputil.py script:

root@vcenter [ ~ ]# grep -n "usr/bin/host" /usr/lib/vmware-vcha/scripts/iputil.py

131:   fqdnCmd = [ '/usr/bin/host', '-W', '30', '-T', ip ]

root@vcenter [ ~ ]#

The "-T" is for TCP.

There is no hint in any documentation, not even in the great KB 1012382. Smiley Sad

I asked them to update the documentation and maybe to remove the "-T".

edit: typo

zanix
Contributor
Contributor
Jump to solution

I had same issue. The issue got solved after performing following two actions :

1. Edited file /etc/vmware/systemname_info.json  to modify  VCS name to lower case.

2. created reverse lookup zone in my AD , and recreated A record for VCS.

Reply
0 Kudos
Paul_Czopowik
Contributor
Contributor
Jump to solution

Wow, thanks! That was our problem! Our DNS is being load balanced via a Netscaler LB and the "DNS" protocol in the Netscaler does not use TCP.

My workaround was to specify one of the DNS severs directly (behind the LB) which does allow TCP and I was able to proceed with the VCHA setup.

-Paul

Reply
0 Kudos