6.1 AHV VM Provisioning, Resource Allocation (vCPU, vRAM, Disks), and Boot Types

AHV VM Provisioning, Resource Allocation (vCPU, vRAM, Disks), and Boot Types

Quick Summary: Nutanix AHV is an enterprise-ready, kernel-based hypervisor natively integrated into the Nutanix Acropolis Operating System (AOS). Unlike legacy three-tier virtualization platforms that require external hypervisor management servers and complex storage fabric zoning, AHV streamlines VM provisioning directly through Prism Element and Prism Central. AHV enforces a deterministic resource allocation model—pinning 100% of allocated virtual RAM without hypervisor swapping or ballooning—and provides multi-queue VirtIO-SCSI virtual disk controllers, flexible Legacy BIOS and UEFI Secure Boot firmware modes, and clientless HTML5 VNC console streaming over TCP port 9440.

---

1. AHV Virtualization Architecture and Provisioning Interfaces

Nutanix AHV transforms traditional hypervisor operations by eliminating the "hypervisor tax"—both in licensing expense and architectural complexity. Traditional virtualization stacks deploy separate compute clusters, dedicated storage area networks (SAN/NAS), fabric switches, and external management software (such as VMware vCenter Server or Microsoft System Center Virtual Machine Manager). In contrast, AHV is an out-of-the-box component of the Nutanix enterprise cloud OS, running bare-metal on each cluster node alongside the Controller Virtual Machine (CVM).

Administrators provision and manage AHV virtual machines through two primary operational interfaces:

1. Prism Element (PE): The localized cluster management engine running distributed across the CVMs on TCP port 9440. Provisioning a VM in Prism Element directly targets the local physical nodes, local virtual networks (managed/unmanaged bridges), and localized Distributed Storage Fabric (DSF) storage containers.
2. Prism Central (PC): The centralized multi-cluster governance platform. VM provisioning in Prism Central enables multi-cluster workload placement, RBAC-governed self-service provisioning, category tagging (e.g., Environment: Production, AppTier: Database), and seamless integration with Nutanix Cloud Manager (NCM) automation playbooks.

+-------------------------------------------------------------------------+
|                        Prism Management Layer                           |
|    Prism Element (Local Cluster)  <--->  Prism Central (Multi-Cluster)  |
+------------------------------------+------------------------------------+
                                     |
                                     v (REST API / libvirt)
+------------------------------------+------------------------------------+
|                           Nutanix AHV                                   |
|   +-------------------+  +-------------------+  +-------------------+   |
|   |    vCPU Engine    |  |   Memory Subsystem|  |   Storage Engine  |   |
|   | (Sockets x Cores) |  | (100% Reserved)   |  |   (VirtIO-SCSI)   |   |
|   +-------------------+  +-------------------+  +-------------------+   |
+------------------------------------+------------------------------------+
                                     |
                                     v (vDisk Redirect-on-Write)
+------------------------------------+------------------------------------+
|               Distributed Storage Fabric (DSF) Container                |
+-------------------------------------------------------------------------+

During virtual machine creation, Prism interacts with Acropolis—the distributed management fabric within AOS. Acropolis manages task execution, state consensus through ZooKeeper, and hypervisor coordination via an optimized libvirt interface. Because AHV hypervisors speak directly to the local CVM via internal loopback interfaces, provisioning operations execute in milliseconds without external network bottlenecks.

---

2. Compute Allocation: vCPU Sockets, Cores, and NUMA Topology

Compute sizing in AHV requires understanding how virtual CPUs (vCPUs) map to physical processor hardware. In Prism, compute is configured through two primary parameters:

$\text{Total Virtual CPUs (vCPUs)} = \text{Number of Sockets} \times \text{Cores per Socket}$

While the total number of compute threads exposed to the guest operating system equals the product of these two values, how administrators divide sockets and cores carries profound implications for guest operating system licensing and hardware Non-Uniform Memory Access (NUMA) performance.

OS Licensing and Sockets vs. Cores

Many enterprise software vendors license products based on socket counts rather than physical cores:

• Client Operating Systems: Consumer and desktop operating systems such as Microsoft Windows 10 and Windows 11 Professional support a maximum of 2 physical sockets, regardless of core density. If an administrator assigns 4 sockets with 1 core each (totaling 4 vCPUs), Windows only detects the first 2 sockets (2 vCPUs), stranding 50% of the allocated compute power. The correct configuration is 1 socket with 4 cores per socket.
• Database Licensing: Certain database engines license per socket. Configuring fewer sockets with higher core counts ensures compliance while maximizing compute utilization.

