Prism Central Upgrade Disconnects the On-Premises Cluster
A manufacturing company manages one on-premises AHV cluster and two NC2 clusters, one in Azure East US and one in West US, from a single Prism Central instance running in East US. Prism Central and both NC2 clusters are connected through a hub VNet and site-to-site VPN; the on-premises cluster uses a 100 Mbps VPN with 55 ms average latency. After an administrator upgraded Prism Central, the on-premises cluster shows disconnected in Prism Central, while both Azure clusters remain connected. Alert volume increased fivefold, mostly cluster unreachable and health check failed events. The team has a change freeze in 48 hours and wants to avoid deploying a second Prism Central. They also need to patch AHV and AOS across all clusters next month.
1. What are the most likely causes of the on-premises cluster disconnection, and what sequence would you use to restore management without breaking the Azure clusters?
Read the worked answer
Because both Azure clusters remain connected, the Prism Central service and the Azure-side network are probably healthy; the failure is likely on the path to the on-premises cluster or in trust/registration after the PC upgrade. Check in order: VPN status and routes to the on-premises Prism Element; NSG/firewall rules for TCP 9440 and related ports; DNS resolution of the on-premises cluster FQDN/IP from PC; time synchronization and certificate validity; Prism Central service health and disk/CPU; and whether the upgrade changed the PC IP, certificate, or registration token. Do not re-register the cluster until you confirm the path. Restore by fixing routing/firewall or restarting the PC service, then re-register only if the cluster record is stale. Keep the change freeze: this is restoration, not an upgrade. After recovery, suppress duplicate alerts and verify health checks.
2. Evaluate whether the company should keep a single Prism Central in Azure or deploy a Prism Central on-premises or per-region. Consider latency, blast radius, and operational overhead.
Read the worked answer
A single Prism Central in Azure gives one pane but makes on-premises management dependent on a 100 Mbps, 55 ms VPN. That is acceptable for occasional management, but it is a blast-radius problem: a WAN outage or PC upgrade can isolate the on-premises cluster, as seen. Options: keep one PC but add a resilient ExpressRoute/VPN and a documented break-glass Prism Element login; deploy a second PC on-premises and accept two consoles or federation if supported; or place PC in the site with the most critical workloads. For this estate, I would keep the Azure PC for the NC2 clusters and deploy a small on-premises PC for the on-prem cluster if the 48-hour freeze and next-month patching make WAN dependency unacceptable. Do not stretch one PC across high-latency links without validating scale and backup/restore.
3. Plan the LCM and NCC upgrade order and safeguards for the hybrid estate.
Read the worked answer
Use the Nutanix compatibility matrix first; do not upgrade blindly because PC is newer. Before the window, back up Prism Central, validate NCC health, confirm enough capacity for rolling upgrades, and snapshot critical VMs. Update NCC, then upgrade Prism Central if required for the target AOS/AHV, then upgrade one Prism Element cluster at a time, starting with the least critical Azure cluster. Verify cluster health, PC connectivity, and application checks before moving to the next. Upgrade the on-premises cluster last or during a separate window because of the 55 ms VPN. Keep AHV and AOS within supported combinations and do not upgrade both at once on the same cluster. If the change freeze is near, defer the upgrade rather than risk the disconnected on-prem cluster.