12.3 The Software Compatibility Matrix and Upgrade Path Planning

12.3 The Software Compatibility Matrix and Upgrade Path Planning

Section 8.3 covered how the Life Cycle Manager performs upgrades. This section covers what you check before starting one — Objective 3.3's "describe software compatibility matrix."

Why a Matrix Exists

A Nutanix cluster is not one product on one version. At any moment it is running a specific version of each of:

• AOS
• The hypervisor (AHV, or ESXi at its own version)
• Prism Central
• NCC
• Foundation
• Firmware for BIOS, BMC, drives, and network adapters
• Add-on products such as Files, Objects, and NKP
• Third-party products integrated with the cluster, most commonly backup software

Not every combination of these is supported or even functional. The Compatibility and Interoperability Matrix on the Nutanix Support Portal is the authoritative record of which combinations are.

[!IMPORTANT] The matrix is a support statement, not documentation. "This combination works in my lab" and "this combination is supported" are different claims, and only the second one gets you help at 2 a.m. That distinction is exactly why the blueprint names the matrix in Objective 3.3 and again in Objective 1.1 for hypervisor support.

What the Matrix Answers

The blueprint also references "Prism Central and Prism Element Specifications" and "Determining Compatibility Between Hardware and Supported Products," which are the specific views behind the second and fifth rows.

Long Term Support vs. Short Term Support

Nutanix publishes AOS on two release tracks, and the choice materially changes an organization's upgrade cadence:

The trade is straightforward: LTS buys you time between mandatory upgrades; STS buys you features sooner at the cost of upgrading more often. An organization that adopts an STS release and then never upgrades will find itself unsupported far faster than it expected.

Upgrade Paths Are Not Always Direct

The assumption that any version can upgrade straight to any newer version is wrong, and it is the practical reason this objective exists.

A cluster several releases behind may need to move to an intermediate version first, because the upgrade code path from a very old release to the newest one has not been validated. The matrix and the upgrade path tooling identify these hops.

The planning implications:

1. A long-deferred upgrade is a multi-step project, not one maintenance window. Each hop is its own rolling upgrade with its own validation.
2. Falling far behind is expensive, which is the strongest operational argument for a regular upgrade rhythm.
3. Component order matters too. LCM enforces dependencies at execution time — for example, updating the LCM framework itself before the components it manages, and observing the documented order between AOS, AHV, firmware, and Prism Central. Prism Central generally needs to be at a version that supports the clusters it manages.

How This Fits With LCM

A useful division of labour:

• The matrix is planning. Before you schedule anything: is the target combination supported, and can I get there directly?
• LCM pre-checks are enforcement. At execution time, LCM runs pre-checks and refuses to proceed if the cluster is not in a fit state — insufficient resiliency, a node already in maintenance mode, an unsupported step.

Both exist because both failures are real. LCM will stop you from executing a bad upgrade; only the matrix stops you from planning one that was never going to work.

[!TIP] The exam-ready sentence: the Compatibility and Interoperability Matrix on the Nutanix Support Portal is the authoritative source for supported version combinations and upgrade paths. If an option offers release notes, the Nutanix Bible, community forums, or the hardware vendor's documentation as the authority for support status, it is wrong.

Common Software Maintenance Tasks

Objective 3.3 closes with "identify common software maintenance tasks." The recurring ones, all driven through LCM or Prism:

• LCM inventory, to discover current versions across the cluster.
• AOS and AHV upgrades, performed as rolling, non-disruptive updates.
• Firmware updates for BIOS, BMC, drives, and NICs.
• Prism Central upgrades, coordinated with the clusters it manages.
• NCC upgrades, which follow their own release cycle independent of AOS (section 8.2).
• NGT upgrades, which can be applied in bulk across many VMs rather than guest by guest.