NUMA Node Boundaries and Core Sizing

Modern server platforms utilize multi-socket architecture where physical RAM is split across CPU sockets (NUMA nodes). Accessing memory attached to a local CPU socket incurs substantially lower latency than traversing the inter-socket bus (e.g., Intel Ultra Path Interconnect [UPI] or AMD Infinity Fabric) to access remote memory.

AHV is NUMA-aware. When assigning vCPUs and memory to high-performance workloads (such as Oracle Database or Microsoft SQL Server), administrators should design the VM's compute profile to fit within a single physical NUMA node whenever possible ("wide and shallow" vs. "narrow and deep"). If a VM requires more resources than a single physical socket provides, AHV automatically exposes a virtual NUMA (vNUMA) topology to the guest OS, enabling the guest scheduler to optimize thread-to-memory placement.

CPU Overcommit Guidelines

In virtualized environments, total allocated vCPUs across all running VMs frequently exceeds the total physical processor cores on the host:

• Physical Cores vs. Threads: Hyperthreading (SMT) doubles the logical execution threads on a physical processor. AHV presents these logical threads as available vCPUs.
• Recommended Overcommit Ratios:
  • Latency-Sensitive / Database Tier: 1:1 to 1.5:1 (vCPU to physical core ratio). Dedicated CPU scheduling prevents thread queuing and context switching overhead.
  • Standard General Purpose Server Workloads: 2:1 to 3:1.
  • VDI and Dev/Test Environments: Up to 4:1 or 5:1, where idle guest cycles permit dense consolidation.
• Risk of Excessive Overcommit (>6:1): Induces significant CPU Ready Time (%RDY), where guest operating system threads wait in hypervisor runqueues for available execution cycles, degrading response times.

---

3. Memory Allocation: Fixed-Size by Default, Overcommit on Request

AHV's memory model is the single most commonly misstated fact about the platform, and it changed materially in AOS 6.1. Learn both halves of it.

Default behaviour: fixed-size memory

Historically AHV VMs had a fixed memory size, and VMs are still created as fixed-size by default. When you build a VM with 32 GB of vRAM, AHV backs the full 32 GB with physical host memory for the life of the power-on. Nothing is reclaimed from the guest, nothing is swapped to disk, and if a host lacks enough unreserved physical RAM to satisfy the request, the VM will not start there. That default is what gives AHV its deterministic, jitter-free performance profile for production workloads.

AHV memory overcommit (AOS 6.1 and later)

Memory overcommit is available on AHV. It is:

• Opt-in and disabled by default. Overcommit is not a cluster-wide switch you inherit; a fixed-size VM stays fixed-size until you change it.
• Configured per VM. You enable or disable it on individual VMs from Prism, or from the command line. That means you can overcommit a subset of VMs on a cluster while leaving the rest pinned.
• Dependent on a guest balloon driver. For the feature to reclaim memory efficiently, a balloon driver must be installed inside each overcommitted guest. Without it, the hypervisor has no cooperative way to learn which guest pages are idle.
• Positioned for test, development, and density-driven workloads — environments where VM density matters more than guaranteed latency — rather than for latency-sensitive production databases.

[!WARNING] A common exam trap. Older Nutanix study material — and plenty of blog posts still online — states flatly that "AHV does not support memory overcommit or ballooning." That was true before AOS 6.1 and is false for AOS 7.5, the release NCA 7.5 is written against. The accurate statement is that AHV VMs are fixed-size by default and that overcommit is an optional, per-VM feature. Objective 4.4 references AHV Memory Overcommit directly when it asks you to recognize memory constraints from Prism metrics.

Sizing implications

Because the default is fixed-size, guest RAM sizing is a real capacity decision rather than something the hypervisor will quietly paper over:

1. Over-provisioning wastes physical RAM. A VM given 64 GB it never touches consumes 64 GB of cluster memory that no other fixed-size VM can use.
2. Under-provisioning pushes paging into the guest. The hypervisor will not rescue a guest that is short on memory; the guest OS starts paging to its own swap, which shows up as I/O load rather than as a memory alert.
3. Overcommit trades determinism for density. Enabling it on the right VMs raises consolidation ratios, but the memory a guest sees is no longer guaranteed to be resident, so latency becomes less predictable.

---

4. Virtual Disk Bus Architectures and Storage Attachment

