9.1 Supported Hypervisors for NCI and Feature Supportability
Key Takeaways
- Objective 1.1 opens by asking you to identify the supported hypervisors for Nutanix Cloud Infrastructure; AHV and VMware ESXi are the two you will meet in current deployments.
- AHV is included with NCI at no additional hypervisor licensing cost, which is the single most quoted commercial reason for choosing it over ESXi.
- A substantial set of features is AHV-only, including Acropolis Dynamic Scheduling, AHV high availability, VM templates in Prism Central, memory overcommit, and Flow Network Security enforcement.
- The authoritative answer for any given AOS release is the Compatibility and Interoperability Matrix on the Nutanix Support Portal, not a memorized list.
- The NCA 7.5 exam is written against AOS 7.5, AHV 11.0, and Prism Central pc.7.5, so feature availability should be judged against that release.
9.1 Supported Hypervisors for NCI and Feature Supportability
The very first knowledge statement under Objective 1.1 is "identify supported hypervisors for NCI." It is an easy point to score and an easy one to lose, because candidates who have only ever seen AHV assume Nutanix is an AHV-only platform, and candidates who came from VMware assume ESXi behaves identically on Nutanix as it does on a SAN.
Nutanix Cloud Infrastructure Is Hypervisor-Flexible
The Acropolis Operating System (AOS) and its Distributed Storage Fabric (DSF) are the constant. The hypervisor running above them is a choice:
| Hypervisor | Origin | Licensing | Where you will see it |
|---|---|---|---|
| AHV | Nutanix, built on KVM | Included with NCI — no separate hypervisor license | The default and most common choice; the exam is written around it |
| VMware ESXi | Broadcom/VMware | Licensed separately from VMware | Existing VMware estates moving to Nutanix hardware, and staged migrations |
| Microsoft Hyper-V | Microsoft | Licensed separately from Microsoft | Historically supported; Nutanix has progressively narrowed it, and Hyper-V administration guides are published only through earlier AOS releases |
[!IMPORTANT] Do not memorize a hypervisor list and treat it as permanent. Support status changes between AOS releases. The blueprint deliberately points Objective 1.1 at two references — Supported Hypervisors and Supportability of Features (by Hypervisor) — plus, under Objective 3.3, Determining Compatibility Between Hardware and Supported Products. The exam-correct instinct is "check the Compatibility and Interoperability Matrix on the Support Portal for this AOS version," not "recite the list I learned last year."
Why AHV Is the Default
AHV is a KVM-derived hypervisor that Nutanix builds, ships, patches, and supports as part of the platform itself. Three consequences follow, and all three are examinable at the recognition level:
- No hypervisor licensing cost. AHV is bundled into every NCI tier — Starter, Pro, and Ultimate. For an organization sizing a refresh, removing per-socket hypervisor licensing is frequently the headline number in the business case.
- One vendor, one support path. Storage, hypervisor, and management plane come from Nutanix, so an AHV cluster does not require the candidate to reconcile a hypervisor compatibility matrix against a separate storage vendor's matrix.
- One upgrade mechanism. AHV, AOS, firmware, and Prism Central are all updated through the Life Cycle Manager (LCM) inventory-and-update workflow. On ESXi, the hypervisor itself is upgraded through VMware's own tooling and lifecycle, so the cluster has two update tracks instead of one.
Feature Supportability by Hypervisor
This is the part that actually gets tested. The Distributed Storage Fabric — replication factor, compression, deduplication, erasure coding, snapshots, data locality — works underneath whichever hypervisor you run. The hypervisor-layer features do not.
| Capability | AHV | ESXi on Nutanix |
|---|---|---|
| DSF storage services (RF, compression, dedup, EC-X) | Yes | Yes |
| Prism Element and Prism Central management | Yes | Yes |
| Acropolis Dynamic Scheduling (ADS) | AHV only | Uses VMware DRS instead |
| AHV high availability | AHV only | Uses vSphere HA instead |
| AHV memory overcommit | AHV only | ESXi has its own memory model |
| VM templates in Prism Central | AHV only | Managed through vCenter |
| Flow Network Security microsegmentation enforcement | AHV only | Not enforced by Flow on ESXi hosts |
| Nutanix IPAM / managed networks | AHV only | ESXi uses vSphere port groups |
| Storage presentation to hosts | Native DSF | NFS datastore presented by the cluster |
The pattern is easy to remember once you see it: anything that schedules, restarts, secures, or addresses a VM is a hypervisor function, so on ESXi it belongs to VMware. Anything that stores, protects, or optimizes the data is a DSF function and behaves the same either way.
[!TIP] If a question describes a cluster running ESXi and then asks which Nutanix feature will handle a failed host's VMs, the answer is not AHV HA — it is vSphere HA. Nutanix does not replace the hypervisor's own clustering functions when you choose a third-party hypervisor.
Storage-Only Nodes Always Run AHV
One detail regularly catches candidates out. A storage-only node contributes capacity and CVM resources to the cluster but runs no guest VMs. Storage-only nodes run AHV regardless of the cluster's guest hypervisor. That means an ESXi cluster can be expanded with storage-only AHV nodes to add capacity without buying more ESXi licenses — a genuinely common design and a favourite scenario for exam items.
Mixing Hypervisors
A single Nutanix cluster runs a single guest hypervisor. You do not run some nodes on AHV and others on ESXi within one cluster to host VMs on both. What you can do is:
- Run multiple clusters with different hypervisors and manage them from one Prism Central instance.
- Add storage-only AHV nodes to a cluster whose guest hypervisor is ESXi, as described above.
- Migrate workloads between hypervisors with Nutanix Move, covered in section 10.1.
What to Take Into the Exam
For Objective 1.1 you need recognition, not depth: AHV is the included, Nutanix-built hypervisor and the platform default; ESXi is supported and keeps its own scheduling, HA, and networking constructs; the DSF layer is common to both; storage-only nodes run AHV; and the Compatibility and Interoperability Matrix is the authority for any specific release.
A customer runs a Nutanix cluster with VMware ESXi as the guest hypervisor and asks which Nutanix feature will restart their virtual machines if a host fails. What is the correct response?
An organization running an ESXi-based Nutanix cluster needs to add storage capacity without purchasing additional VMware licensing. Which approach fits, and what hypervisor will the added nodes run?
Where should an administrator look to confirm whether a specific feature is supported with a specific hypervisor on a specific AOS release?