Red Hat Virtual Datacenter Subscriptions: Hosts, Guests and the Unregistered Systems
Red Hat Enterprise Linux for Virtual Datacenters (VDC) is sold on the host: pay for the socket-pair, and every virtual guest that runs on that socket-pair is covered, unlimited, on a supported hypervisor. It is the highest-density RHEL subscription there is, and it is also the one estates most often get wrong, because the entitlement lives on the host pair while the guests are the thing anyone actually notices.
The gaps that show up are consistent: hosts running as hypervisors without their own operating-system entitlement, clusters where some hosts are covered and others are not, and guests that register content access under Simple Content Access without the account behind them actually holding enough VDC to cover the estate. None of these show up until someone counts the hosts against the subscriptions, which is usually the audit.
What a VDC subscription actually buys
- Bought on the host, counted in socket-pairs. A VDC subscription covers a socket-pair, the same base unit as RHEL Server. An eight-socket host needs four VDC subscriptions, stacked the same way Server subscriptions stack.
- Unlimited guests on that pair. Once the host pair is covered, the number of RHEL guests running on it is not separately licensed. That is the density VDC is bought for.
- Named hypervisors only. The subscription names the supported hypervisors: Red Hat Virtualization, VMware, and Microsoft Hyper-V. A hypervisor outside that list is not a VDC scenario, whatever the sales conversation assumed.
- No host operating system included. If the hypervisor itself needs RHEL to run, that is a separate subscription. VDC covers the guests, not the platform underneath them.
The mechanics sit on top of Red Hat's general subscription model, covered in full in understanding Red Hat's licensing model: the socket-pair as the base unit, stacking for multi-socket hosts, and the physical-versus-virtual portability that lets a subscription move between a physical node and virtual guests without contacting Red Hat.
Where clusters go wrong
VDC is pooled at the cluster, and Red Hat's terms are specific about what that means: every host in the cluster has to be accounted for, at a uniform service level, unless the hypervisor can actually restrict and enforce which hosts run RHEL workloads. A cluster running Standard on some nodes and Premium on others, with a workload that can land on any of them, is not a partial coverage situation; it is every node needing the higher level.
The failure pattern is almost always the same: a cluster grows by a host or two, added for capacity rather than as a licensing decision, and the new host runs the same workloads as the rest of the cluster without anyone adding its socket-pair to the VDC count. The guests on it look identical to every other guest in the cluster. The gap is at the host level, invisible from inside any single guest.
Registered is not entitled
Under Simple Content Access, a host authenticates to the Red Hat Customer Portal or Satellite, gets a system identity, and from that point can enable the repositories it needs. That registration is a content-access check, not a licensing check: a host can be fully registered, pulling packages without error, on an account that does not hold enough VDC subscriptions for the cluster it sits in. subscription-manager status answering cleanly on the guest tells you nothing about whether the host pair underneath it is covered.
The real question is not whether a guest is registered; it is whether the account holds enough of the right subscription type for every host the guest could run on. That is an account-and-inventory question, not a per-host one, and it is exactly the distinction how to check if your Red Hat server is licensed walks through for individual systems. VDC adds the cluster layer on top: the check has to cover every host the cluster can schedule a workload onto, not just the one you happen to be looking at.
virt-who is part of this and often mistaken for the whole of it. It reports guest-to-host mapping for accurate Subscriptions Service charts on VDC and similar subscription types, but reporting is not attach: running virt-who makes the inventory visible, it does not make the host entitled.
The reconciliation that closes the gap
- List every host in every cluster that runs a RHEL guest, including hosts added for capacity that nobody flagged as a licensing event.
- Confirm the hypervisor on each host is one of the three VDC supports. A cluster running an unsupported hypervisor is not covered by VDC regardless of guest count.
- Count socket-pairs per host and stack subscriptions accordingly, then confirm the account holds that many VDC subscriptions at a uniform service level across the cluster.
- Check whether the hypervisor itself is RHEL, and if so, confirm it carries its own subscription separate from the VDC guest coverage.
- Treat registration and entitlement as two different checks, run against the same host and guest inventory, not one used to infer the other.
Every one of those checks needs the same underlying data: the hosts, their sockets, their hypervisors, their cluster membership, and which guests actually run where. Red Hat Deployment Manager resolves that from the inventory you already collect, mapping physical and virtual RHEL to the SKUs that cover them and surfacing the hosts a cluster grew to include without anyone adding the subscription. A subscription position built from real host and guest data, backed by install and registration timestamps, is defensible at renewal and at audit; one inferred from which guests happen to look registered is not.
Checklist
- Every host in every RHEL-carrying cluster listed, capacity additions included.
- Hypervisor on each host confirmed as one of the three VDC supports.
- VDC subscriptions counted in socket-pairs, stacked per host, uniform across the cluster.
- The hypervisor's own RHEL entitlement checked separately from guest coverage.
- Registration and entitlement checked as two separate facts, not inferred from each other.
