Bill_Oyler
Hot Shot
Hot Shot

vCenter 6.7U3 Dynamic DNS issue with vCenter HA (VCHA) - duplicate DNS records creating connectivity issues

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?

Bill Oyler Systems Engineer
Tags (2)
16 Replies
ryanrpatel
Enthusiast
Enthusiast

Do you have a diagram or something showing your setup? Specifically, the NICs & Switch assignments, IP addressing, GW and such.

0 Kudos
Bill_Oyler
Hot Shot
Hot Shot

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:

vc03.company.com: 10.201.30.111

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:

vc03.company.com: 10.201.30.111,10.201.98.61

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.

Bill Oyler Systems Engineer
0 Kudos
a_p_
Leadership
Leadership

I'd suggest that you open a support ticket for this to get an official answer?

Maybe it's already a known bug, and VMware has a fix/workaround already available.

André

0 Kudos
ryanrpatel
Enthusiast
Enthusiast

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.

0 Kudos
Bill_Oyler
Hot Shot
Hot Shot

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.

Bill Oyler Systems Engineer
0 Kudos
johncol
VMware Employee
VMware Employee

Would you mind pm'ing me the sr # when you do, thanks

0 Kudos
NathanosBlightc
Commander
Commander

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.

or

2. Remove the 2nd registered record and add it again as a CNAME (Alias) record.

Please mark my comment as the Correct Answer if this solution resolved your problem
0 Kudos
Vijay2027
Expert
Expert

Can you open an SR for this, there is a potential fix available.

0 Kudos
maussem
Contributor
Contributor

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?

0 Kudos
Vijay2027
Expert
Expert

What is the output of below command??

/opt/likewise/bin/lw-update-dns

0 Kudos
maussem
Contributor
Contributor

Hello Vijay2027,

NIC0: 192.168.31.10

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

Thank you

0 Kudos
Vijay2027
Expert
Expert

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.

0 Kudos
maussem
Contributor
Contributor

Option is not checked but for nic0 I delete an recreated the DNS record.

Delete secondary DNS record and run shell command.

NIC1 register in DNS again.

0 Kudos
berndweyand
Expert
Expert

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

maussem
Contributor
Contributor

Hello bernweyand,

workaround seems to work. HA NIC has not registered in the DNS since the change.

Thanks

0 Kudos
berndweyand
Expert
Expert

Vmware just released a patch for this:6.7.0.42000-15132721-patch-FP.iso (6.7U3b)

before applying this patch you should cleanup: VMware Knowledge Base

0 Kudos