SQL Server on VMware: Licensing the Host, the VM or the Cluster
Licensing a virtualized host is only possible under Enterprise Edition, and that one rule decides most of what follows. A SQL Server estate on VMware can be licensed at the host, at the VM, or at the cluster, and each choice moves the entitlement in a different direction: host licensing covers every VM on it but only under Enterprise, VM-level licensing is cheaper per instance but caps out fast as VMs multiply, and cluster-wide coverage is the only way to survive vMotion without breaking the 90-day reassignment rule.
This is a guide to picking correctly, and to the one benefit, Software Assurance, that decides whether any of the three options actually work in a live vSphere environment.
The three ways to license SQL Server on VMware
- Per VM (Standard or Enterprise). License the virtual machine at its allocated vCPUs, four-core minimum per VM, same as licensing a physical server that size. Cheapest when a host runs few, well-defined SQL VMs and does not oversubscribe cores.
- Per host, Enterprise Edition only. License every physical core on the host, and every VM on that host can run unlimited SQL Server instances, Standard or Enterprise, without counting them individually. This is the only route to unlimited virtualization density, and Standard Edition cannot do it: host-level licensing is an Enterprise-only right.
- Per cluster, with License Mobility. Neither VM-level nor host-level licensing, on their own, survives a VM moving between hosts more than once every 90 days. A cluster running vMotion, DRS, or HA needs License Mobility, a Software Assurance benefit, to move the license with the workload without triggering a new licensing event on every host it lands on.
The 90-day rule, and why it breaks most clusters
Without License Mobility, a SQL Server license reassignment (moving it from one server to another) is allowed no more often than once every 90 days. That rule was written for a world of static server assignments; it does not survive contact with a modern vSphere cluster. DRS rebalances VMs across hosts automatically, HA restarts a failed VM on a different host without asking, and vMotion moves a running VM live. Any of the three can reassign a SQL Server license to a new physical host inside the same day, and without License Mobility that reassignment is not a technicality, it is a compliance event.
License Mobility is a benefit of active Software Assurance (or the equivalent subscription coverage that ships by default with SQL Server 2022 and 2025's subscription model). With it active, licenses can move within a server farm, and to authorized outside vendors' infrastructure, as often as the estate actually moves them. Without it, a license bought for a perpetual VM is legally tied to the physical host it was assigned to, and every automated migration the cluster performs is, on paper, an unlicensed one until someone catches up the paperwork.
Picking the right level
| Estate shape | Best fit | Why |
|---|---|---|
| One or two SQL VMs on a shared host, static placement | Per VM, Standard or Enterprise | Cheapest; no host-wide Enterprise cost for a light SQL footprint |
| A dedicated SQL host, many instances, high VM density | Per host, Enterprise | Unlimited virtualization on that host beats per-VM math past a handful of instances |
| Any cluster with DRS, HA, or vMotion enabled | Either level, plus License Mobility | The 90-day rule otherwise breaks on the first automated migration |
| Mixed estate, some static VMs, some in a moving cluster | Split: per-VM on the static hosts, host-level with Mobility on the cluster | Paying for host-wide Enterprise on a host with one static VM wastes the licence |
Where positions actually go wrong
- Host-level licensing bought at Standard. Standard cannot license a host; it is an Enterprise-only right. A host licensed at Standard core counts is a VM-level position, whatever the intent was.
- DRS or vMotion enabled without checking Software Assurance status. The feature that makes the cluster convenient is exactly the feature that requires License Mobility to stay compliant.
- Counting vCPUs instead of the host's physical cores. Host-level Enterprise licensing is priced on the physical core count of the host, not on how many vCPUs are allocated across its VMs.
- Assuming the subscription model changes the mechanics. SQL Server 2022 and 2025's subscription licensing includes Software Assurance benefits by default, which is why License Mobility is less of a trap on new subscription deployments, but the underlying per-core and per-host rules, and the four-core VM minimum, are unchanged.
The decision between VM-level and host-level licensing is, underneath the Microsoft terms, a question about the platform: the same distinction that decides Oracle's per-VM versus per-cluster exposure shows up here as Standard versus host-wide Enterprise, and the same discipline, knowing the physical core count and cluster membership of every host, not just the VMs running on it, is what a defensible position needs on either vendor.
That host and cluster data is exactly what Microsoft Deployment Manager reconciles against SQL Server's licensing rules: which hosts are licensed at which level, whether Software Assurance and License Mobility are active where DRS or vMotion are enabled, and whether a VM's allocation still adds up to the four-core minimum. Built from the inventory you already collect, not a fresh audit of every host in the cluster.
Checklist
- Every SQL Server VM's licensing level (VM or host) matched to its actual placement, not the original design.
- Every host running host-level licensing confirmed at Enterprise Edition, priced on physical cores.
- DRS, HA, and vMotion status checked against active Software Assurance and License Mobility on every cluster that runs SQL Server.
- No VM licensed below the four-core minimum, whatever its actual vCPU allocation.
