Foundation Discovery Stalls on the Third Node
You are deploying a three-node NX-3060-G8 cluster into a dark site. All nodes are racked on the same top-of-rack switch. IPMI addresses are 10.10.50.11–13 on VLAN 50; AHV host and CVM addresses will come from 10.20.100.0/24 on VLAN 100. There is no DHCP, no internet access, and no DNS delegation. The Foundation VM runs on a laptop connected to a switch port trunked for VLAN 50 and VLAN 100. Foundation discovers and images nodes 1 and 2, but node 3 never appears. Its IPMI link LED is green, and the BMC responds to ping from the laptop. The BMC web UI is reachable. The AOS 6.8.1 Foundation bundle and the LCM dark-site bundle are already local. The customer wants the cluster built today and says, “Just add the third node later.”
1. What addressing and prerequisite checks should you complete before restarting Foundation, and why is adding the third node later a poor choice?
Read the worked answer
Build a complete address plan before rerunning Foundation. Each node needs a unique AHV host IP and a unique CVM IP from 10.20.100.0/24, plus a cluster VIP. IPMI addresses are separate on VLAN 50. With three nodes, that is three host IPs, three CVM IPs, one VIP, and three IPMI addresses. Confirm DNS and NTP servers are reachable or locally defined, because Prism and LCM will fail later without consistent name resolution and time. Verify the laptop trunk allows both VLAN 50 and VLAN 100, and that the data VLAN is present on every node port; Foundation must reach IPMI and PXE-boot the nodes over the data network. Check BMC firmware against the compatibility matrix, confirm each node is powered on, and make sure the IPMI range in Foundation includes 10.10.50.13. Adding the third node later is poor because the initial two-node cluster has no failure tolerance at RF2, cannot satisfy normal resiliency expectations, and forces an expansion and full data rebalance later under production pressure.
2. Node 3 responds to ping but is not discovered by Foundation. What are the most likely causes, and what checks would you perform?
Read the worked answer
Ping only proves IPMI connectivity from the laptop; it does not prove Foundation can use the node. Check that 10.10.50.13 is inside the IPMI range and credentials configured in Foundation, and that it is not a duplicate address. Verify the BMC power state and boot device with ipmitool chassis status and ipmitool chassis bootdev pxe. Confirm the node’s data NICs are connected to ports that carry VLAN 100 and can reach the Foundation VM for PXE; if the laptop trunk only passes VLAN 50 natively, nodes 1 and 2 may have worked through a different port configuration. Check the switch MAC address table for the node’s BMC and data NICs. Review Foundation logs on the Foundation VM for the specific discovery or PXE timeout. Finally, confirm the BMC model and firmware are supported by the installed Foundation version; a reachable but unsupported BMC can still fail discovery.
3. After the cluster is created, LCM cannot reach the Nutanix portal. What dark-site configuration is required, and how would you validate it?
Read the worked answer
LCM must be pointed at a local web server that hosts the downloaded dark-site bundle and metadata instead of the internet portal. In Prism Element, configure the LCM dark-site URL and credentials, then run an inventory so LCM reads the local manifest and shows applicable bundles. Validate by confirming the Prism CVM can resolve and reach the dark-site host, that the URL path serves the manifest files without authentication errors, and that the imported bundle versions match the installed AOS and AHV versions. Do not simply upload one firmware file; LCM needs the dark-site inventory structure to calculate prerequisites and dependency order. After inventory, check that the desired AOS upgrade appears with a valid target state and that no component is marked unavailable. If inventory still fails, test with curl from a CVM to the dark-site URL and inspect LCM logs for TLS or proxy errors.