What is Nutanix AHV? The Hypervisor, the Licensing Model, and Why It Matters in 2026

Nutanix AHV is an enterprise hypervisor developed and maintained by Nutanix as part of the Nutanix Cloud Infrastructure platform. AHV stands for Acropolis Hypervisor, named after the Acropolis layer of the Nutanix platform stack. It is a Type 1 bare-metal hypervisor in the same architectural category as VMware ESXi and Microsoft Hyper-V, meaning it runs directly on server hardware and hosts virtual machines without requiring an underlying general-purpose operating system.

Technically, AHV is built on KVM (Kernel-based Virtual Machine), the Linux kernel virtualization technology that also underpins Red Hat Virtualization, much of the public cloud (AWS, Google Cloud, Azure all use KVM-derivative technology), and a substantial portion of the world's running virtual machines. Nutanix did not invent virtualization technology when it built AHV. It packaged, hardened, and operationalized KVM into an enterprise-grade hypervisor with the management, automation, and integration that production deployments require.

The practical definition for a virtualization administrator is straightforward: AHV is a hypervisor that runs Linux and Windows VMs, supports vCPU and memory configuration, attaches virtual disks and virtual NICs, performs live migration between hosts, handles host failures through high availability, and is managed through a centralized interface called Prism. From the workload perspective, an AHV-hosted VM looks like any other VM. The guest operating system does not know or care that it is running on AHV rather than ESXi.

What distinguishes AHV from other enterprise hypervisors is not the underlying technology but the packaging. AHV is included in every Nutanix Cloud Infrastructure license at no additional hypervisor licensing cost. There is no separate ESXi-style purchase decision, no per-CPU or per-core hypervisor charge layered on top of the platform license. The hypervisor is part of the platform.

AHV was not built in response to Broadcom's VMware acquisition. It has been part of the Nutanix platform since 2015. Understanding the context for why Nutanix built its own hypervisor years before the current VMware licensing crisis clarifies what AHV is meant to be and what it is not.

Nutanix launched in 2011 as a hyperconverged infrastructure pioneer. The early Nutanix platform ran on VMware ESXi, with Nutanix providing the storage layer and VMware providing the hypervisor. This model worked, but it had a structural problem: Nutanix was selling a platform whose primary economic value (consolidated infrastructure, simpler operations, scale-out architecture) was undermined by the VMware licensing cost that customers continued to pay on top of the Nutanix platform cost. VMware's pricing and bundling decisions could effectively cap Nutanix's commercial value to customers, and Nutanix had no control over them.

The strategic response was to build an alternative hypervisor that Nutanix controlled. Acropolis Hypervisor launched in 2015 as a free-with-the-platform option for Nutanix customers, initially with reduced feature parity compared to ESXi and Hyper-V. Over the subsequent decade, AHV's feature set expanded to cover the substantial majority of what enterprise virtualization administrators need. By 2020, AHV was already a credible primary hypervisor for most workloads. By 2026, AHV adoption among Nutanix customers exceeds ESXi adoption on the Nutanix platform, and AHV is positioned as the default Nutanix hypervisor in nearly all new deployments.

AHV runs as the hypervisor layer on a Nutanix node. A typical Nutanix node has several distinct software components: AHV as the hypervisor, the Controller Virtual Machine (CVM) that handles the storage stack, the AHV Linux kernel running the actual virtualization, and the Acropolis service that provides the cluster-level orchestration.

The CVM is the architectural feature that distinguishes Nutanix from competing hypervisor platforms. Every Nutanix node runs a CVM as a privileged virtual machine on AHV (or on ESXi in older deployments). The CVM owns the storage capacity of the local node, manages the local NVMe and SSD drives, and participates in the Nutanix Distributed Storage Fabric (DSF) that spans the cluster. When an AHV-hosted VM issues a storage read or write, the I/O is routed to the local CVM, which then handles cluster-level data placement, replication, and consistency.

AHV itself is responsible for running VMs. The components include libvirtd (the standard Linux virtualization management daemon, which handles VM lifecycle operations), the acropolis agent (a Nutanix-specific service that coordinates AHV with the broader Nutanix platform), and Open vSwitch (OVS, the standard Linux software-defined networking stack that provides virtual switching on AHV hosts). Each of these is a service that can be monitored and that has specific failure modes that experienced AHV operators learn to recognize.

Networking on AHV uses Open vSwitch as the data plane. Bridges, bonds, and VLANs are configured at the AHV host level, with VM virtual NICs attached to those bridges. The networking model is more Linux-native than ESXi's vSwitch and Distributed Virtual Switch model. For administrators familiar with Linux networking, this is comfortable. For administrators primarily familiar with ESXi networking, this is one of the more meaningful operational adjustments when adopting AHV.

