Migrating SQL Server from VMware to Nutanix AHV: NUMA, Storage, and the Core-Licensing Trap

Broadcom’s licensing changes to VMware since the 2023 acquisition have pushed a steady wave of organizations to evaluate Nutanix AHV as the replacement hypervisor. Nutanix’s own migration tooling, Nutanix Move, has matured specifically to support that wave, including an in-place cluster conversion path that avoids a hardware swing kit entirely.

Most of what gets written about this migration is infrastructure-focused: assess the VMs, run Move, cut over, done. That framing skips the parts that matter specifically for SQL Server: AHV configures CPU and NUMA differently from ESXi, storage has two distinct paths with different performance histories, Always On Availability Groups do not move the way a stateless application VM does, and the SQL Server per-core licensing math does not simplify just because the new hypervisor has no separate licensing cost of its own.

1Why This Migration Is Happening Now

The driver is almost always licensing and cost, not a technical dissatisfaction with vSphere. Broadcom’s post-acquisition changes to VMware licensing, including the shift toward subscription bundles and the retirement of perpetual licensing options, have made a three to five year cost projection on VMware look materially worse than it did before the acquisition for a large share of enterprise customers. AHV ships as part of the Nutanix Cloud Platform with no separate hypervisor licensing line item, which is the core of the financial argument driving these projects.

Nutanix Move is the primary migration tool, following a seed, sync, and cutover model that minimizes downtime by pre-seeding data and performing delta syncs before the final cutover. A 2026 addition, in-place cluster conversion, allows a cluster already running ESXi on Nutanix-supplied hardware to convert directly to AHV without requiring a separate swing kit, which changes the economics and timeline of the migration for organizations already on Nutanix-branded hardware running VMware as the hypervisor.

2AHV vs ESXi: The Architecture Difference That Matters

AHV is not a drop-in hypervisor swap. It is Nutanix’s own KVM-based hypervisor, built into the Nutanix Cloud Platform rather than layered on top of it. Every Nutanix node runs a Controller VM, which owns storage services for that node and participates in the Distributed Storage Fabric that pools storage across the cluster. That CVM has its own CPU and memory footprint on every host and, per Nutanix’s own guidance, should be pinned to a specific NUMA node so it does not cross NUMA boundaries for its own operations.

Practically, this means capacity planning for an AHV cluster is not identical to capacity planning for an ESXi cluster with the same physical hardware. Some CPU and memory on every node is committed to the CVM before any SQL Server VM is placed.

3vCPU and Core Configuration: A Different Model, Not Just Different Names

In AHV terminology, a vCPU corresponds to a virtual socket, and cores per vCPU corresponds to the number of cores on that socket, similar in concept to ESXi’s socket and core-per-socket settings but governed by different rules in practice.

Two rules matter immediately for anyone used to ESXi:

• Nutanix’s own guidance is to increase the number of vCPUs (sockets) before increasing cores per vCPU, up to the physical core count of the host, rather than defaulting to a single large socket.
• CPU hot-add is not supported on AHV at all. Changing either the vCPU count or the cores-per-vCPU value on an existing VM requires powering the VM off first. There is no equivalent to the ESXi CPU hot-add feature, which itself carries the separate, well-documented tradeoff of disabling vNUMA when enabled.

The operational consequence: a SQL Server VM’s CPU allocation on AHV has to be right the first time, or at minimum, resized during a planned maintenance window. There is no live adjustment path to fall back on if the initial sizing estimate turns out wrong.

4NUMA Sizing on AHV

The core NUMA principle carries over directly from any virtualization platform: a VM that fits within a single physical NUMA node avoids the latency penalty of crossing to remote memory. Nutanix’s own best practices guidance states the objective plainly, keep regular VMs within the size of one AHV host NUMA node whenever possible.

Two AHV-specific details affect how that target gets hit. First, maximum single-VM sizing should be planned against physical core count, not hyperthreaded logical core count. Configuring a VM with more vCPU cores than physical cores available on the host is explicitly called out as a configuration that can cause significant performance problems. Second, because the CVM is pinned to a NUMA node on every host, the usable NUMA capacity for guest VMs on that node is the physical node capacity minus whatever the CVM has claimed, not the full physical node.

SQL Server is itself NUMA-aware, so a VM correctly sized to fit inside one NUMA node lets the SQL Server engine’s own NUMA-aware scheduling and memory allocation work as designed rather than fighting a virtualization layer that is already spanning nodes.

5Storage: Native vDisks vs. Volume Groups

Nutanix presents two distinct storage paths for a SQL Server VM’s disks: native vDisks, which are the default disk type attached directly to an AHV VM, and Nutanix Volume Groups, which are presented as iSCSI-attached shared storage that can be mounted independently of a specific VM.

Native vDisks were historically more constrained for high-throughput database workloads than they are today. Starting with the Autonomous Extent Store introduced in AOS 6.x, local sharding for native vDisks improved meaningfully, closing much of the gap that previously pushed some database deployments toward Volume Groups by default. Any guidance encountered that predates AOS 6.x, including some still-circulating best practice documents, should be reverified against current AOS documentation rather than assumed to still apply, since this is exactly the kind of default behavior that changed quietly between major releases.

For the disk type itself, Nutanix’s guidance for AHV VMs is to use the SCSI disk type for all VM disks, which differs from the ESXi pattern of pairing an LSI SAS controller for the boot disk with a PVSCSI controller for data disks. AHV does not carry that same controller-choice decision.

6The Licensing Trap: The Word Changes, the Core Count Math Does Not

This is the gap most migration plans miss entirely, because it sits between two teams that rarely talk to each other during a hypervisor migration: infrastructure, which is focused on compute and storage sizing, and software asset management, which is focused on the licensing entitlement.

