This is a task I find myself performing more than I would like, but there comes a time when you just have to get rid of Prism Central.
Unregistering a cluster from Prism Central is essential in various scenarios, including in a healthy environment, when facing connectivity issues between Prism Element (PE) and Prism Central (PC), or when PE is deleted without unregistration. It’s crucial to follow specific procedures to ensure a smooth transition and prevent data loss. Additionally, cleaning up Prism Self-Service configuration post-unregistration requires following detailed steps to ensure all remnants of the configuration are correctly removed, maintaining system integrity and readiness for future configurations.
IMPORTANT: Starting from pc.2024.1/AOS 6.8, once a Prism Element (PE) is unregistered from Prism Central (PC), it will be blacklisted and cannot be re-registered to the same PC or any other PC. In other words, the cluster is expected to be destroyed after it is unregistered. This change is part of the “PE Decommissioning” workflow introduced in pc.2024.1.
To ensure customers are aware of this behavior before proceeding, a warning message will now appear when attempting to unregister PE from PC using the ncli command.
Reasons to Unregister: Several key reasons can prompt unregistering an AOS cluster from Prism Central. These include concluding the evaluation period of Prism Central, shifting to a different managing Prism Central instance, addressing the aftermath of a decommissioned Prism Central, and modifying the IP settings of Prism Central’s VMs. This process is pivotal for maintaining optimal system management and configuration integrity.
Do’s and Don’t: When unregistering an AOS cluster from Prism Central, adhere strictly to the complete process detailed in the provided solution guidelines. This includes not prematurely removing Prism Central or Prism Element and maintaining PE and PC IP addresses in whitelists until the process concludes. Special attention is needed if your setup includes additional applications like nuCALM or Nutanix Disaster Recovery, as these configurations require extra steps for a thorough and correct unregistration and subsequent system integrity.

Solutions–
- Scenario 1: Unregistering from Prism Central
- Scenario 2: Unregister PC from PE
- Scenario 3: Unregister PE from PC
Scenario 1: Unregistering from Prism Central: Use this when connectivity to both PE and PC is normal
- Initiate SSH Session: Access any Controller VM within the cluster via SSH.
- Check Cluster Health: Execute “cluster status” to confirm all services are operational.
- Begin Unregistration: Use:
- “ncli multicluster remove-from-multicluster external-ip-address-or-svm-ips=pc-name-or-ip username=pc-username password=pc-password”
- Replace “pc-name-or-ip” with the Prism Central name or IP address and “pc-username” and “pc-password” with the login credentials for your Prism Central administrator account
- “ncli multicluster remove-from-multicluster external-ip-address-or-svm-ips=pc-name-or-ip username=pc-username password=pc-password”
- Confirm Unregistration: Verify the completion by running: “ncli multicluster get-cluster-state”
- Obtain Cluster UUID: Secure the cluster’s UUID by running: “ncli cluster info”.
- Cleanup Process: SSH into Prism Central, execute the unregistration cleanup script with the cluster’s UUID, and then obtain Prism Central’s UUID for complete cleanup.
- Run the unregistration clean-up script.
- “python /home/nutanix/bin/unregistration_cleanup.py uuid”
- Replace UUID with the value you obtained in Step 5.
- Get the UUID for Prism Central: “ncli cluster info“
- Final Cleanup: Return to the Controller VM and execute the “unregistration_cleanup.py” script with Prism Central’s UUID to conclude the process.
- “python /home/nutanix/bin/unregistration_cleanup.py uuid”
- Replace UUID with the value you obtained in Step 6.
- “python /home/nutanix/bin/unregistration_cleanup.py uuid”
Scenario 2: Unregister PC from PE: Use this when connectivity to both PE and PC is not normal, or PC was deleted.
- Initiate SSH Session: Access any Controller VM within the cluster via SSH.
- Check Cluster Health: Execute “cluster status” to confirm all services are operational.
- Obtain Cluster UUID: Get the Cluster UUID of the PC: “ncli multicluster get-cluster-state”
- Begin Unregistration: Run the following command to remove the registration information: “ncli multicluster delete-cluster-state cluster-id=cluster_uuid”
- Replace cluster_uuid with the value obtained in Step 3.
- If PC is still around, follow the steps in Scenario 1
Scenario 3: Unregister PE from PC: Use this when PE was deleted without being unregistration
- Initiate SSH Session: Access Prism Central within the cluster via SSH.
- Obtain Cluster UUID: Get the Cluster UUID of the PC: “ncli multicluster get-cluster-state“
- Begin Unregistration: Run the following command to remove the registration information: “ncli multicluster delete-cluster-state cluster-id=cluster_uuid“
Summary: Navigating the complexities of unregistering a cluster from Prism Central, this guide outlines detailed procedures for ensuring data integrity and system readiness. Key steps include initiating SSH sessions, verifying cluster health, and executing targeted commands for unregistration. Critical for system upgrades or resolving connectivity issues, the process demands precision, especially when additional applications are involved. This strategic approach ensures smooth transitions, maintaining operational excellence across scenarios—whether in standard connectivity, dealing with PC deletions, or addressing unregistered PEs.
What Do You Think?
Is this something you’re excited about? Did we miss any features you’re curious about? Feel free to share your thoughts in the comments below—we’d love to hear from you!
Hey Raj,
This is a great write up.
I am about to embark on this where a customer has grown from a couple of small converged clusters with self hosted PCs to need to move to external PC with more clusters landing.
Example here I’ve got 4 x 6.5 -> 6.10 clusters on the go with another 4 X new 7.0.0.5 clusters landed that can’t register to the same PCs so it makes sense to cut sideways for now.
Who knows the future, I get why blacklisting exists and at least knowing we can undo it to serve the need means we can still pivot when customers need to expand in different directions.
Thanks for the write up mate 🙂