RHEL socket pair, counted against virtual datacenter.
RHEL socket pair counting and virtual datacenter counting are two different mechanics applied to two different shapes of deployment. The audit team in 2026 frequently applies the socket pair mechanic against estates that the contract licenses on virtual datacenter terms, producing a finding that the contract itself does not support. The defense is operationally simple and contractually exact: read the contract before reading the inventory. This note treats both mechanics, where they diverge, and what the response asserts before any inventory is returned.
What the socket pair measures.
The RHEL socket pair counting mechanic measures entitlement consumption at the physical host level by counting populated CPU sockets in pairs. One socket pair subscription covers up to two populated physical sockets on a single host. The mechanic is straightforward for a non virtualized estate: count populated sockets, divide by two, count the result against the entitlement record. The complication arrives when the host is a hypervisor and the workloads on it are virtual machines. The socket pair mechanic was not designed for that shape of deployment, and the contract typically does not require it to be applied there.1
Across the audit defenses settled in the trailing twelve months, the socket pair mechanic was the dominant counting dispute in six of twelve matters. In all six the audit team applied socket pair counting against estates with significant virtualization. In all six the contract either established a virtual datacenter subscription on the affected hosts or established a counting mechanic the response could read against socket pair. The defense work was therefore not technical demonstration of the virtualization; it was contractual demonstration of which mechanic governed.
The companion note on counting RHEL systems accurately treats the inventory read in detail. The note on RHEL practice sets the product context.
What virtual datacenter measures.
The virtual datacenter subscription covers all RHEL guest virtual machines running on a single hypervisor host or cluster, regardless of the number of guests. The subscription is sold per hypervisor socket, typically in groups, and is intended for estates where the number of RHEL guests would otherwise produce a socket pair count that significantly exceeds the underlying physical footprint. The subscription contemplates virtualization explicitly; the socket pair subscription does not.
The virtual datacenter mechanic creates two questions the audit team can probe. The first is whether the customer's subscription record reflects virtual datacenter coverage on the affected hosts at all. The second is whether the coverage is sized correctly against the hypervisor estate. Where the answer to the first is yes, the socket pair mechanic does not apply on those hosts; the response asserts the virtual datacenter posture in the response language. Where the answer to the first is no but the contract contemplates virtual datacenter as the default for hypervisor hosts, the response cites the contractual default. The note on virtual datacenter deep dive treats the mechanic at the contract level.
The virtual datacenter sizing is often the secondary dispute. Where the hypervisor cluster has grown beyond the subscription's covered socket count, the response is to size up the virtual datacenter rather than to default back to socket pair. The audit team will accept the up sizing as the resolution of the finding more readily than it will accept the socket pair posture once the response has asserted virtual datacenter as the governing mechanic. The note on unlimited virtual when it pays treats the third tier of the mechanic.
Where the two diverge in practice.
The divergence between socket pair counting and virtual datacenter counting is largest in three deployment shapes that recur in 2026 audits. Each shape produces a meaningful finding when socket pair is applied incorrectly. The figure below sets out the three shapes, the audit team's default reading on each, and the contractual response position.
| Deployment shape | Audit team default | Response position |
|---|---|---|
| VMware cluster, RHEL guests, no VDC on record | Socket pair on every host | VDC at cluster level per contract |
| KVM hosts, RHEL guests, partial VDC | Socket pair on non VDC hosts | Expand VDC to cover full cluster |
| vMotion / DRS across hosts | Worst case socket count | VDC at cluster level; vMotion irrelevant |
| Mixed virtualization and bare metal | Socket pair across all | VDC for hypervisor; socket pair for bare metal |
| Dense hypervisor, high guest count | Socket pair against guest count | Unlimited virtual where the math justifies |
The first shape is the most common and the most consequential. A VMware cluster running RHEL guests without an explicit virtual datacenter subscription on the cluster invites the audit team to count socket pairs on every host plus the guest count, producing a finding that often exceeds the cluster's physical footprint several times over. The contract typically contemplates virtual datacenter on hypervisor hosts running multiple RHEL guests; the response cites the contractual default and proposes the virtual datacenter resolution at the right size.
The third shape, vMotion or DRS migration across hosts, produces the most heated counting disputes. The audit team's default reading treats every host the guest could land on as in scope under socket pair. The virtual datacenter mechanic moots the question entirely at the cluster level. The response that asserts virtual datacenter early in the matter closes the dispute before it consumes settlement leverage on other surfaces.
What the response establishes first.
The response that defends correctly establishes the counting mechanic before any inventory is returned. The order matters operationally and contractually. Operationally, an inventory returned in the audit team's default template carries the audit team's counting assumptions; the assumptions are then difficult to dislodge. Contractually, the counting mechanic is a question of contract interpretation that sits upstream of the inventory data, not downstream.
The scope paragraph of the response cites the customer's RHEL subscription terms verbatim where the contract establishes virtual datacenter as the default mechanic on hypervisor hosts. Where the contract is silent on the question, the response cites Red Hat's published subscription documentation that establishes virtual datacenter as the mechanic for the shape of deployment in question. The audit team is often operating from a different contractual reading, and the response forces the alignment in writing before producing data.
The note on responding to the compliance letter treats the response language in full; the present note treats the counting paragraph specifically. The companion note on OpenShift core counting on virtualization treats the parallel mechanic on the container platform side.
Where the counting meets the contract.
The counting reading does not exist in isolation from the contract. The contract establishes the mechanic; the response cites the contract; the audit team's finding rebuilds against the cited mechanic. Customers without a clear contractual statement of mechanic find themselves arguing the mechanic on first principles, which the audit team is structurally positioned to win. Customers with a clear contractual statement find the audit team accepting the mechanic without prolonged dispute. The single most consequential moment in a RHEL counting dispute is the moment the contract is cited explicitly in the response language.
Where the existing contract does not establish the mechanic clearly, the renewal that follows the settlement is the moment to fix the language. The settlement that closes well closes with an explicit counting mechanic in the renewal paper, sized to the actual deployment shape. The note on renewal negotiation treats the language reset; the note on post audit posture treats the contract hygiene work after settlement.5
If the audit notice is in hand and the counting question is open, the first useful hour is a call with the practice. The note on Red Hat audit defense as a service sets out the engagement protocol; the present note treats the counting work inside that protocol.
Notes & references
- 1. Socket pair definition. Red Hat's socket pair subscription covers up to two populated CPU sockets on a single physical host. The mechanic predates large scale enterprise virtualization and is operationally cleanest on bare metal estates.
- 2. Virtual datacenter design. The virtual datacenter subscription is Red Hat's named mechanism for hypervisor hosts running multiple RHEL guests. It is sold per hypervisor socket and contemplates an arbitrary number of guests per host.
- 3. Audit team default. Across six recent audit defenses involving virtualization, the audit team's first reading applied socket pair counting in all six, including in three cases where virtual datacenter was already on the customer's account.
- 4. vMotion treatment. The vMotion question is largely mooted by virtual datacenter at cluster level. Where socket pair is applied, the audit team's worst case reading on vMotion produces the largest single counting dispute the practice has handled in 2026.
- 5. Renewal language reset. Across the six recent defenses, all six were followed by a renewal that included explicit counting language for the customer's actual deployment shape. None of the six has returned to dispute on the same counting question.
Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.