11.1 Cluster Services Configuration: DNS, NTP, SMTP, and SNMP

11.1 Cluster Services Configuration: DNS, NTP, SMTP, and SNMP

Objective 3.1 begins with a single knowledge statement — "verify DNS, SMTP, SNMP, and/or NTP configurations" — that carries far more operational weight than its length suggests. These four settings are configured once, forgotten, and then cause outages that look like something else entirely.

All four are set from Prism Element under the cluster settings gear menu, and the equivalents for Prism Central are set in its own settings area.

Name Servers (DNS)

Configured under Settings → Name Servers, this list tells the CVMs which DNS servers to use.

What depends on it:

• Directory services integration. Active Directory or LDAP authentication resolves domain controllers by name. Broken DNS presents as "users cannot log into Prism," which nobody diagnoses as a DNS problem on the first attempt.
• Life Cycle Manager downloads. A connected-site LCM inventory reaches Nutanix download endpoints by hostname.
• Pulse and Insights. Telemetry upload resolves a Nutanix endpoint.
• SMTP, NTP, and syslog targets entered as hostnames rather than IP addresses.
• Certificate validation, where hostname matching matters.

[!TIP] Configure more than one name server. A single DNS entry makes name resolution a single point of failure for authentication, updates, and telemetry all at once.

Time Synchronization (NTP)

Of the four, NTP has the most severe failure mode. Nutanix is a distributed system, and distributed systems reason about ordering using time.

What depends on consistent time:

• Cassandra, the distributed metadata store, resolves competing writes with timestamps.
• Zookeeper, which manages leadership and locks, depends on consistent timing for lease expiry.
• Kerberos and Active Directory authentication, which typically rejects a request whose timestamp is skewed beyond about five minutes.
• Certificates, whose validity windows are evaluated against local time.
• Alerts, events, and logs, which become impossible to correlate across nodes when clocks disagree.

The guidance to remember

1. Use the same NTP sources for the CVMs and for the hypervisor hosts. Splitting them is how clusters end up with hosts and CVMs disagreeing about the time.
2. Configure multiple NTP servers, so the loss of one does not leave the cluster free-running.
3. In a Windows domain, point at the domain controllers, since that is the time source Kerberos authentication is already measured against.
4. Prism Central should use the same sources as the clusters it manages.

Verifying it

The blueprint points explicitly at the NCC health check check_ntp. Running it is the fastest way to answer "is time correct across this cluster," and it is the check to name if an exam item asks how you would verify NTP configuration.

ncc health_checks network_checks check_ntp

SMTP

Configured under Settings → SMTP Server, this is how the cluster sends mail. It requires the server address, port, and — where the relay demands it — credentials and a security mode.

Two consumers matter:

1. Alert email. The alert notification policy sends to recipients through this relay. If SMTP is unset, the cluster still raises alerts in Prism but nobody is told about them out of hours. This is the single most common cause of "we never got the alert."
2. Pulse. When a direct outbound HTTPS connection to Nutanix is not permitted, Pulse can fall back to sending its telemetry by email through the configured SMTP relay.

Prism provides a test email function; using it after configuration is the verification step.

SNMP

Configured under Settings → SNMP, this exposes the cluster to an existing enterprise monitoring platform. Nutanix supports:

• SNMP v2c, using a community string.
• SNMP v3, using a user with authentication and privacy — the version to choose when security matters, because v2c community strings cross the network in clear text.

You configure trap receivers so the cluster pushes events to the monitoring system, and Nutanix publishes a MIB that the monitoring platform imports so those traps are interpreted rather than displayed as raw OIDs.

SNMP is an additional notification path, not a replacement for the alert engine. Section 8.1 covers the alert model itself; SNMP is one of the ways alerts leave the cluster.

Verification Checklist

[!WARNING] When troubleshooting anything strange on a Nutanix cluster — authentication failures, LCM stalls, certificate errors, metadata inconsistency — check DNS and NTP early. They are cheap to verify and they explain a disproportionate share of confusing symptoms.