SQL Server True-Up on a Virtualised Cluster

The "96 cores equals three hosts" reasoning only holds if the VMs cannot run on the fourth host. With DRS fully automated and vMotion enabled, they can. The licensable set is therefore the whole cluster: 4 x 32 = 128 cores. HA admission control reserving 25% is a capacity setting, not a licensing boundary, and does not shrink that number.

But the correct model depends on whether Software Assurance is being used for licence mobility:

• Host-based, no mobility: all four hosts must be licensed - 128 cores against an entitlement of 96, a gap of 32 cores, about GBP 230,400.
• Per-VM with SA mobility: each VM is licensed for its own vCPU count (minimum 4 cores per VM) and may move freely. Nine Enterprise VMs at 8 vCPUs each needs 72 cores. The 96-core entitlement would then be sufficient, and the gap is zero.

So the deployment must be mapped VM by VM - vCPU count, edition, host affinity, licence assignment - before any money moves. Two errors are live: the team is counting hosts when the rule may be per-VM, and the CFO is buying 64 cores when the worst-case shortfall is 32. Cancel or reduce the PO until the effective licence position is signed off by the licensing specialist against the actual agreement terms.

Read-only is still access. The partner's analysts reach SQL Server data through the linked server, and under the Server + CAL model every user or device that accesses the data needs a CAL, regardless of whether they read or write, and regardless of whether they touch the database directly or through an application or linked server.

Options, in order of preference:

1. License the specific instances the partner touches per core. Per-core licensing for an instance covers unlimited users against that instance, which is often cheaper and far simpler to administer than issuing and tracking CALs for a third party.
2. Buy CALs for the partner's named users. Workable only if the partner's user population is small, stable and auditable - and it must be declared in the True-Up.
3. Move the reporting to a separate, dedicated instance or exported data set licensed for that purpose, so partner access does not contaminate the licensed production footprint.

Whichever route is chosen, it must be declared accurately in the True-Up. The most expensive outcome here is not over-buying: it is an inaccurate self-audit declaration that is later contradicted by the vendor's own discovery of the linked server. Suspend external access until the position is modelled and documented, and record the partner integration in the CMDB as a dependency so the next cycle catches it automatically.

The failure is procedural, not technical: a purchase commitment preceded measurement.

• Define the effective licence position as a gate. Consumption, entitlement and the licence model must be signed off before any true-up PO is raised. A PO raised "because a shortfall is likely" is a guess with a budget attached.
• Make licence impact part of change. Adding vCPUs, enabling DRS, adding a linked server or onboarding a partner should each raise a licensing review task. Every fact in this scenario is a change that had a licensing consequence nobody assessed.
• Automate the evidence. Inventory tooling should capture per-VM vCPU, edition, host, and the licence assignment nightly; the manual spreadsheet is where the host-versus-VM confusion lives.
• Separate the roles. The person who owns the deployment should not be the only person who defines the entitlement; a licensing specialist validates the model against the agreement, and the CFO sees both the modelled gap and the assumptions behind it.
• Use a standing review cadence. Quarterly internal true-up keeps the number small and the conversation calm, rather than an annual scramble with a PO in flight.

Measure one thing: the number of days between a licence-affecting change and its reflection in the licence position. Target under five.