The Per-Core Database That Grew Overnight
A retail company runs a database product licensed per physical core with a minimum of two cores per server. Virtualisation was introduced two years ago; the hypervisor now presents 16 vCPUs to each database VM, and 40 VMs run across 12 physical hosts, each host with 32 cores. The contract has a soft-partitioning clause that allows licensing only the virtual machines, but only if the hypervisor enforces a hard cap on CPU resources per VM. The current hypervisor does not enforce caps; it allows burst. Finance has been budgeting on the 40-VM count. A renewal is 90 days out and the vendor has hinted at a 'licensing review'.
1. What is the real licensing exposure, and what are the options with their trade-offs?
Read the worked answer
Under per-core licensing with a minimum per server, the exposure depends entirely on whether the soft-partitioning clause is satisfied.
If the clause is not met (current state, no hard cap), the vendor can require licensing of the physical cores the VMs can potentially access. With 12 hosts at 32 cores, that is 384 cores of potential footprint, not 40 VMs' worth. Even if clustering limits which hosts a VM can move to, the licensable quantity is the maximum it can reach, not the average it uses.
Options:
- Enforce hard caps. Configure CPU limits per VM so each VM cannot exceed its allocation, then license per VM under the clause. This converts the exposure to the VM count and is usually the cheapest path, but it costs performance headroom and requires proof the cap is technically enforced, not just configured.
- License the physical hosts. Predictable and simple, but expensive at 384 cores and wasteful given actual utilisation.
- Reduce the estate. Consolidate VMs and hosts before renewal so whichever model applies, the number is smaller.
Trade-off to surface to Finance: the budget was built on an assumption (soft partitioning applies) that the contract does not currently support. The gap between the VM-based and host-based number is the real risk, and it should be quantified before negotiation, not after.
2. How should the SAM lead approach the renewal conversation, and what evidence must exist before it?
Read the worked answer
The renewal is a negotiation about the licensing metric, so the evidence has to settle the metric before price is discussed.
Before the meeting:
- Obtain the executed contract and confirm the exact wording of the soft-partitioning clause, the minimum-cores rule and any mobility/cluster language.
- Produce a technical report proving whether CPU caps are enforced, with configuration exports and a test showing a VM cannot burst past its allocation.
- Build a deployment map: hosts, cores, VM-to-host affinity, cluster boundaries, and the maximum core footprint any VM can reach.
- Model three scenarios (capped-per-VM, physical-host, consolidated estate) with cost and performance impact.
In the conversation:
- Lead with the technical facts, not with the budget. If caps can be enforced, propose that as the basis and ask the vendor to confirm in writing that the capped configuration qualifies.
- If the vendor will not accept it, negotiate a transition: a capped environment going forward with a phased true-up rather than a retroactive host-based charge.
- Seek a written statement of the licensing basis for the next term so the ambiguity does not recur.
Judgement being tested: the SAM lead's job is to change the facts (enforce caps, consolidate) before arguing about price. Arguing price on an unsupported assumption loses.