Virtual disks in AHV are stored as native vDisks within Distributed Storage Fabric (DSF) storage containers. Rather than interacting with raw block LUNs, AHV virtual machines attach to vDisks through emulated or para-virtualized bus controllers.

+-------------------------------------------------------------------------+
|                        AHV Virtual Machine                              |
|  +-------------------------------------------------------------------+  |
|  |                     Guest Operating System                        |
|  +-------------------+-------------------+-------------------+-------+  |
|                      |                   |                   |          |
|                      v                   v                   v          |
|             [ VirtIO-SCSI Bus ]    [ IDE Bus ]         [ SATA Bus ]     |
|             (Multi-Queue, 256)     (Legacy, 4)         (AHCI, 6)        |
+----------------------+-------------------+-------------------+----------+
                       |                   |                   |
                       +-------------------+-------------------+
                                           |
                                           v (Local Unix Domain Socket / Stargate)
+-------------------------------------------------------------------------+
|                   Controller VM (Local Stargate Service)                |
|   Direct I/O processing via Distributed Storage Fabric (DSF)            |
+-------------------------------------------------------------------------+

AHV provides four distinct bus controller types, each tailored to specific operational requirements:

1. SCSI (VirtIO-SCSI) — Recommended Production Standard

• Architecture: Para-virtualized storage controller utilizing the open-standard virtio-scsi specification.
• Scalability: Supports up to 256 virtual disks per VM.
• Multi-Queue Support: AHV VirtIO-SCSI implements multi-queue storage processing. It establishes separate I/O queues mapped to individual vCPUs, completely bypassing single-lock bottlenecks and delivering hundreds of thousands of IOPS with sub-millisecond latency.
• Dynamic Resizing: Supports online disk expansion without requiring VM reboots or storage downtime.
• Driver Requirement: Native in modern Linux kernels; requires Nutanix VirtIO drivers for Windows.

2. IDE (Integrated Drive Electronics) — Legacy & CD-ROM

• Architecture: Emulated legacy ATA controller.
• Scalability: Strictly limited to 4 devices (Primary Master, Primary Slave, Secondary Master, Secondary Slave).
• Primary Purpose: Primarily utilized for attaching virtual CD-ROM drives (such as ISO installation media) or booting legacy operating systems that lack initial VirtIO driver integration.
• Performance: Substantially lower throughput and higher CPU overhead due to hardware emulation locks.

3. SATA (Serial ATA) — Compatibility Mode

• Architecture: Emulated AHCI SATA bus controller.
• Scalability: Supports up to 6 devices.
• Primary Purpose: Provides intermediate compatibility for modern operating systems that include native SATA/AHCI drivers out of the box but lack native VirtIO drivers during initial OS setup.

4. PCI (Peripheral Component Interconnect)

• Architecture: Direct attachment to the virtual PCI root complex.
• Scalability: Limited device attachment slots.
• Primary Purpose: Reserved for specialized direct-attached storage adapters, virtual hardware devices, and GPU pass-through attachments.

---

5. Boot Firmware Modes: Legacy BIOS vs. Modern UEFI and Secure Boot

When creating a virtual machine in Prism, administrators must specify the virtual firmware architecture: Legacy BIOS or UEFI (Unified Extensible Firmware Interface).

+-------------------------------------------------------------------------+
|                        Boot Firmware Architectures                      |
+------------------------------------+------------------------------------+
|            Legacy BIOS             |               UEFI                 |
+------------------------------------+------------------------------------+
| - 16-bit real mode initialization  | - 32-bit / 64-bit execution mode   |
| - Master Boot Record (MBR)         | - GUID Partition Table (GPT)       |
| - 2.2 TB boot disk limitation      | - Boot disks up to 9.4 ZB (ZettaB) |
| - No cryptographic validation      | - Cryptographic signature check    |
| - Legacy interrupt handling (INT)  | - Optional UEFI Secure Boot        |
+------------------------------------+------------------------------------+

Legacy BIOS Mode

Legacy BIOS emulates standard PC-AT firmware. It executes in 16-bit real mode and relies on the Master Boot Record (MBR) partition scheme:

• Capacity Ceiling: MBR partitions cannot address storage sectors beyond 2.2 TB. If an administrator boots a Legacy BIOS VM from a virtual disk larger than 2.2 TB, the remaining storage cannot be formatted as a boot volume.
• Security Posture: Legacy BIOS performs zero cryptographic verification of the operating system bootloader, leaving systems susceptible to bootkits and rootkits.

