{"id":508,"date":"2026-09-04T02:40:43","date_gmt":"2026-09-04T00:40:43","guid":{"rendered":"https:\/\/nutanix.ma\/?p=508"},"modified":"2026-09-04T02:43:31","modified_gmt":"2026-09-04T00:43:31","slug":"nutanix-prism-element-lcm-upgrade-step-by-step","status":"publish","type":"post","link":"https:\/\/nutanix.ma\/index.php\/2026\/09\/04\/nutanix-prism-element-lcm-upgrade-step-by-step\/","title":{"rendered":"Upgrading a Nutanix Cluster with LCM Step by Step"},"content":{"rendered":"
Upgrading a Nutanix cluster is one of those jobs that looks intimidating the first time and routine the tenth. Life Cycle Manager (LCM) does most of the heavy lifting \u2014 dependency resolution, rolling reboots, VM evacuation \u2014 but the order you do things in, and what you check before you press Apply, is still on you. This is the full sequence from a recent engagement, run entirely from Prism Element: inventory, then NCC, Foundation, AOS, firmware and finally AHV. Screenshots are from the actual cluster, with customer identifiers, addresses and dates redacted; version numbers are left intact because they’re the useful part.<\/p>\n
Before you start<\/h2>\n
Nutanix’s own recommendations for LCM updates are short and worth following to the letter. The ones that matter most in practice:<\/p>\n
\n
Do it in a maintenance window.<\/strong> Even though workloads live-migrate, users can see latency during the upgrade \u2014 noticeably so on clusters that only have 1GbE uplinks.<\/li>\n
Non-production first.<\/strong> Run the same sequence on a test or secondary cluster before touching production. The cluster in this walkthrough is a test environment for exactly that reason.<\/li>\n
Check the compatibility matrix.<\/strong> Nutanix publishes upgrade paths and interoperability (“what works with what”) on the portal. Check it before you start, not when LCM warns you.<\/li>\n
Prism Central before Prism Element.<\/strong> If the cluster is registered to Prism Central, PC must be on a compatible version before<\/em> you upgrade AOS on the cluster. LCM will remind you \u2014 we’ll see that screen later \u2014 but it’s better to have already done it.<\/li>\n
Deal with VMs that can’t live-migrate.<\/strong> Anything that can’t move needs to be powered off or reconfigured before a host-reboot update (hypervisor, firmware), or the update stalls trying to evacuate the host. VMs with ha_priority=-1<\/code> should be set as agent VMs so LCM handles them correctly.<\/li>\n
Silence email alerts temporarily.<\/strong> A rolling upgrade generates a flood of expected alerts. Disable email alerting in Prism for the window and re-enable it afterwards.<\/li>\n
One operation at a time.<\/strong> Wait for each LCM task to complete fully before starting the next. Don’t queue, don’t overlap.<\/li>\n<\/ul>\n
Step 1 \u2014 Run the inventory<\/h2>\n
Everything in LCM starts with an inventory. It scans the cluster, refreshes the available version list from the Nutanix portal, and runs bundle and version compatibility checks. Until this has completed, the Updates tab is either empty or stale.<\/p>\nInventory complete \u2014 LCM now knows what’s installed and what’s available.<\/figcaption><\/figure>\n
Step 2 \u2014 Review what LCM found<\/h2>\n
The Updates tab lists everything with a newer version. On this cluster that was AHV, AOS (6.10.1.7 offered as the LTS target against 6.10.1.5 installed), Foundation 5.9.0.2 against 5.7.1, and NCC 5.1.2 against 5.1.1. Note the banner at the top: Nutanix releases software into LCM in incremental phases, so a version you know exists may not appear immediately \u2014 in which case you download it from the portal and use Direct Uploads.<\/p>\n
The order we’re going to follow keeps the tooling ahead of the platform: NCC and Foundation first, then AOS, then firmware, then the hypervisor.<\/p>\nSix updates available. NCC goes first.<\/figcaption><\/figure>\n
Step 3 \u2014 NCC<\/h2>\n
Nutanix Cluster Check is the health-check framework, and upgrading it first means every subsequent precheck runs against the latest set of checks. Selecting NCC and clicking View Upgrade Plan brings up the review dialog. Read the impact statement every time: for NCC it’s simply that the Cluster Health Service restarts, with no workload impact.<\/p>\nReviewing the NCC plan \u2014 service restart only.<\/figcaption><\/figure>\n
Every LCM run follows the same two stages. Precheck runs an LCM framework check and a module check; Install downloads the bundle, applies it, then runs bundle and version compatibility checks again. NCC finishes in a few minutes.<\/p>\nNCC done. Return to Updates and the list has shrunk by one.<\/figcaption><\/figure>\n
Step 4 \u2014 Foundation<\/h2>\n
Back on the Updates tab, something worth noticing: after the NCC update and its inventory refresh, LCM is now offering AHV 10.0.1.1 where it previously showed only an el8 build. This is the staged release model in action \u2014 what’s available can change between runs, which is another reason to re-check the list after each update rather than planning everything from the first screenshot.<\/p>\nFive remaining \u2014 and a newer AHV target has appeared.<\/figcaption><\/figure>\n
Foundation is the imaging and node-expansion tool, and AOS upgrades depend on it. Its plan review notes a Genesis service restart, again with no disruption to workloads.<\/p>\nFoundation 5.7.1 \u2192 5.9.0.2.<\/figcaption><\/figure>\nFoundation complete.<\/figcaption><\/figure>\n
Step 5 \u2014 AOS<\/h2>\n
With the tooling current, the AOS upgrade. By this point LCM had auto-populated AOS 7.0.1.6 as the target, moving the cluster from the 6.10 line onto 7.x. LCM auto-selects the latest available version to resolve dependencies, but you can pick a different one from the dropdown if your compatibility matrix or Prism Central version says you should \u2014 check before accepting the default.<\/p>\nAOS 7.0.1.6 offered against 6.10.1.5 installed.<\/figcaption><\/figure>\n
The AOS plan review has two steps. The first is the impact statement: each Controller VM is rebooted in turn, one at a time, with no effect on user workloads \u2014 the cluster stays up because the other CVMs carry the storage path while each one restarts.<\/p>\nAOS plan, step one \u2014 rolling CVM reboots.<\/figcaption><\/figure>\n
The second step is the one people click through and shouldn’t. It’s the explicit warning: if this cluster is registered with Prism Central, upgrade Prism Central first<\/strong> to a compatible version. Running AOS ahead of PC is one of the most common ways to end up with a cluster PC can’t manage. If you haven’t done it yet, cancel here and go do it.<\/p>\nStep two \u2014 the Prism Central compatibility warning. Don’t skip it.<\/figcaption><\/figure>\n
Step 6 \u2014 Firmware<\/h2>\n
Once AOS is on the new version, the Firmware Updates view lists what’s outstanding on each node. Here that was HBA firmware (to 31.00.00.00) and BMC firmware via Redfish (to 01.01.10) across all three nodes. The Redfish path lets BMC updates happen without booting the node into a separate environment, so BMC went first.<\/p>\nSix firmware updates across three nodes \u2014 HBAs and BMCs.<\/figcaption><\/figure>\n
The BMC plan puts each CVM into maintenance mode and shuts its services down in turn; workloads aren’t disrupted.<\/p>\nBMC 01.01.06 \u2192 01.01.10 on all three nodes.<\/figcaption><\/figure>\n
Then the HBAs. This is the heaviest operation in the whole sequence, and the plan review says so: each node boots into a separate update utility, one node at a time, may reboot multiple times, and disk checks run before and after. Workloads migrate automatically \u2014 but read the line about making sure the cluster has enough compute and storage to run with one node offline. On a three-node cluster that’s the entire safety margin.<\/p>\nThree HBA updates remaining.<\/figcaption><\/figure>\nHBA 25.00.00.00 \u2192 31.00.00.00. Each node boots into the update utility in turn.<\/figcaption><\/figure>\n
Budget real time for this stage. Where the software updates each took minutes, the firmware pass on this cluster ran for well over an hour end to end, because every node has to be evacuated, rebooted into the utility, updated, checked and brought back before the next one starts.<\/p>\nFirmware complete on all nodes.<\/figcaption><\/figure>\n
Step 7 \u2014 AHV<\/h2>\n
Last, the hypervisor. With everything underneath it current, AHV 10.0.1.1 is offered for all three hosts.<\/p>\nAHV 10.0.1.1 available for three hosts.<\/figcaption><\/figure>\n
The AHV plan is another rolling host reboot with automatic workload migration \u2014 with one important exception called out in the dialog: on a single-node cluster, workloads will<\/em> be disrupted, because there’s nowhere for them to go. On three or more nodes, users shouldn’t notice beyond the latency mentioned earlier.<\/p>\nAHV plan \u2014 rolling host reboots, workloads migrate automatically.<\/figcaption><\/figure>\n
Afterwards<\/h2>\n
Once the last update finishes, run a fresh inventory to confirm the Updates tab is clear and nothing new has appeared, re-enable the email alerts you silenced, and run a full NCC health check. If the cluster uses a Witness VM, upgrade that too \u2014 its version is independent of AOS and PC and can be done at any point.<\/p>\n
The whole sequence on a three-node cluster is comfortably a half-day maintenance window, dominated by the firmware stage. It’s also almost entirely hands-off once you’ve reviewed each plan \u2014 which is exactly why the reviewing is the part worth doing carefully.<\/p>\n
![\"LCM](\"https:\/\/nutanix.ma\/wp-content\/uploads\/2026\/09\/prism-element-lcm-upgrade-00.webp\")
![\"LCM](\"https:\/\/nutanix.ma\/wp-content\/uploads\/2026\/09\/prism-element-lcm-upgrade-01.webp\")
![\"Review](\"https:\/\/nutanix.ma\/wp-content\/uploads\/2026\/09\/prism-element-lcm-upgrade-02.webp\")
![\"LCM](\"https:\/\/nutanix.ma\/wp-content\/uploads\/2026\/09\/prism-element-lcm-upgrade-03.webp\")
![\"LCM](\"https:\/\/nutanix.ma\/wp-content\/uploads\/2026\/09\/prism-element-lcm-upgrade-04.webp\")
![\"Review](\"https:\/\/nutanix.ma\/wp-content\/uploads\/2026\/09\/prism-element-lcm-upgrade-05.webp\")
![\"LCM](\"https:\/\/nutanix.ma\/wp-content\/uploads\/2026\/09\/prism-element-lcm-upgrade-06.webp\")
![\"LCM](\"https:\/\/nutanix.ma\/wp-content\/uploads\/2026\/09\/prism-element-lcm-upgrade-07.webp\")
![\"Review](\"https:\/\/nutanix.ma\/wp-content\/uploads\/2026\/09\/prism-element-lcm-upgrade-08.webp\")
![\"Review](\"https:\/\/nutanix.ma\/wp-content\/uploads\/2026\/09\/prism-element-lcm-upgrade-09.webp\")
![\"LCM](\"https:\/\/nutanix.ma\/wp-content\/uploads\/2026\/09\/prism-element-lcm-upgrade-10.webp\")
![\"Review](\"https:\/\/nutanix.ma\/wp-content\/uploads\/2026\/09\/prism-element-lcm-upgrade-11.webp\")
![\"LCM](\"https:\/\/nutanix.ma\/wp-content\/uploads\/2026\/09\/prism-element-lcm-upgrade-12.webp\")
![\"Review](\"https:\/\/nutanix.ma\/wp-content\/uploads\/2026\/09\/prism-element-lcm-upgrade-13.webp\")
![\"LCM](\"https:\/\/nutanix.ma\/wp-content\/uploads\/2026\/09\/prism-element-lcm-upgrade-14.webp\")
![\"LCM](\"https:\/\/nutanix.ma\/wp-content\/uploads\/2026\/09\/prism-element-lcm-upgrade-15.webp\")
![\"Review](\"https:\/\/nutanix.ma\/wp-content\/uploads\/2026\/09\/prism-element-lcm-upgrade-16.webp\")