Module 3: AHV (The Hypervisor Question)

The Promise

By the end of this module you will:

1. Explain AHV to a VMware admin in 60 seconds without sounding defensive. AHV is the most emotionally loaded comparison in the Nutanix conversation. The customer's entire career is built on ESXi. You need a frame for AHV that lands as honest, not as conversion.
2. Know exactly what AHV does well, what it lacks, and the comparison to ESXi at a sentence level. No marketing. Specific gaps named. Specific strengths quantified.
3. Pass the AHV portions of NCP-MCI. Roughly 28% of the NCP-MCI blueprint touches AHV directly. Master this module and a quarter of NCP-MCI is in your pocket.
4. Handle the four most common AHV objections in customer conversations: "why would I switch hypervisors?", "what about FT?", "my backup vendor doesn't support AHV," and "my team has 10 years of ESXi expertise."
5. Make the Broadcom math case with specific dollar comparisons. By April 2026, this is the single strongest economic argument in your bag.
6. Position the mixed-hypervisor option correctly. The most common deal pattern in 2026 is not "switch from ESXi to AHV." It is "run ESXi on Nutanix today, drift to AHV over time, or stay mixed forever." You should be able to recommend this without sounding like you're hedging.

Foundation: What You Already Know

You know ESXi cold. The VMkernel, the vSphere stack, vCenter as a separate piece of management infrastructure, the licensing tiers (Standard, Enterprise Plus, vSphere Foundation, vCloud Foundation post-Broadcom), VMware Tools, the snapshot mechanics that everyone has been burned by once.

You know what vCenter does. It is the brain. Without it, you have unmanaged ESXi hosts. With it, you have HA, DRS, vMotion, Storage vMotion, distributed switches, content libraries, vRealize integrations, the Update Manager, the whole thing. vCenter is software you have to install, patch, monitor, and license.

Hold that picture. Now switch hypervisors.

AHV reorganizes those vCenter responsibilities. There is no separate management product to install. The control plane lives inside the CVM as a service called Acropolis. HA, Live Migration, scheduling, and VM lifecycle are all handled by Acropolis without any external coordinator. The result is operationally simpler. It is also genuinely different from what you are used to.

Core Content

What AHV Actually Is

AHV is a Type-1 hypervisor based on KVM (Kernel-based Virtual Machine) with QEMU as the device emulator and libvirt for management primitives. It is bundled into every Nutanix cluster. It is free in the sense that there is no separate AHV license; the cost is part of the AOS (now NCI) subscription.

Read carefully: KVM is a Linux kernel module that turns Linux into a hypervisor. QEMU is the user-space process that emulates devices for guest VMs. libvirt is a management API. AHV is what Nutanix built on top of those open-source pieces: a hardened, opinionated, enterprise-managed hypervisor with the upstream complexity hidden behind Prism and Acropolis.

The lineage matters because customers will ask. The honest framing: "AHV is to KVM what RHEL is to upstream Linux. Nutanix took the open-source kernel-mode hypervisor that Red Hat, IBM, AWS, and Google all use in some form, hardened it for enterprise HCI, integrated it with the rest of the platform, and made it manageable for people who don't want to think about KVM internals."

Acropolis: The Service That Replaces vCenter (For AHV)

This is the architectural insight that changes everything for a VMware admin.

In the VMware world, vCenter is a separate appliance running an entire management stack. It is software you deploy, patch, license, and protect. If vCenter fails, your hosts keep running, but DRS does not work without vCenter; vMotion does not work without vCenter.

AHV does not have a vCenter. The control-plane responsibilities (VM lifecycle, HA, scheduling, Live Migration, host management) are handled by a service called Acropolis, which runs inside every CVM. One Acropolis instance is elected master at any time; the others are followers, ready to take over if the master CVM is lost. The election uses the Zeus / ZooKeeper consensus mechanism we covered in Module 2.

This means three things:

1. There is no external management appliance to deploy. AHV is functionally complete out of the box.
2. HA, Live Migration, scheduling, and VM lifecycle have no external dependency. They survive the loss of any single CVM (or even multiple) because Acropolis is replicated across CVMs.
3. The management surface lives at Prism Element (per-cluster) and Prism Central (multi-cluster). Module 4 goes deep on Prism. For now, treat Prism as the AHV equivalent of the vSphere Web Client, with Acropolis underneath as the equivalent of vCenter Server.

Diagram: AHV Stack vs ESXi Stack

The Cycle, Frame Two: AHV as the Hypervisor Without a Tax

