Registering an Acquired Cluster and Scaling Prism Central
A parent company with Prism Central pc.2024.1 managing 8 clusters and 420 VMs acquires a subsidiary that runs a 3-node AHV cluster with AOS 6.5.1, 120 VMs, and no Prism Central. The subsidiary uses VLANs 10, 20, and 30 and has its own IT team that must retain day-to-day VM administration. The parent security team wants centralized audit and inventory, and the infrastructure team wants LCM to manage firmware and AOS from the parent PC. The parent PC is a small deployment with 3 VMs. Network teams confirm that the parent PC can reach the subsidiary cluster VIP and CVM IPs on TCP 9440, but the subsidiary has no forward DNS record for its cluster VIP. The subsidiary cluster is not registered to any Prism Central and has never had its AOS version validated against pc.2024.1. The change window is 4 hours, and the subsidiary cannot tolerate a full cluster outage.
1. List the prerequisites and compatibility checks you must complete before registering the subsidiary cluster to the parent Prism Central, and explain the risk if the AOS version is not supported.
Read the worked answer
Prerequisites: verify the Nutanix interoperability matrix for pc.2024.1 and AOS 6.5.1. If AOS 6.5.1 is not supported by that PC version, upgrade AOS on the subsidiary first through Prism Element LCM or deploy a compatible PC; do not register into an unsupported combination. Network: PC must reach the subsidiary cluster VIP and every CVM IP on TCP 9440; DNS forward and reverse for the cluster VIP and PC; NTP synchronized; no firewall or proxy blocking; unique cluster name; cluster not already registered to another Prism Central. PC capacity: confirm the small deployment can handle 9 clusters and 540 VMs and has free storage/CPU. Credentials: a Prism admin account on the subsidiary; record current PE config backup.
Risk if unsupported: registration may succeed partially but inventory, LCM, and APIs may fail or behave inconsistently; you could be blocked from upgrading and create a support case during the change window. It is safer to delay registration and upgrade in a separate window than to force it in 4 hours.
2. Design RBAC so subsidiary IT keeps local admin but parent security has audit, and CloudOps can manage LCM. Include AD group mapping and scope.
Read the worked answer
Configure AD/LDAP in Prism Central and map three groups. Subsidiary-IT-Admins gets a cluster-scoped Prism Admin (or a custom VM/network admin role) only on the subsidiary cluster, not Super Admin. Parent-Security-Auditors gets Prism Viewer plus access to audit logs; viewers cannot change objects. Parent-CloudOps gets the minimum role that includes LCM operations; if no custom LCM-only role exists, use Prism Admin scoped to the clusters with change control and logging, and explicitly document that hypervisor admins can access VM disks-RBAC cannot prevent that. Use projects/categories for VM self-service, but do not rely on projects for cluster administration.
Keep a break-glass local account in a vault; disable shared local admin after AD works. Enable syslog export of Prism Central audit logs to the parent SIEM. Test each group with a read-only and a change action. This gives subsidiary IT day-to-day control, parent security auditability, and CloudOps lifecycle control without global Super Admin.
3. Plan the 4-hour change window: sequence PC capacity check, registration, LCM baseline, and rollback. What do you do if registration succeeds but LCM shows the subsidiary AOS as unsupported?
Read the worked answer
Sequence: (1) pre-check PC scale and take a PC config backup; (2) confirm subsidiary PE config backup and NTP/DNS; (3) register the cluster to PC; (4) verify inventory and health; (5) run LCM inventory; (6) only if compatible, apply required firmware/NCC in a separate approved step-not in the same 4-hour window if AOS upgrade is needed. Do not upgrade PC and AOS simultaneously.
Rollback: if registration fails, the subsidiary remains managed by Prism Element; no data-plane outage. If registration succeeds but LCM marks AOS unsupported, stop. Do not attempt an AOS upgrade in the remaining window. Open a support case or schedule a separate upgrade window; you can leave the cluster registered if PC can still manage it, or unregister it if management is degraded. Document that unregistering removes PC management but does not delete VMs. The 4-hour window should end with registration and evidence, not a risky upgrade.