Live migration on AHV operates similarly to vMotion. VMs can be moved between AHV hosts in the same cluster with no downtime, with memory state being copied between hosts while the VM continues running. AHV's live migration is managed through Prism rather than vCenter, and the underlying mechanics are KVM live migration rather than VMware's proprietary vMotion, but the operational behavior is functionally equivalent for the user.

High availability is built into the cluster. When an AHV host fails, the VMs that were running on that host are restarted on surviving hosts in the cluster. Nutanix Acropolis Dynamic Scheduling (ADS) handles workload placement across hosts and rebalances when load distribution becomes uneven.

Understanding AHV economics requires understanding what AHV is and is not separately from the Nutanix platform license.

AHV is included in every Nutanix Cloud Infrastructure (NCI) license. There is no separate per-CPU charge, no per-core charge, and no per-VM charge for the hypervisor itself. When an organization licenses NCI, AHV is part of what they have licensed. The hypervisor capability is bundled in.

This is meaningfully different from the VMware model where vSphere ESXi is licensed separately (or as part of VCF) on a per-CPU or per-core basis with various edition tiers and feature gates. With VMware, the hypervisor license itself is a meaningful line item. With Nutanix, that line item is zero because the hypervisor is included in the platform.

The Nutanix platform license itself is not free, of course. NCI is sold in editions (Starter, Pro, Ultimate) with feature differences and is priced per CPU core. The platform license is the cost driver. AHV being included in that license means the hypervisor cost is part of the platform decision rather than a separate procurement.

Replacing ESXi with AHV in an existing Nutanix deployment is a license simplification. The customer is already paying for NCI. They were also paying VMware for ESXi. Moving to AHV eliminates the VMware line item. The Nutanix license cost does not change.

Replacing a standalone VMware environment (where the customer was paying VMware for vSphere and was not on Nutanix at all) with AHV requires a Nutanix platform purchase. This is the more common scenario in 2026. The economic comparison is the Nutanix platform license cost versus the VMware Cloud Foundation license cost, plus any operational differences. For most organizations doing this analysis seriously, NCI plus AHV comes out economically favorable to VCF, and that comparison is what is driving the VMware exit conversations.

AHV's feature set in 2026 is comprehensive for the substantial majority of enterprise virtualization workloads. The capabilities that AHV handles well include the entire core virtualization feature set and a significant portion of the advanced features that virtualization administrators expect.

Live migration of running VMs between AHV hosts is fully supported and operationally equivalent to vMotion from the user perspective. VMs can be moved across the cluster without downtime, including during host maintenance, firmware upgrades, and load balancing operations. The performance and reliability of live migration on AHV is on par with VMware vMotion in most production environments.

High availability with automatic VM restart on host failure is standard and well-tested. When an AHV host fails, Acropolis detects the failure and orchestrates the restart of VMs on surviving hosts. The behavior is similar to VMware HA. The recovery time depends on cluster configuration and VM count but is typically measured in minutes rather than hours.

Resource scheduling across the cluster is handled by Acropolis Dynamic Scheduling. ADS continuously monitors load across hosts and rebalances VM placement to even out CPU, memory, and storage utilization. The behavior is broadly similar to VMware DRS. Anti-affinity policies, affinity groups, and host-specific placement rules are supported.

Snapshot and clone operations are first-class capabilities. AHV supports VM-level snapshots, fast clones (copy-on-write clones that consume minimal storage), and integration with Nutanix Protection Domains for VM-level replication and DR.

Virtual disk management is straightforward. VMs can have multiple virtual disks attached, disks can be expanded online, virtual disks can be moved between storage containers, and the underlying storage characteristics (storage tier, replication factor) are managed at the storage policy level rather than per-VM. This is operationally cleaner than the per-VM datastore selection model that some other hypervisors use.

Networking through Open vSwitch supports VLAN tagging, port-channels and LAG bonds for redundancy and bandwidth aggregation, jumbo frames, and standard Layer 2 switching behavior. VM virtual NICs can be placed on different VLANs through standard configuration.

Guest operating system support is broad. Windows Server (all currently supported versions), Windows 10 and 11 for VDI workloads, the major Linux distributions (Red Hat Enterprise Linux, SUSE Linux Enterprise Server, Ubuntu LTS releases, Oracle Linux, Rocky Linux, Alma Linux, and CentOS Stream), and most enterprise application platforms are supported and tested. The Nutanix Compatibility Matrix is the authoritative source for current guest OS support.

Performance characteristics for general-purpose workloads are competitive with ESXi. Independent benchmarks and customer production data consistently show that AHV delivers comparable performance for the substantial majority of workloads. For workloads that have specific scheduling, memory management, or I/O characteristics where ESXi has been historically optimized, the AHV behavior can differ and should be validated.