In the ESXi world, you pay for the hypervisor (now subscription-only post-Broadcom) and you pay for vCenter (bundled into the same subscription, but it is its own deployment). Broadcom-era pricing depends heavily on which SKU. vSphere Foundation (vSphere + vCenter + HA / DRS / vMotion) is roughly $190 per core per year MSRP as of 2026 (partner quotes often land at $195+). VMware Cloud Foundation (VCF), the higher-tier SDDC stack including vSAN, NSX, and Aria, is roughly $350 per core per year (down from the $700 announced at the start of the Broadcom transition). Both SKUs require a 16-core minimum per CPU, and Broadcom has a 72-core minimum order for new subscriptions.

For a typical 4-node cluster with 64 cores per node (256 cores cluster-wide), vSphere Foundation lands at roughly $48,000 per year and VCF lands at roughly $90,000 per year, before add-ons, support uplift, or discount. Customers on the original $700/core VCF tier are paying close to $180,000 a year on the same cluster. Always confirm the customer's specific SKU before quoting numbers.

AHV's hypervisor license is bundled into the NCI subscription (formerly AOS). Functionally, the hypervisor is free. The customer pays for NCI, which they would pay for anyway if they buy Nutanix. The hypervisor cost line on the BOM goes to zero.

The Cycle, Frame Three: AHV as KVM Hardened for HCI

