The RHEL Virtual Datacenter, counted at the hypervisor.
The RHEL Virtual Datacenter deep dive comes down to one mechanic. The subscription entitles unlimited RHEL guests on a hypervisor, counted by the socket pair of the underlying host. The counting unit is the hypervisor's processor sockets, not the number of guests, and not the cores. This note walks the mechanic, the four traps that move hosts off the Virtual Datacenter line by surprise, and the audit reading that reconciles guest counts against socket counts at scale.
The Virtual Datacenter mechanic, in plain language.
The RHEL Virtual Datacenter subscription is the host based RHEL subscription priced per socket pair on the underlying physical hypervisor. Each Virtual Datacenter line entitles two physical processor sockets on the named hypervisor host, and entitles unlimited RHEL guest instances running on that hypervisor regardless of how many guests are deployed. The counting unit is the socket pair on the hypervisor; the entitlement that follows is RHEL on every guest the hypervisor runs.1
The arithmetic is simple at the level of a single host. A two socket hypervisor takes one Virtual Datacenter subscription. A four socket hypervisor takes two. A single socket hypervisor takes one, because the subscription is sold by socket pair and one socket rounds up. A guest count of one and a guest count of two hundred attract the same Virtual Datacenter cost on the same hypervisor; the model is intended for dense RHEL fleets on consolidated hosts. The model is not intended for sparse RHEL placements on hypervisors that also run non RHEL guests.
The Virtual Datacenter line sits in the same RHEL practice catalogue as the socket pair and pay as you go variants discussed in RHEL subscription models explained. The choice between Virtual Datacenter and per guest socket pair counting is the central buyer side decision for virtualised RHEL estates, and the choice depends on guest density, the support tier line, and the hypervisor footprint. For the parent practice posture see the RHEL practice hub.
The density arithmetic that justifies the line.
The Virtual Datacenter line is rational where the RHEL guest density per hypervisor exceeds a break even threshold against the per guest socket pair price. The threshold depends on the support tier and the term length, but the shape of the threshold is stable across engagements. Below the threshold, the per guest line is cheaper; above the threshold, the Virtual Datacenter line is cheaper; the threshold is a small number of guests per socket pair.2
The break even calculation is straightforward when the estate is known. Multiply the Virtual Datacenter line cost by the number of socket pairs on the affected hypervisors; divide by the per guest socket pair line cost; the quotient is the guest count at which the Virtual Datacenter line becomes cheaper. The buyer that runs the calculation honestly will frequently find that the threshold is low enough to recommend Virtual Datacenter even on modestly dense hypervisors, and that the per guest line is rational only on hypervisors that run a small handful of RHEL guests among a larger non RHEL population.
The honest version of the calculation includes the support tier line. A buyer that runs Premium support on the per guest line and Standard support on the Virtual Datacenter line is comparing two different products; the comparison should hold the support tier constant. Where Premium support is required across the estate, the Virtual Datacenter line at Premium is the comparator, not Standard. The support tier reading is in RHEL self support, standard, and premium.
| Hypervisor profile | RHEL guests | VDC vs per guest |
|---|---|---|
| Light, mixed workloads | 1 to 3 | per guest cheaper |
| Mid density RHEL | 4 to 7 | break even band |
| Consolidated RHEL | 8 to 20 | VDC cheaper |
| Dense RHEL cluster | 20+ | VDC strongly cheaper |
The four counting traps.
Four counting traps move hosts off the Virtual Datacenter line by surprise. Each begins with an operational decision that did not pass through the procurement team and ends as a row in the audit reading.
The first trap is the bare metal RHEL host added to the Virtual Datacenter pool. The host has no hypervisor; it is RHEL on the bare metal; Virtual Datacenter does not entitle it. The host belongs on a Socket Pair or other per host RHEL line, not on the hypervisor's Virtual Datacenter line. The error frequently appears when a single dedicated host is added to a fleet otherwise made of virtualised guests, and the registration is left under the same activation key as the virtualised hosts.
The second trap is the cluster migration that moves RHEL guests onto hypervisors not covered by Virtual Datacenter. A virtualisation team rebalances the cluster; guests move from a Virtual Datacenter covered hypervisor to a hypervisor outside the Virtual Datacenter scope; the guests are now entitled against nothing on the new hypervisor. The trap is not the migration. The trap is the absence of a control that keeps the Virtual Datacenter scope and the cluster scope aligned.3
The third trap is the socket density change. A hypervisor's processor configuration changes through hardware refresh; the socket count moves from two to four; the Virtual Datacenter line was sized for two; the host is now under entitled by one Virtual Datacenter line. The trap surfaces at refresh time, when the procurement team is focused on the hardware and the subscription register is read last. The buyer side control is a refresh checklist that includes the Virtual Datacenter line.
The fourth trap is the Smart Management or other add on attached to a Virtual Datacenter line on a per host basis when the add on is sold per guest. The buyer pays Smart Management at hypervisor count; the entitlement applies at guest count. The reverse error also occurs: Smart Management priced per guest on a Virtual Datacenter base produces a runaway add on line as guest density grows. The Smart Management reading specifically is in Satellite Smart Management entitlements.
The audit reading at scale.
The audit reading on a Virtual Datacenter estate joins three data sets. The list of physical hypervisors and their socket counts. The list of Virtual Datacenter subscriptions and the hypervisors they are assigned to. The list of running RHEL guests and the hypervisors they run on. The reading is internally consistent when every hypervisor with at least one RHEL guest has a Virtual Datacenter line covering its socket count, and when every RHEL guest is on a covered hypervisor.4
The first inconsistency the audit reading finds is the unentitled guest. A RHEL guest is running on a hypervisor that has no Virtual Datacenter line. The settlement reading values the guest at the per host RHEL line for the period of operation. The remediation is to attach a Virtual Datacenter line to the hypervisor or to migrate the guest to a covered hypervisor; the choice depends on the guest density on the affected hypervisor and on the planned utilisation.
The second inconsistency is the under sized Virtual Datacenter line. The hypervisor has Virtual Datacenter coverage but for fewer socket pairs than the hypervisor carries. The settlement reading values the residual sockets at the marginal Virtual Datacenter line. The remediation is to add the missing socket pair lines at the next true up; the trap is to discover the gap during the audit rather than during a routine subscription assessment.
The third inconsistency is the over sized Virtual Datacenter line on a hypervisor that no longer carries RHEL guests. The host previously ran a dense RHEL fleet; the fleet has been migrated to a different platform; the Virtual Datacenter line is still on the books. The reading is the inverse: the buyer is over entitled, and the line can be retired at the next renewal. Over entitlement and under entitlement frequently coexist in the same estate; the renewal posture surfaces both. The renewal mechanics are in renewal negotiation.
The renewal posture that keeps the line honest.
The Virtual Datacenter line is among the line items most often left to drift between renewals, because the operational changes that affect it happen below the procurement layer. A renewal posture that keeps the line honest has three operational habits.
The first habit is a hypervisor inventory of record. The list of hypervisors carrying RHEL guests is maintained as a procurement artifact, separate from the operational virtualisation inventory. The two lists are reconciled on a quarterly cadence; any hypervisor in the operational inventory that is not in the procurement record is reviewed, and any in the procurement record that is no longer running RHEL guests is retired.
The second habit is a refresh checklist that includes the Virtual Datacenter line. Hardware refreshes that change socket counts trigger a subscription review before the refresh is scheduled. The review covers the socket count delta and any add on Smart Management or Extended Update Support lines tied to the hypervisor. The reading is a procurement gate, not an after the fact correction.
The third habit is the migration scope alignment. Virtualisation cluster scopes and Virtual Datacenter scopes are explicitly aligned in the runbook for guest migrations. A guest cannot migrate to a hypervisor outside the Virtual Datacenter scope without a subscription event. The runbook is owned by the operations team and reviewed by the procurement team on the same quarterly cadence as the hypervisor inventory.
The three habits together cost a small amount of operational discipline and remove the line item from the audit surface entirely. The buyer that adopts them reads the Virtual Datacenter line as a stable, predictable expense; the buyer that does not adopts the line as a recurring source of surprise. For the engagement that puts the habits in place, see subscription assessment and audit defense. For an engagement against the desk, see the contact form.
Notes & references
- 1. The RHEL Virtual Datacenter subscription is documented on access.redhat.com under the RHEL subscription guide. The socket pair counting unit and the unlimited guest entitlement on a single hypervisor are the defining mechanics. The variant has been refined across RHEL major releases; this note reads against the current edition observed in engagements.
- 2. The break even between Virtual Datacenter and per guest counting depends on the per guest list price, the Virtual Datacenter list price, the support tier, the term, and the volume position. The threshold values in figure 2.1 reflect the typical reading rather than a specific quoted rate. Buyers should run their own arithmetic against the rates in their own quote.
- 3. Cluster scope and Virtual Datacenter scope alignment errors are among the most common counting traps observed at audit. They are also among the most preventable, since the operational tooling can carry a guard that prevents an out of scope migration from completing.
- 4. The audit reading at scale joins three data sets that frequently live in three different teams. The reconciliation is therefore an organisational exercise as much as a technical one, and the assessment cadence in § 5 is sized for that reality.
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.