Nutanix AOS Lifecycle Management with LCM: The Unified NCI Release Model and Upgrade Operations

Nutanix made a structural change to its release model starting with AOS 6.5 that has substantial operational implications for any organization planning Nutanix lifecycle management on assumptions that pre-date the change.

The prior model used three release branches. Long Term Support (LTS) branches received bug fixes and minimal new features over a 12-to-15 month maintenance window with extended troubleshooting support beyond that. Short Term Support (STS) branches received new features quarterly with a shorter support window. Extended Short Term Support (eSTS) was a middle ground for organizations that wanted some feature currency without committing to the STS quarterly cadence. The release model gave organizations a choice between stability and feature currency.

Starting with AOS 6.5, this branching model was retired. Under the Unified NCI Release Model, there is one release stream. Major and minor releases are typically issued every 6 to 9 months. Every release receives 15 months of active maintenance with both bug fixes and security patches, followed by an additional 9 months of troubleshooting-only support that includes security patches but not bug fixes. The total supported lifetime for any release is approximately 24 months.

As of May 2026, the AOS release landscape consists of several supported releases under the Unified NCI Release Model and several recently retired releases that are no longer supported.

AOS 7.5.1.2 is the current latest release, released in May 2026. It is in active maintenance through December 2027. AOS 7.3 is also supported, with active maintenance through June 2027. AOS 7.3.1 includes specific feature additions including improved support for VMware to AHV migration with external Pure Storage via Nutanix Move.

AOS 7.0 was the first release under the Unified NCI Release Model. It has moved to its security-only support window and will reach end of life on its scheduled date. AOS 6.8 was the last release under the prior LTS model. It reached end of life on August 31, 2025. Customers still running AOS 6.8 are operating on unsupported software and should plan an immediate upgrade.

Nutanix Life Cycle Manager is the orchestration tool that handles upgrades of AOS, AHV, firmware, and dependent components on Nutanix clusters. LCM is integrated into Prism Element and Prism Central rather than being a separate product.

The architectural premise of LCM is that infrastructure upgrades on a Nutanix cluster involve multiple components that need to be coordinated. AOS is the platform software. AHV is the hypervisor that runs on AOS. Firmware lives on the underlying hardware including the BIOS, BMC, NIC firmware, drive firmware, and HBA firmware. Each component has its own update cadence but the upgrades need to be sequenced and validated together to maintain cluster health.

LCM provides the coordination. It maintains awareness of every version of every component on every node in the cluster. It validates which target versions are supported by the source versions and by the hardware platform. It plans the upgrade sequence to maintain cluster availability throughout the upgrade. And it executes the upgrades with appropriate pre-checks, monitoring, and rollback paths.

The user-facing experience is a single LCM page in Prism that shows current versions, available updates, and the option to plan and execute an upgrade. Behind that interface, LCM is performing substantial orchestration including downloading update bundles, staging them on each node, sequencing the node upgrades, monitoring cluster health throughout, and validating completion.

Nutanix Cluster Check (NCC) is the operational health check tool for Nutanix clusters. NCC runs a comprehensive set of checks that validate cluster configuration, performance, and operational state. NCC is the discipline that should run continuously, not only before upgrades.

NCC is built into AOS. It does not require separate installation. The full NCC check suite runs by default on a configurable schedule, typically weekly, and produces a report categorized by severity (Pass, Warn, Fail, Error). The check suite includes hundreds of individual checks covering storage health, network configuration, hardware status, software version consistency, performance characteristics, and many other dimensions.

For lifecycle operations specifically, NCC is the prerequisite. LCM will not initiate an upgrade if NCC reports failures or errors that would interfere with the upgrade process. The pre-upgrade discipline is to run NCC, review the output, resolve any failures, and confirm a clean NCC result before initiating LCM.

The LCM workflow has distinct phases that the administrator participates in. Understanding each phase clarifies what LCM is doing and where to intervene if something does not look right.

LCM scans every node in the cluster and catalogs the current versions of every component. AOS version, AHV version, BIOS, BMC, NIC firmware, drive firmware, HBA firmware, Foundation version, Prism version, and various dependent components. The inventory may take 15 to 30 minutes depending on cluster size.

LCM compares the inventoried versions against the supported upgrade paths. For each component, LCM identifies which target versions are available and which target combinations are valid. Some upgrade paths require intermediate versions.

LCM presents the available upgrade plans to the administrator. The plans are typically organized by software (AOS upgrade, AHV upgrade, Prism upgrade) and by firmware (specific hardware component upgrades). The administrator reviews the plans and selects which to execute.