For a customer with a Linux-savvy team, the technical lineage matters. AHV is not a science project. KVM is the kernel virtualization layer in Red Hat OpenStack, AWS Nitro (in part), Google Compute Engine (KVM-derived), Oracle Cloud, and many others. It is one of the two hypervisors (alongside ESXi and Hyper-V, three if you count Xen's diminishing presence) that powers production at hyperscale.

What Nutanix added: hardening (security profiles, restricted access, controlled package set), opinionation (one supported configuration per AOS version, no manual KVM tuning), enterprise management (Prism, Acropolis, NGT, NCC integration), and the integration with DSF that makes AHV's snapshot, replication, and DR experience genuinely better than running stock KVM with external storage.

The Cycle, Frame Four: AHV as One Less Thing to Manage

For an operations leader, the durable AHV pitch is not lower licensing or KVM lineage. It is: one less management product to deploy, patch, license, protect, and integrate.

vCenter is software your team manages. It has a database. It has its own upgrade cadence. It has a backup story. It has its own HA story (vCenter HA, which is its own thing). It has a Tomcat instance and a Postgres database and an LDAP integration and a certificate refresh cycle. None of this is hard, individually. All of it adds up to a thing your team owns.

AHV does not have any of that. The Acropolis service auto-starts on every CVM. The master election is automatic. There is no database to back up because state lives in Cassandra and Zeus. The customer does not get a free hypervisor; the customer gets a hypervisor that does not require a parallel management infrastructure.

Live Migration (the vMotion Equivalent)

AHV's Live Migration is functionally equivalent to vMotion. It moves a running VM from one host to another with sub-second user-visible disruption. The mechanism is the same kind of memory-copy plus iterative dirty-page tracking that vMotion uses, with a final stun-and-switch when the dirty rate is low enough.

What it does:

• Live migration of running VMs between hosts in the same cluster.
• No interruption visible to the guest OS or the application (for typical workloads).
• Storage stays in DSF; only memory and execution state move.

What it does not do:

• Cross-cluster live migration. (For this, you use Nutanix Move, which is async, not live.)
• Cross-hypervisor live migration. (You cannot live-migrate from ESXi to AHV; you migrate VMs cold or use Move.)

HA in AHV (No vCenter Required)

When a node fails in an AHV cluster, here is what happens:

1. The remaining CVMs detect the loss via cluster heartbeat (Zeus / Cassandra mechanisms).
2. Acropolis (the master, on a surviving CVM) inventories the VMs that were on the failed node.
3. Acropolis selects target hosts for those VMs based on resource availability and any affinity rules in effect.
4. The VMs are restarted on surviving hosts.

End to end this is on the order of 30-90 seconds, similar to vSphere HA. The key difference: there is no vCenter dependency. AHV does not have this dependency because the equivalent of vCenter (Acropolis) lives in the surviving cluster.

ADS: The DRS Equivalent

ADS (Acropolis Dynamic Scheduling, sometimes written as the Acropolis Dynamic Scheduler) is the AHV equivalent of vSphere DRS. It periodically rebalances VMs across hosts to address resource pressure. The internal service that runs this is called Lazan; you will see the name in logs and acli output.

ADS is genuinely simpler than DRS. DRS has decades of tuning for aggressive placement, pre-emptive load balancing, and granular policy options. ADS does the practical 80% of what DRS does with a fraction of the configuration surface. Specifically:

• ADS runs every 15 minutes by default and evaluates host CPU and memory pressure.
• When pressure exceeds thresholds, ADS recommends or executes Live Migrations to rebalance.
• VM-host affinity, VM-VM affinity, and anti-affinity rules are honored.
• ADS does not micromanage at the granularity DRS does; it acts on persistent pressure, not transient spikes.

Diagram: Acropolis Control Plane

Snapshots: The Genuine AHV Win

Here is where AHV (in fact, AOS, since it works on ESXi-on-Nutanix too) has a real advantage: snapshots are native to DSF, not the hypervisor.

In the ESXi world, a VM snapshot creates a delta vmdk. The hypervisor redirects writes to the delta. Read performance can degrade as the snapshot tree grows. Removing a snapshot triggers a consolidation operation that can be slow and can actually pause I/O for noticeable periods on large VMs. Anyone who has accidentally run with a months-old snapshot on a database VM has felt this pain.

In Nutanix, snapshots are a DSF operation. They are:

• Instant. Snapshot creation takes milliseconds, regardless of VM size.
• Space-efficient. DSF uses redirect-on-write with metadata pointers; the snapshot consumes only the changed blocks.
• No I/O penalty. Reads and writes to the active VM continue at native speed; the snapshot is a metadata reference, not a delta file in the VM's I/O path.
• Consolidation-free. Removing a snapshot is a metadata operation. No multi-hour consolidation that pauses your VM.

Console Access and NGT

NGT (Nutanix Guest Tools) is the analog of VMware Tools. It provides:

• Time synchronization between host and guest
• IP address detection and reporting (so Prism shows guest IPs)
• VirtIO drivers for paravirtualized I/O (storage, network)
• VSS-aware snapshots for Windows (application-consistent snapshots)
• File-Level Recovery (FLR) for guest file recovery from a Nutanix snapshot
• Self-service file restore utilities

NGT is required for VSS-consistent snapshots on Windows guests, for accurate IP reporting in Prism, and for FLR. Install it on every production VM as a matter of course.

What AHV Genuinely Lacks (The Honest Gap List)

Read this twice. As a BlueAlly SA, naming the gap honestly is what wins customer trust.

1. FT (Fault Tolerance, lockstep CPU mirroring). No equivalent in AHV. If a customer has a workload that requires lockstep failover, that workload stays on ESXi.
2. Mature third-party ISV ecosystem. ESXi has 20+ years of ISV support. AHV's ecosystem is meaningful and growing (Veeam, Commvault, Rubrik, HYCU, Cohesity, others all support AHV; major monitoring tools support AHV via APIs), but ESXi is broader. Specific niche ISVs may not yet certify AHV. Always check.
3. Some advanced networking features that NSX-T provides on ESXi. Distributed firewall sophistication, advanced routing patterns, gateway services. Module 6 covers this in detail.
4. DRS-level scheduling sophistication. ADS does the practical work; it does not match DRS's tuning surface.
5. vSphere with Tanzu / native Kubernetes integration in the way VMware ships it. AHV has NKE (Nutanix Kubernetes Engine, branded "Kubernetes Management" in current PC versions), which is genuinely good, but it is a different product with a different operational model.
6. Hot-add CPU and memory limits. AHV supports hot-add but with tighter limits than ESXi in some scenarios. Check current AOS version specifics.
7. Console UX parity with VMRC. Prism's in-browser VNC console is functional but not as feature-rich as the VMware Remote Console.

What AHV Has That ESXi Does Not

1. No separate hypervisor licensing line item. Bundled with NCI.
2. No vCenter dependency. Acropolis lives in the cluster.
3. DSF-native snapshots. Instant, space-efficient, no I/O penalty, no consolidation.
4. One-click rolling upgrades via LCM. AOS, AHV, BIOS, BMC, NIC firmware, drive firmware in one orchestrated workflow.
5. Tight integration with Nutanix DR (Recovery Plans, NearSync, Metro). Module 7 goes deep.
6. Open Virtual Switch (OVS) underneath networking. Module 6 covers this; for SDN-friendly customers, OVS is a meaningful technical asset.
7. Single API surface (Nutanix v4). No need to glue together vSphere API + array API + network API. Automation is genuinely simpler.

The Mixed-Hypervisor Reality (Read This Carefully)

This is the section that wins more BlueAlly deals than any feature comparison.

The customer does not have to choose AHV or ESXi. They can run both. Specifically:

• ESXi on Nutanix is a fully supported, common deployment pattern. The customer keeps vCenter, keeps ESXi, keeps every piece of their VMware tooling, and gets the HCI platform benefits underneath. They still pay VMware for vSphere licensing.
• AHV on Nutanix is the alternative. Same hardware, different hypervisor, no VMware bill.
• Mixed clusters within a single Prism Central are supported. You can have an ESXi cluster and an AHV cluster, both Nutanix, both managed from the same Prism Central.
• Migration from ESXi to AHV is a controlled process using Nutanix Move (free tool). Module 10 walks the migration end to end.

The most common 2026 deal pattern at BlueAlly is not "switch from ESXi to AHV." It is:

1. Deploy Nutanix with ESXi on it. Customer keeps everything they know.
2. Get HCI benefits immediately (snapshots, DR, scale-out, lifecycle management).
3. Over 12-36 months, drift workloads to AHV at the customer's pace, starting with low-risk workloads (dev/test, monitoring, file/print, internal apps).
4. Maybe converge fully to AHV. Maybe stay mixed forever. Either is fine.

Diagram: Mixed-Hypervisor Cluster Topology

Nutanix Move: The Migration Tool

Move is Nutanix's free VM migration tool. It is delivered as a small VM you deploy on your Nutanix cluster. It supports migration from:

• VMware ESXi (most common)
• Microsoft Hyper-V
• AWS EC2
• Microsoft Azure
• Google Cloud Platform
• Other Nutanix clusters

The Move workflow:

1. Deploy Move (download an OVA / qcow2; run it on your Nutanix cluster).
2. Add source environment (e.g., point Move at your vCenter and provide credentials).
3. Add target (your Nutanix cluster's Prism Element or Central).
4. Create a migration plan: select VMs, set network mappings, set scheduling.
5. Run the plan. Move performs the bulk of the data copy while the VM continues running on the source (using CBT-equivalent change tracking).
6. At the cutover, the VM is briefly powered off, the final delta is copied, drivers are swapped (VMware Tools out, NGT in), and the VM powers up on AHV.

Total downtime per VM is typically 5-15 minutes for the cutover. Bulk data copy happens in the background and can take hours per terabyte depending on network and source array performance.

Lab Exercise: Live Migration and a VM on AHV

Steps:

1. Log into Prism Element at https://<cluster-vip>:9440.
2. Navigate to VM > Create VM. Provision a small Linux VM (2 vCPU, 4 GB RAM, 20 GB disk on the default storage container, default network, boot from a Linux ISO).
3. Power on, install the OS, then power off. Take note of which physical host the VM landed on.
4. Power the VM back on. Note the host placement again.
5. Live Migrate the VM. Right-click the VM in Prism, choose "Migrate," select a different host. Watch the migration. Confirm the guest OS is unaffected.
6. Take a snapshot. Right-click VM > "Take Snapshot." Note that this is instant. Take three more in quick succession to build a snapshot tree.
7. Restore the VM from a snapshot. Note that this is also fast.
8. Open an SSH session to the cluster (ssh nutanix@<any-cvm-ip>). Run acli vm.list to see all VMs from the CLI. Run acli vm.get lab-vm-01 to see detailed VM properties.
9. Optional: simulate a host failure. If you have a non-production cluster, you can power off the host running your VM. Watch HA restart the VM on a surviving host.
10. Check Acropolis master. Run acli interactive mode and look at cluster state.

What You Now Have

You can now explain AHV to a VMware admin in 60 seconds without sounding defensive. You know it is KVM-based, with QEMU and libvirt and Open vSwitch underneath, and Acropolis as the Nutanix-specific control plane.

You have four mental frames for AHV: the hypervisor without a vCenter, the hypervisor without a tax, KVM hardened for HCI, and one less management product to maintain. When a customer pushes from any of those angles, you have a frame ready.

You know what AHV genuinely lacks: FT, mature niche-ISV ecosystem in some categories, DRS-level scheduling sophistication, console UX parity in heavy desktop scenarios. You can name those gaps without flinching.

You know the mixed-hypervisor story cold: they don't have to switch hypervisors to get the platform benefits. That sentence wins meetings.

You know the Broadcom math: vSphere Foundation ~$190/core, VCF ~$350/core, 16-core CPU minimum, 72-core order minimum. AHV bundles into NCI; that line goes to zero.

You are now ready for the management plane. AHV's control plane lives inside the cluster (Acropolis), but the user-facing experience lives in Prism Element and Prism Central. Module 4 makes that concrete.