AHV is not a feature-for-feature replacement for ESXi. Organizations adopting AHV need to understand the specific areas where AHV differs and plan for those differences.

NSX-T does not run on AHV. NSX-T is a VMware product and is tightly coupled to ESXi. Organizations with significant NSX-T investment (microsegmentation policies, distributed firewall rules, NSX-managed overlay networks) cannot simply migrate those configurations to AHV. The functional equivalent on Nutanix is Flow Networking, which provides microsegmentation and VPC-style network virtualization but with a different policy model and configuration approach. Migration from NSX-T to Flow Networking is a separate workstream from hypervisor migration and is non-trivial.

VMware Site Recovery Manager (SRM) configurations do not migrate to AHV. SRM is the VMware DR orchestration product. AHV environments use Nutanix Protection Domains and Nutanix DR (or third-party DR products) for analogous capability. The architectural concept is similar, but the configuration model and operational workflow differ. Existing SRM runbooks need to be replaced with Nutanix DR procedures, and DR testing should validate the new procedures before any cutover.

VMware Tools is replaced by Nutanix Guest Tools (NGT). The function is similar (guest OS integration, IP address reporting, file system snapshots, VSS integration on Windows). The installation and lifecycle are managed differently. Existing VMware Tools should be uninstalled and Nutanix Guest Tools installed during the migration process. Nutanix Move handles this automatically during VM migration.

PowerCLI scripts that automate vSphere operations need to be rewritten to use Prism APIs or Nutanix REST APIs. Existing automation is not portable. The Prism API surface is comprehensive and Nutanix provides SDKs in multiple languages, but the automation work is real and should be scoped explicitly in the migration plan.

AHV's positioning in 2026 is dominated by the VMware exit conversation. Broadcom's restructuring of VMware licensing has made AHV the most common destination for organizations leaving VMware. This section frames how AHV fits into that decision.

The typical evaluation arc begins with a Broadcom renewal that presents pricing significantly higher than the customer's prior VMware cost, often combined with consolidation of standalone vSphere into VCF bundles that include capabilities the customer did not previously license. The customer evaluates whether to renew at the new pricing, replace VMware entirely, or pursue a partial replacement strategy.

If the decision is to replace VMware, the next decision is the target platform. The primary alternatives are Nutanix with AHV, Microsoft Azure Stack HCI with Hyper-V, and various smaller HCI platforms. Nutanix has captured the majority of the announced VMware exit destinations because of three factors: AHV's maturity, Nutanix's commercial focus on the VMware exit segment with dedicated migration tooling (Nutanix Move), and the joint validation of architectures like FlashStack with Nutanix that protect existing Cisco and Pure hardware investment.

The migration itself is well-understood. Nutanix Move handles VM-level migration from ESXi sources to AHV targets, performing online replication of VM disks while the source VM continues running, with a brief cutover window at the end of migration. Move supports ESXi 6.0 through 8.0 as source and current AHV versions as target. The migration is operationally well-tested. Most VMs migrate without manual intervention. VMs with specific dependencies (NSX-T, SRM, specific guest tools configurations) require additional handling.

The decision is rarely whether AHV technically works for the workloads being migrated. For the substantial majority of enterprise workloads, AHV is operationally sufficient. The more nuanced questions are about the surrounding ecosystem and the migration complexity.

Specifically, the questions that matter for a VMware exit decision include: What is the NSX-T footprint, and what is the plan for it? What does the SRM configuration look like, and what is the DR runbook replacement plan? What automation has been built on PowerCLI that needs to be re-platformed? What backup and replication configurations need to be rebuilt? What licensing audit is required to confirm what is currently licensed and what is being retired?

AHV environments are managed through Nutanix Prism rather than VMware vCenter. Prism is the management plane, the monitoring interface, and the orchestration platform for Nutanix clusters running AHV.

Prism comes in two forms. Prism Element runs on each Nutanix cluster and provides cluster-local management. Prism Central is the multi-cluster management interface that runs as a separate VM (or VM pair for HA) and aggregates visibility and control across multiple clusters in the environment. For environments with a single cluster, Prism Element is sufficient. For multi-cluster environments, Prism Central is the operational interface.

The day-to-day management capabilities in Prism cover what virtualization administrators expect. VM lifecycle operations (create, modify, delete, power on, power off), virtual disk and virtual NIC management, snapshot operations, clone operations, live migration across hosts and across clusters, template management, and image catalog. The interface is web-based and the workflow is generally efficient. Administrators coming from vCenter typically find Prism Central comfortable within their first week of working with it.

The areas where Prism Central differs operationally from vCenter include the alerting model (Prism alerting is typically less verbose by default than vCenter and may need tuning for the operations team), the API surface (different from VMware APIs, requiring rework of existing automation), and the role-based access control model (different RBAC implementation than vSphere).

