Adding vCenter as a Compute Manager fails with "Unable to configure fabric for... Please check if vCenter is up and running and also check if NSX Extension present in vCenter Server and delete the same."

Products

• VMware NSX

Issue/Introduction

• Unable to add vCenter as a Compute Manager to NSX
• SDDC Deployment fails.
• /var/log/cm-inventory/cm-inventory.log contains lines like:
  DNS reverse lookup IPs are [] for FQDN: <fqdn>
DNS is misconfigured for the IP <IP> -> fqdn <fqdn> and ipReverseLookup[]
• The commands below return the correct information:
  nslookup <fqdn>
nslookup <IP-address>
• The commands below are missing the required DNS information and/or missing the Answer section of the output:
  /usr/bin/dig <fqdn>
/usr/bin/dig -x <IP-address>

Environment

VMware NSX

Cause

NSX uses the dig command to resolve FQDNs.  If the output of dig does not include the expected information in an Answer section NSX will be unable to connect to the Compute Manager.

Generally, DNS resolution failure issues typically occur due to one the following reasons:

1. DNS Configuration Issues:
• Incorrect or missing DNS entries for NSX Manager or vCenter.
• DNS server configuration errors or DNS server unavailability.
• Some DNS servers may not respond with an Answer section when using the command as shown in the Resolution section.
2. Host Name Resolution Issues:
• NSX Manager is unable to resolve the vCenter server's hostname to an IP address.
  
  
3. Incorrect/Expired Certificates:
• Issues with SSL/TLS certificates might also cause failed connections if the DNS resolution is dependent on certificates for trust validation.
  
  
4. Firewall or Security Group Blocking:
• Network traffic between NSX Manager and DNS server may be blocked due to firewall rules or security groups.

Resolution

1. Run the /usr/bin/dig <fqdn> command, and verify the output in the "Answer" section is correct:
   • Example of a correct output:

     • root@edge01:~# /usr/bin/dig <fqdn>
       ; <<>> DiG 9.18.28-0ubuntu0.22.04.1-Ubuntu <<>> <fqdn>
       ;; global options: +cmd
       ;; Got answer:
       ;; WARNING: .local is reserved for Multicast DNS
       ;; You are currently testing what happens when an mDNS query is leaked to DNS
       ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15328
       ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
       
       ;; OPT PSEUDOSECTION:
       ; EDNS: version: 0, flags:; udp: 4000
       ;; QUESTION SECTION:
       ;<fqdn>.                IN      A
       
       ;; ANSWER SECTION:
       <fqdn>. 3600    IN      A       192.#.#.#
       
       ;; Query time: 0 msec
       ;; SERVER: #.#.#.##53(#.#.#.#) (UDP)
       ;; WHEN: Thu Feb 20 14:44:32 UTC 2025
       ;; MSG SIZE  rcvd: 67

2. Run the /usr/bin/dig -x <IP-Address> command, and verify the output in the "Answer" section is correct:
   • Example of a correct output:

     • root@edge01:~# /usr/bin/dig -x <IP-address>
       ; <<>> DiG 9.18.28-0ubuntu0.22.04.1-Ubuntu <<>> -x <IP-address>
       ;; global options: +cmd
       ;; Got answer:
       ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30823
       ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
       
       ;; OPT PSEUDOSECTION:
       ; EDNS: version: 0, flags:; udp: 4000
       ;; QUESTION SECTION:
       ;10.#.#.#.in-addr.arpa.   IN      PTR
       
       ;; ANSWER SECTION:
       <IP-address>. 3600 IN    PTR     <DNS-fqdn>.
       
       ;; Query time: 4 msec
       ;; SERVER: #.#.#.##53(#.#.#.#) (UDP)
       ;; WHEN: Thu Feb 20 15:02:32 UTC 2025
       ;; MSG SIZE  rcvd: 94

3. If the outputs in the first 2 steps are missing the "Answer" section or are showing incorrect values in the "Answer" section, then it points to an issue with DNS server configuration or the underlying connectivity.