Modern UEFI Mode

UEFI represents the modern enterprise standard for firmware initialization. Executing in 32-bit or 64-bit protected mode, UEFI interfaces with the GUID Partition Table (GPT) scheme:

• Capacity Support: GPT supports boot storage volumes up to 9.4 Zettabytes ($9.4 \times 10^{21}$ bytes), completely removing partition size constraints.
• Fast Initialization: UEFI loads drivers and parallel hardware detection significantly faster than BIOS, accelerating VM boot times.

UEFI Secure Boot

Introduced natively in AOS 5.11 and AHV, Secure Boot is an extension of UEFI firmware that validates the cryptographic signatures of all loaded boot binaries (such as the Windows Boot Manager bootmgr.efi or Linux shim.efi/grub2.efi) against trusted digital certificates embedded in the virtual firmware.

• Malware Prevention: If a bootloader, kernel module, or hypervisor driver has been modified or infected by rootkits, the cryptographic handshake fails, and UEFI halts execution before the compromised code can run.
• Windows 11 and Windows Server 2022 Requirement: Microsoft strictly mandates UEFI Secure Boot alongside a virtual Trusted Platform Module (vTPM 2.0) for Windows 11 and advanced virtualization-based security (VBS) features in Windows Server 2022.

[!WARNING] The boot mode (Legacy BIOS vs. UEFI) must be chosen during VM creation. Converting a VM between BIOS and UEFI after operating system installation requires manual disk partition conversion (MBR to GPT via tools like mbr2gpt.exe) and bootloader reinstallation; otherwise, the guest OS will fail to locate its bootloader and crash with an unbootable device error.

---

6. VM Console Management and Power Operations Lifecycle

Managing virtual machines throughout their lifecycle requires robust console interaction and reliable power control mechanisms.

Clientless HTML5 Console Architecture

Traditional virtualization platforms historically required client-side browser plugins, external heavy client installations, or Java runtime environments to open a virtual machine remote console. Nutanix AHV eliminates all client dependencies through an integrated HTML5 VNC/WebSocket Console:

• Transport Security: When an administrator clicks Launch Console in Prism Element or Prism Central, a secure WebSocket connection is established over HTTPS TCP port 9440 to the active Prism Leader CVM.
• No Plugins: The CVM proxies console display buffers directly from the hypervisor's native VNC/SPICE server into the administrator's modern web browser.
• Capabilities: Supports clipboard synchronization, remote key combinations (Ctrl+Alt+Del), multi-language keyboard layouts, and full administrative access during pre-boot firmware stages (BIOS/UEFI setup).

Virtual Machine Power Operations

Prism exposes distinct power actions, categorized into graceful guest operations and hard hypervisor-enforced state changes:

+-------------------------------------------------------------------------+
|                     AHV VM Power Operations Matrix                      |
+-------------------+-----------------------+-----------------------------+
| Power Action      | Mechanism             | Operational Impact          |
+-------------------+-----------------------+-----------------------------+
| Power On          | Hypervisor scheduling | Allocates RAM, spawns QEMU  |
| Power Off         | Immediate termination | Hard pull of power cable    |
| Guest Shutdown    | ACPI / NGT signal     | Graceful OS service stop    |
| Reset             | Immediate cold reset  | Hard hardware reset button  |
| Guest Reboot      | ACPI / NGT signal     | Graceful OS restart         |
| Suspend / Resume  | Memory state save     | Flushes execution to disk   |
+-------------------+-----------------------+-----------------------------+

1. Power On: The Acropolis dynamic scheduler locates a host with sufficient unreserved memory, allocates physical CPU threads, pins 100% of guest vRAM, attaches DSF vDisks, and launches the QEMU/KVM execution thread.
2. Power Off (Hard Stop): The hypervisor immediately kills the VM's execution process. Equivalent to pulling the physical power cord. Use strictly when a guest operating system is totally unresponsive, as unwritten memory buffers will be lost.
3. Guest Shutdown (Graceful): Acropolis sends an ACPI shutdown signal (or communicates via Nutanix Guest Tools) to the guest operating system. The OS notifies running applications, flushes filesystem caches to storage, stops background services, and cleanly powers off.
4. Reset (Hard Reset): Instantly terminates CPU execution and restarts the VM from firmware initialization without flushing disks.
5. Guest Reboot (Graceful): Sends an ACPI restart command instructing the guest OS to reboot cleanly.