Now that vCenter 6.7U3 enables Dynamic DNS updates by default, it seems there is a bug that causes the vCenter HA (VCHA) IP address (on the 2nd NIC) to be registered to DNS as a second IP address for the vCenter server. This causes connectivity issues because end-users trying to connect to the vCenter interface via FQDN end up with 2 IP addresses, one of which most likely is not going to work (i.e. the VCHA IP address on the 2nd NIC, which likely does not have a default gateway). I was able to reproduce this bug in several different environments. One work-around is to disable vCenter HA entirely. This is not a very good work-around for customers that wish to have vCenter high availability. Does anyone know any other work-arounds, such as disabling dynamic DNS on the VCHA NIC, or disabling Dynamic DNS globally on the vCenter server? Also, does anyone from VMware know whether this bug will be fixed soon?
Sure, it's a very basic VCSA / VCHA setup. vCenter 6.7U3 appliance is configured as follows:
NIC 0 (default NIC):
IP = 10.201.30.111/24
Gateway = 10.201.30.1
NIC 1 (VCHA created NIC):
IP = 10.201.98.61/24
No Gateway (purposely; this is a private network for VCHA replication traffic only)
DNS name is "vc03.company.com".
Prior to VCSA 6.7U3, dynamic DNS was not supported so the corporate Microsoft DNS servers contained the following "A" record:
After updating to VCSA 6.7U3, dynamic DNS was enabled by default and VCSA automatically registered a second IP address on the Microsoft DNS server:
Therefore, when someone tries to access vCenter by FQDN (vc03.company.com), their DNS lookup will resolve to the above two IP addresses rather than the single IP address as in the past. Depending on the user/browser/OS, there will either be a lengthy delay (because the user's browser tries to access 10.201.98.61, which is the private VCHA IP address), or the connection will fail. Also, vCenter Enhanced Linked Mode failed intermittently because the other (2) vCenter servers were intermittently unable to connect to the vCenter by FQDN, presumably due to the second IP address which is not a routable IP address and not meant to be published to the world (it is only used for VCHA internal replication traffic).
Destroying vCenter HA solves the problem, but that's not a very good solution. I am hoping there is a more elegant solution.
Does sound like a strange issue (bug). I would open a case with GSS, and perhaps in the meantime you could remove the DNS server completely and manually create the DNS record for the single IP. I'll be waiting to hear what VMware says.
Removing the DNS server from vCenter is a non-option because that breaks name resolution for all vCenter services. We will open a ticket with VMware Support.
Regardless of it's a bug or not, try following methods to avoid misleading of VCSA FQDN:
1. Edit /etc/hosts file for each host and add the VCSA FQDN to its content.
2. Remove the 2nd registered record and add it again as a CNAME (Alias) record.
same problem here.
2nd NIC, isolated HA network, register in DNS and backup fails because of second DNS entry.
Edit local host file and set DNS to accessible IP address of the first network card but from 100 VMs to back up every day, 4-5 are not backed up because of DNS.
The workarounf does not work 100%.
I'd like to know how to prevent the NIC from registering in DNS.
Any new information?
NIC1: 192.168.32.10 (HA)
root@srv-31-010 [ ~ ]# /opt/likewise/bin/lw-update-dns
A record successfully updated in DNS
Unable to register reverse PTR record address 192.168.32.10 with hostname srv-31-010.pep.local
PTR records successfully updated in DNS
On DNS server for vCSA record can you verify if "Allow any authenticated user to update DNS records with the same owner name" is checked.
If the above option is checked, un-check the option and remove secondary DNS record.
Same problem here since 6.7U3.
Workaround for me:
modified /etc/cron.d/dns_update.cron - changed the line to /opt/likewise/bin/lw-update-dns --ipadress <primary ip> --fqdn <fqdn of vcsa>
Interesting observation: there are about 30 running processes of lw-update-dns - seems like they are hanging