LCM executes the upgrade by processing one node at a time. The rolling upgrade preserves cluster availability throughout. VMs continue running on the cluster (on different nodes than the one being upgraded) with no scheduled downtime.

The rolling node upgrade is the architectural pattern that makes Nutanix upgrades non-disruptive to workloads. Understanding what happens at the node level during an upgrade clarifies why specific cluster states are required and what failure modes mean.

For each node, the upgrade sequence is the following. First, LCM enters the node into maintenance mode. The Controller VM (CVM) on that node coordinates with the cluster to ensure data redundancy is maintained when the node is unavailable. VMs running on the node are live-migrated to other nodes in the cluster. The node is now empty of active VM workload but still participating in the storage cluster.

Second, LCM applies the upgrade to the node. The specific operations depend on what is being upgraded. AOS upgrades typically update the CVM software. AHV upgrades update the hypervisor itself, which often requires the node to reboot. Firmware upgrades update specific hardware components and may require multiple reboots depending on the components.

Third, after the upgrade applies, the node returns to service. The CVM rejoins the cluster. The storage layer reincorporates the node. The hypervisor is ready to accept VMs. Fourth, VMs that were previously running on this node may migrate back. The cluster scheduler decides VM placement based on resource utilization across the cluster.

Firmware management is one of the more operationally significant aspects of running Nutanix infrastructure. Firmware affects many hardware components, and the coordination of firmware updates with software updates is non-trivial.

LCM manages firmware updates for components that are integrated with the Nutanix platform. This includes the server BIOS, the Baseboard Management Controller (BMC), Network Interface Card firmware, drive firmware (SSD and HDD), Host Bus Adapter firmware, and specific hardware accelerator components.

For Nutanix-branded NX-series hardware, LCM provides direct firmware management. The hardware is fully integrated and LCM has complete visibility into firmware versions and target levels. For Nutanix on Cisco UCS hardware, the firmware management is split. UCS firmware is managed through Cisco Intersight or UCS Manager rather than through LCM directly. The coordination between Nutanix software upgrades (handled by LCM) and Cisco UCS firmware upgrades (handled by Cisco tooling) is a planning requirement.

Firmware update sequencing matters. Some firmware updates require specific software versions as prerequisites. Other firmware updates need to be coordinated with reboots that affect operations. The Nutanix compatibility documentation specifies the validated combinations.

Prism Central has its own lifecycle that is related to but separate from AOS lifecycle. Coordinating Prism Central upgrades with AOS upgrades is part of the broader Nutanix operational discipline.

Prism Central is a separate Nutanix appliance (typically running as a VM on a Nutanix cluster) that provides multi-cluster management. Prism Central has its own release cadence, its own version numbering, and its own LCM workflow. The compatibility between Prism Central versions and AOS versions is specified in Nutanix documentation. Newer Prism Central versions can typically manage older AOS clusters, but not always vice versa.

Operational best practice is to upgrade Prism Central first, then upgrade AOS on managed clusters. This sequence ensures that Prism Central can manage the AOS versions both before and after the cluster upgrade. Prism Central upgrades are typically less operationally disruptive than AOS upgrades because they affect only the management plane.

AHV has its own version numbering and its own lifecycle considerations that are coupled to AOS but warrant specific attention. AHV versions are tracked separately from AOS versions. A given AOS release typically ships with a specific AHV version. AHV updates are typically applied as part of AOS upgrades through LCM. In some cases AHV can be updated independently of AOS, but the standard pattern is coupled upgrades.

The AHV upgrade process involves the hypervisor on each node. Live migration moves VMs off the node being upgraded, the AHV image is updated, the node reboots, and VMs are returned to the upgraded node. The behavior is consistent with the rolling node upgrade pattern described earlier.

AHV upgrades may include changes to guest tools (Nutanix Guest Tools, NGT). NGT updates are typically applied within guest VMs through standard NGT update procedures. The administrator does not need to manually coordinate NGT updates with AHV upgrades; the integration handles this.

The coordination between platform upgrades and production workloads is the operational interface between the platform team and the application teams. Most Nutanix upgrades are transparent to applications. The rolling node upgrade pattern keeps the cluster operational throughout. VMs continue running. Storage continues serving I/O. Network connectivity is preserved. Applications running in the VMs see no direct impact.

Some upgrades have indirect application effects. Live migrations during the rolling upgrade are individually brief but can cause momentary pauses in VM execution (typically milliseconds, occasionally longer for specific workloads). Performance-sensitive workloads may notice these pauses. Most workloads do not.