Prism Central upgrade cadence is faster than vCenter historically has been. Nutanix releases Prism Central updates frequently, and the upgrade process is integrated with the Nutanix Life Cycle Manager. Organizations adopting AHV should plan for a regular Prism Central upgrade rhythm as part of their ongoing operations.

AHV runs on Nutanix-supported hardware. The supported hardware list has expanded significantly since Nutanix transitioned from a hardware-defined platform to a software-first model.

Nutanix NX-series is Nutanix's own hardware. Nutanix sells NX-series nodes that are pre-configured for the Nutanix platform. NX-series is the simplest procurement path because everything comes from one vendor with one support relationship.

Nutanix on Cisco UCS is jointly supported by Cisco and Nutanix. Cisco UCS X-Series, C-Series, and B-Series servers can run Nutanix AHV with full joint support. This is the path most commonly used in IVI's AIM engagements because of the integration with existing Cisco UCS environments and the FlashStack with Nutanix joint validation.

Nutanix on Dell hardware (Dell PowerEdge servers, jointly validated for Nutanix) is also supported with joint Dell and Nutanix support.

The choice of hardware vendor is typically driven by existing relationships and operational preferences rather than by Nutanix platform differences. The Nutanix software platform is identical across hardware vendors. The hardware-specific differences are around server form factors, management interfaces, and lifecycle integration.

For organizations modernizing from VMware on Cisco UCS, running Nutanix AHV on the same Cisco UCS hardware is operationally the lowest-friction path. The hardware management (Intersight), the operational tooling, and the team's hardware expertise all transfer. The FlashStack with Nutanix architecture documents this path with joint Cisco, Pure, and Nutanix validation.

What does running an AHV environment look like in production? The operational profile differs from vSphere in specific ways that operations teams should plan for.

The upgrade cadence is regular and is managed through Nutanix Life Cycle Manager (LCM). LCM is the upgrade orchestration tool that handles AOS upgrades, AHV upgrades, firmware upgrades, and dependent component upgrades in a coordinated sequence. Pre-upgrade Nutanix Cluster Check (NCC) runs validate that the cluster is in a state suitable for upgrade. The actual upgrade rolls through the cluster one node at a time, with VMs being live-migrated off the upgrading node and back after the upgrade completes.

Nutanix Cluster Check (NCC) is the operational health check tool. NCC runs on a configurable schedule (default is weekly) and produces a report of cluster health issues. Most environments under-utilize NCC. Under Aegis Managed Nutanix, NCC runs continuously and any critical check failure is actioned within IVI's incident response scope. For self-managed environments, scheduling NCC to run regularly and acting on the output is one of the highest-leverage operational practices.

CVM health is a recurring operational focus. The Controller VM is critical to the cluster, and CVM issues are usually the first symptom of broader cluster problems. Monitoring CVM CPU, memory, and service health proactively is standard practice. Aegis Performance Monitoring includes custom LogicMonitor modules specifically for CVM and AHV service health that go beyond default platform monitoring.

The questions that practitioners ask before committing to AHV are predictable. This section addresses them directly.

Is AHV production-ready? Yes. AHV has been in production at enterprise scale for over a decade. There is no remaining question about whether the platform is mature enough for production workloads. The questions are about specific feature parity and migration complexity, not about basic readiness.

Is AHV slower than ESXi? In aggregate, no. For most workloads, the performance is comparable. For specific workloads, there can be differences in either direction. The blanket comparison is not a useful frame. Workload-specific validation during a pilot migration is the correct way to answer this for a specific environment.

Will my applications work on AHV? Almost certainly yes. The Nutanix Compatibility Matrix lists supported guest operating systems, and the substantial majority of enterprise applications run on those supported OS versions. Specific applications with hypervisor certification requirements (Oracle, SAP, some specialized ISVs) should be verified against current ISV certification.

Can I keep my existing storage? Yes, if the storage is Pure FlashArray and the deployment is compute-only Nutanix with NVMe/TCP connectivity. This is the FlashStack with Nutanix pattern. For other external storage platforms, compatibility should be verified with Nutanix and the storage vendor. iSCSI connectivity to external storage is also supported.

What happens to my VMware tools and PowerCLI scripts? VMware Tools is uninstalled and Nutanix Guest Tools is installed during migration (Nutanix Move handles this automatically). PowerCLI scripts need to be re-implemented using Prism APIs or REST API calls. The conceptual operations are similar but the API surface is different.

How long does the migration take? For a typical mid-size environment (50 to 500 VMs, 10 to 50 hosts), migration from VMware to AHV through Nutanix Move typically takes 12 to 24 weeks from project initiation through full cutover. The wide range reflects environment complexity, workload count, and the maturity of the customer's pilot and validation approach.