Microsoft’s own core-based licensing guidance is unambiguous on the mechanism: a core license is required for each virtual core, defined for licensing purposes as a virtual core, virtual CPU, or virtual thread assigned to the VM, with a minimum of four core licenses required per virtual machine. If a virtual core maps to more than one hardware thread, each hardware thread it maps to must be licensed. None of that changes based on which hypervisor is running underneath.

What does change is the terminology collision. On AHV, the word vCPU means a virtual socket, and the total core count presented to the guest OS is vCPUs multiplied by cores per vCPU. On ESXi, the same math applies but is usually expressed differently in the UI, and many DBAs mentally shortcut “vCPU count” to mean “licensable core count” out of habit from years of ESXi-only environments. Carrying that shortcut into an AHV sizing conversation risks licensing the wrong number, in either direction, particularly during a rightsizing exercise where a VM’s vCPU-and-cores-per-vCPU combination changes from what it was on the source ESXi host.

The practical fix is procedural, not technical: whenever a SQL Server VM’s compute configuration changes as part of this migration, recalculate the licensable virtual core count directly from the new vCPU times cores-per-vCPU value, do not carry over the prior ESXi-side license count, and confirm the result still clears the four-core-per-VM minimum before finalizing the sizing. The SQLYARD licensing guide covers the four-core minimum and core-pack purchasing mechanics in full detail.

7Migrating Always On Availability Groups to AHV

An Always On Availability Group does not migrate as a single moving VM the way a stateless application server does. The documented pattern for this specific scenario is to build a new SQL Server VM on AHV, join it to the existing Windows Server Failover Cluster, and add it to the Availability Group as a new secondary replica, then fail over once the new replica is synchronized and remove the old ESXi-hosted replica from the topology.

This is slower than a bulk VM migration through Nutanix Move, but it is the lower-risk path for a database that cannot tolerate an unplanned failover mid-migration. It also means AG migrations should be planned and scheduled separately from the general VM migration wave rather than swept into the same batch as stateless workloads, since the AG replica-by-replica approach does not compress to the same timeline as a Move-driven seed-sync-cutover for ordinary VMs.

Storage path selection matters here too. Because Volume Groups can be presented independently of a specific VM, some environments use them specifically for AG data and log volumes to simplify the storage side of a future replica rebuild, though this is an environment-specific design decision rather than a universal recommendation.

8Networking: One Adapter Type, Fewer Decisions

ESXi requires a choice between adapter types for SQL Server VMs, with VMXNET3 generally recommended over the older E1000 for performance reasons. AHV removes that decision: there is a single virtual NIC type available for AHV VMs, so there is no adapter-type comparison to make during the migration. This is a genuine simplification, not a hidden tradeoff, but it is worth confirming during migration planning so nobody spends time researching a decision that does not exist on the target platform.

9A Pre-Migration Checklist for DBAs

• Confirm the target vCPU and cores-per-vCPU combination for each SQL Server VM against the host’s physical NUMA node size, not just against the source VM’s current ESXi vCPU count.
• Recalculate SQL Server core licenses directly from the new vCPU times cores-per-vCPU value on AHV; do not copy the ESXi-side license count forward.
• Decide native vDisks versus Volume Groups per workload, and confirm the decision against current AOS documentation rather than legacy pre-AOS-6.x guidance.
• Schedule Always On Availability Group migrations separately from bulk stateless VM migrations, using the build-join-failover pattern rather than a direct VM move.
• Confirm CVM placement and NUMA pinning on target hosts before finalizing per-VM sizing, since CVM overhead reduces usable NUMA capacity on every node.
• Verify there is no remaining dependency on ESXi-specific tooling, including VMware Tools-based monitoring or backup integrations, before decommissioning the source environment.

10Should the DBA Drive This Migration or Just Advise It

The recommendation: the DBA should own the SQL Server-specific sizing, storage path, and licensing recalculation, while infrastructure owns the Nutanix Move mechanics and cluster conversion. Handing the entire migration to an infrastructure team without a DBA checkpoint on vCPU-to-core mapping and licensing is the single most common way this project quietly overspends or undersizes a production database server, since neither of those numbers is visible from the infrastructure team’s side of the migration plan alone.

References

• Microsoft Docs: Core-Based Licensing Models Licensing Guidance (microsoft.com/licensing)
• Nutanix Docs: AHV Best Practices Guide (BP-2029)
• Nutanix Docs: Microsoft SQL Server on Nutanix Best Practices (BP-2015)
• Nutanix: Supercharge Your VM Migrations to Nutanix AHV with Nutanix Move (Nutanix Blog, 2026)
• Community and Industry Sources: Migrating Virtualized Workloads to Nutanix AHV, a Phased Approach That Works in Production (ePlus, 2026)
• SQLYARD: Best Practices for Running SQL Server on VMware vSphere and vCenter, Part 1: CPU and NUMA
• SQLYARD: Best Practices for Running SQL Server on VMware vSphere and vCenter, Part 2: Storage, Memory, and Instance Configuration
• SQLYARD: SQL Server Always On Availability Groups: The Complete DBA Guide
• SQLYARD: SQL Server Pricing and Licensing Guide 2026

All technical content on SQLYARD is verified against Microsoft documentation at the time of publication. SQL Server features, cloud service capabilities, licensing terms, and configuration requirements can change between versions and cumulative updates. Always validate against current Microsoft Learn documentation before deploying to production. Nutanix-specific guidance in this article reflects AOS 6.x and later; environments on earlier AOS versions should reverify storage and NUMA behavior against Nutanix’s current documentation before relying on it.