SQL Server in a virtual estate has two licensing models, and the gap between them is often the single largest controllable number on the SQL bill. You can license each virtual machine by its allocated cores, or you can license the physical host by all its cores and run unlimited SQL virtual machines on it. The first model suits a sparse footprint. The second rewards density, but only above a threshold that most estates cross without recalculating. The error that costs the most is choosing the model once and never revisiting it as the estate grows, then paying per VM across a dense cluster where licensing the hosts would have cost a fraction. The mirror error is licensing hosts for a sparse footprint and paying for cores that run no SQL. The right model is a calculation, not a default, and it changes as the cluster fills.
Both models are legitimate. The choice between them is an economic decision driven by how many SQL virtual machines run on a given host and how much they move. Understanding what each model actually licenses is the precondition for choosing correctly.
You license the virtual cores allocated to each SQL virtual machine, subject to a minimum core count per VM. This model suits estates where SQL runs on a small number of VMs spread across many hosts, because you pay only for the cores SQL actually uses rather than the full hardware underneath.
You license all the physical cores on the host and, with software assurance, run an unlimited number of SQL virtual machines on it. The economics flip in this model's favor once enough SQL VMs share a host that the per VM total would exceed the cost of the hardware's full core count.
The decision is a crossover calculation. Below a density threshold, per VM is cheaper. Above it, per host wins. Three variables move that threshold, and getting any of them wrong sends an estate to the more expensive side of the line.
The core driver. A host running two SQL VMs almost always favors per VM. A host running eight or ten dense SQL VMs almost always favors per host, because the per VM total has long since passed the cost of licensing all the physical cores. The crossover usually sits in the middle of that range, which is exactly where estates stop recalculating.
Heavily provisioned SQL VMs reach the per host crossover faster, because their large virtual core counts inflate the per VM total quickly. The interaction between VM size and VM count is where a simple count of machines misleads, and where a proper model earns its place.
If SQL VMs move freely across a cluster through live migration, licensing individual hosts becomes complex and the per host model may require licensing every host the VM can land on. High mobility often pushes the answer toward licensing the whole cluster's hosts or constraining where SQL VMs are allowed to run.
The correct virtualization position is rarely just a model choice. It is a model choice plus a placement policy that holds the chosen model's economics in place as the estate evolves. Both pieces are needed, because the cheapest model on paper is undone by uncontrolled VM sprawl.
We model the per VM total against the per host total for each cluster using the actual VM count, core allocation, and host core density. The output is a clear answer per cluster rather than a single estate wide default, because a dense production cluster and a sparse test cluster usually land on opposite sides of the crossover. The savings from moving a cluster to its correct model is direct and recurring, and in dense estates it frequently runs to a third or more of the SQL line.
Where per host is the right model, the savings only hold if SQL VMs are confined to the licensed hosts rather than free to migrate across the whole cluster. We set the placement policy that keeps SQL on the cores you have licensed, so the unlimited VM benefit stays a benefit rather than becoming an obligation to license every host SQL could reach. This single control is what separates a per host model that saves money from one that quietly creates exposure across the cluster.
The per VM versus per host crossover, the three variables that move the threshold, and the placement policy that holds per host economics in place as the cluster fills. Sent on request.
We run the per VM against per host crossover for each cluster in the estate, move the dense clusters to host licensing and the sparse ones to per VM, and set the placement policy that keeps the savings in place. The most expensive controllable number on the SQL bill comes down and stays down.