Application owner communication is part of the upgrade discipline. Even for non-disruptive upgrades, application owners should be notified of the schedule. This allows them to be prepared for any unexpected behavior and to participate in validation after the upgrade. Skipping this communication because 'the upgrade is non-disruptive' is the kind of operational shortcut that creates organizational friction.

Upgrades succeed in the substantial majority of cases. When they do not succeed cleanly, the failure modes are predictable. The most common failure mode is a pre-upgrade check that prevents the upgrade from starting. NCC failures, capacity issues, or specific environmental conditions trigger LCM to refuse the upgrade. The resolution is to address the underlying issue and re-run the pre-upgrade check.

Less commonly, an upgrade can fail partway through the cluster. One node has been upgraded successfully, the next node enters maintenance mode, and something prevents the upgrade from completing on that node. The cluster ends up in mixed-version state with some nodes at the new version and some at the old.

LCM provides specific guidance for resolving mid-upgrade failures. The administrator typically does not need to drive the recovery manually; LCM presents options for resuming or rolling back the upgrade. The recovery path depends on the specific failure and is documented in the LCM error guidance.

Long-term lifecycle planning under the Unified NCI Release Model requires different thinking than the LTS-based model. Under the LTS model, an organization might run on an LTS branch for 3 to 4 years before requiring an upgrade. Lifecycle planning could align with hardware refresh cycles or other multi-year initiatives. The cadence was relatively slow.

Under the unified model, the supported lifetime of any release is approximately 24 months (15 months active maintenance plus 9 months security-only). To stay in the active maintenance window, organizations need to upgrade every 12 to 18 months. This is a meaningfully faster cadence.

The implication is that lifecycle planning becomes an ongoing discipline rather than a periodic project. Each year, organizations should expect at least one major upgrade. Some years may involve multiple upgrades depending on the specific release cadence and the organization's risk tolerance.

The operational pattern that works under the unified model is to treat upgrades as routine rather than as special events. Standard schedules, standard processes, standard validation. The discipline that makes routine upgrades successful is the same discipline that worked under LTS but applied more frequently.

Under Aegis Managed Nutanix, IVI's Lifecycle Management service handles the AOS, AHV, and firmware upgrade discipline as part of the managed services scope. The operational model is co-managed. The customer's team retains operational ownership of VMs, applications, and business priorities. IVI's team handles platform-level operations including lifecycle management. The interface between the two is well-defined and documented.

IVI's Lifecycle Management workflow includes continuous version tracking. IVI engineers maintain awareness of every AOS, AHV, Prism Central, and firmware version across managed clusters. The version inventory is refreshed continuously through Prism Central integration and through the Aegis Performance Monitoring data collection.

When new AOS releases are issued by Nutanix, IVI evaluates them for the managed customer base. The evaluation considers the release notes, known issues, customer-specific dependencies, and the appropriate timing for adoption. Critical security patches are typically scheduled quickly. Major version upgrades are scheduled with appropriate change management lead time.

Upgrade planning is coordinated with the customer. The proposed upgrade schedule, the scope of the upgrade (AOS only, AOS plus AHV, AOS plus AHV plus firmware), and the expected timing are reviewed with the customer's IT team before execution. Customer-specific timing constraints (business calendar, application maintenance windows, regulatory requirements) are accommodated.

The scope of Aegis Lifecycle Management is bounded deliberately. Understanding what is covered and what is not covered is essential for setting accurate expectations.

Covered by Aegis Lifecycle Management: AOS version management including upgrades, patches, and version compliance. AHV version management with the same scope. Prism Element and Prism Central version management. Hardware firmware management for components in the Nutanix-managed scope (BIOS, BMC, NIC firmware, drive firmware, HBA firmware). Coordination of these upgrades with the customer's change management process.

Not covered: guest operating system issues. Operating system updates within VMs (Windows Update, RHEL satellite, etc.), guest OS configuration, guest OS troubleshooting are the customer's responsibility. IVI engineers can advise but do not directly operate guest OS lifecycle. Application-layer issues including application configuration, application troubleshooting, application performance tuning beyond the platform layer are the customer's responsibility.

The boundary is documented in the Aegis Master Service Agreement and is reviewed annually. Customers can adjust the scope through scope amendments if their requirements change. The reason for the bounded scope is straightforward. IVI's expertise is in the platform layer. Application-level work requires application-specific expertise that varies by customer and is not efficiently provided by a generalist managed service.