LICENSEWARE
Contribute

Red Hat Enterprise Linux and OpenShift subscription licensing

From the LICENSEWARE WikiLast edited 13 ReferencesCited

This article covers how Red Hat names Units for self-managed Red Hat Enterprise Linux and Red Hat OpenShift subscriptions. It is not legal advice. Product Appendix 1 is the binding unit-of-measure document; the RHEL and OpenShift subscription guides quote it and state that nothing in those guides supersedes Appendix 1. Contractual sources are linked in References. Appendix 4 hosted services and store SKU prices are out of scope here.

On This Page

Red Hat Enterprise Linux and OpenShift subscription licensing is how Red Hat sells Subscription Services against counted Units. Fees are for Subscription Services; Appendix 1 says there are no fees associated with the Red Hat Software licenses. RHEL Server is purchased as a Socket-pair for each Physical Node or as 2 Virtual Nodes. Self-managed OpenShift compute is purchased as a Core-pair (2 physical cores or 4 vCPUs) unless the SKU is a Bare Metal Node Socket-pair band. Red Hat publishes no conversion between Socket-pair and Core-pair. Buying programs and support Service Levels are how customers purchase those Units, not separate metrics.

Metrics

The catalog has seventeen rows for Red Hat, each under Red Hat’s own name. Rows 5–17 are further Appendix 1 Table 1.1 Units. Appendix 1 Table 1.1 does not use the token “Core-pair”; Exhibit 1.B Virtual Node rows say 2 Cores or 4 vCPUs. The OpenShift subscription guide does use Core-pair. Both strings are Red Hat’s. Red Hat publishes no Socket-pair↔Core-pair packing formula.

# Red Hat name Catalog row Unit What Red Hat says 
1 Socket-pair Socket-pair Socket Up to two Sockets. Socket = a socket occupied by a CPU. One-socket physical server still needs a Socket-pair; cannot split across two physical systems. Stack: 8-socket machine = four base subscriptions (RHEL guide, 4 Nov 2025). RHEL Server: Socket-pair for each Physical Node or 2 Virtual Nodes. 
2 Physical Node Physical Node Other A physical system which contains or executes all or a portion of the Software (server, workstation, laptop, blade, or other physical system). Distinct from Bare Metal Node (row 9): OpenShift SKU that is still a Physical Node, with Socket-pair core-band capacity. 
3 Virtual Node / Virtual Guest Virtual Node Other An instance of the Software executed, in whole or in part, on a virtual machine or in a container. RHEL Server: 2 Virtual Nodes per Socket-pair subscription regardless of virtual sockets. Virtual Datacenters: unlimited Virtual Guests on a Socket-pair (no host OS entitlement — Appendix 1 Exhibit 1.A Note 1). 
4 Core-pair Core-pair Core OpenShift guide: 2 physical cores or 4 vCPUs. Bare metal: always physical cores regardless of hyperthreading; 2 physical cores presenting as 4 vCPU = one core-pair. Hyperscaler (AWS, Azure, GCP): 4 vCPU = one core-pair. Counted at cluster level; may span instances. Not applicable to OpenShift Virtualization Engine. Appendix 1 equivalent token: 2 Cores or 4 vCPUs on Virtual Node SKUs. 
5 Managed Node Managed Node Other Each Node managed directly or indirectly during the term. Node = Virtual Node, Physical Node, device or other instance. Same Unit name for Ansible Automation Platform (Exhibit 1.D) and Satellite (formerly Smart Management); no conversion between them is published. Cannot cycle or rotate nodes to stay under entitlement (article 3331481). 
6 Core Core Core Physical or virtual processing core executing the Software. Exhibit 1.B Note 1: 1 Core = 2 vCPUs with HT unless the Order Form says otherwise — Exhibit 1.B products only. Note 3: minimum 2 Core allocations per Unit. Core Band is SKU packing of Cores, not a second catalog kind. 
7 vCPU vCPU vCPU A CPU assigned to a VM or container. Used in “2 Cores or 4 vCPUs”. Edge Device: Virtual Nodes up to 32 vCPUs. 
8 Socket Socket Socket A socket occupied by a CPU. Building block of Socket-pair. Device Edge: 1 Socket with up to 32 Cores. Distinct from Socket-pair (up to two Sockets). 
9 Bare Metal Node Bare Metal Node Other OpenShift Bare Metal Node SKUs: Physical Node; Socket-pair with up to 64 Cores, or up to 128 Cores after 1 January 2025 MSRP (Note 2). Guide: one physical server; cannot span servers. Distinct from Core-pair Virtual Node SKUs. 
10 AI Accelerator AI Accelerator Processor An acceleration processing unit (e.g. GPU or NPU) or board on Red Hat’s AI Accelerator support list that contains or executes the Software. CPU in Appendix 1 February 2026 excludes AI Accelerators. 
11 System System Other RHEL Workstation and Desktop UoM. Workstation: 2 CPU, Unlimited RAM, 1 or 4 Virtual Guests. Desktop: 1 CPU, up to 8GB RAM, 1 Virtual Guest. Distinct from Physical Node. 
12 FTE FTE Employee Full time faculty + ⅓ part time faculty + full time staff + ½ part time staff. Academic Site Subscription. Academic floor: 1,000 FTEs. 
13 IBM Z IFL / Power IFL IBM Z IFL / Power IFL Processor IBM Z IFL: activated mainframe CPU executing the Software. Power IFL: activated IBM Power processor core. RHEL for IBM Z Unit is IBM Z IFL. RHEL for Power SKU remains Physical Node or Virtual Nodes. Guide: Z/LinuxONE subcapacity (only cores used). 
14 Spyre Spyre Processor An IBM Spyre Accelerator that contains or executes the Software. February 2026 Table 1.1 addition. Distinct from AI Accelerator and from Socket-pair. 
15 User User User An individual person that accesses or uses the Software or Service. Employee User is a related defined term, not a second catalog kind. Distinct from FTE. 
16 Deployment Deployment Other An installation of a single instance of the Software or a single Quay Enterprise registry using a single shared data store. Quay; Private Partner Automation Hub. 
17 Module Module Other Use of the Software to manage one System, Virtual Node or Physical Node. Workstation and Desktop each include one Satellite Module. Distinct from Managed Node. 

Counting / floors

True-up. Appendix 1: while you have a Subscription, purchase the applicable Subscriptions in a quantity equal to the total number and capacity of Units from the commencement of use or deployment of that Subscription or a part thereof. Units include non-Red Hat products if Subscription Services support or maintain them.

Processor type. For Units based on processors running the Software (Physical Nodes, Virtual Nodes, CPUs, Cores, AI Accelerators), purchase Subscriptions that match the processor type. Subscriptions that do not specify a processor type are based on x86 processors.

RHEL Server — Socket-pair per Physical Node or 2 Virtual Nodes. Appendix 1 Exhibit 1.A capacity for Red Hat Enterprise Linux Server: Socket-pair for each Physical Node or 2 Virtual Nodes (regardless of virtual sockets).[1] Catalog proof: RHEL Server — Socket-pair per Physical Node or 2 Virtual Nodes (backs RHEL Server — Socket-pair per Physical Node or 2 Virtual Nodes).

Socket-pair stacking / cannot split. RHEL guide: base unit is a socket-pair. 2-socket server = one subscription; 4-socket = two; 8-socket = four. Each one-socket system must be entitled with a Socket-pair subscription; that subscription cannot be split across different physical systems. Ten one-socket systems therefore need ten Socket-pair subscriptions, not five. Self-support subscriptions cannot be stacked and are not for use with Red Hat Cloud Access; Entry Level server subscriptions are available only with self-support and can be deployed only on physical systems.[3] Catalog proof: Socket-pair stacking / cannot split across systems (backs Socket-pair stacking / cannot split across systems).

Core-pair (OpenShift compute). OpenShift guide: a Core-pair is 2 physical cores or 4 vCPUs. Bare metal: always physical cores regardless of hyperthreading; 2 physical cores presenting as 4 vCPU = one core-pair. Hyperscaler (AWS, Azure, GCP): 4 vCPU = one core-pair. Counted at cluster level; may span instances. Not a Socket-pair conversion; not applicable to OpenShift Virtualization Engine.[4] Catalog proof: Core-pair = 2 physical cores or 4 vCPUs (backs Core-pair = 2 physical cores or 4 vCPUs).

Exhibit 1.B Note 1 (scope). Unless otherwise stated in an Order Form, one (1) Core is equivalent to two (2) vCPUs with hyper-threading active for the Red Hat Products in Exhibit 1.B. That sentence does not apply to RHEL Socket-pair SKUs or to App Services products outside that Exhibit.[1] Catalog proof: Exhibit 1.B — 1 Core = 2 vCPUs (hyper-threading) (backs Exhibit 1.B — 1 Core = 2 vCPUs (hyper-threading)).

Exhibit 1.B Note 3. You may use up to the number of Cores purchased in the Core Band(s) for OpenShift Container Platform deployments, in a minimum of 2 Core allocations per Unit.

OpenShift Cluster. Appendix 1 Exhibit 1.B: purchase the appropriate number of OpenShift Container Platform Subscriptions for each Unit in a Cluster if any Units of OpenShift Container Platform are running in that Cluster. Each deployment of Red Hat Enterprise Linux, regardless of method (including containers), constitutes a Unit.

OpenShift Core-pair quantity (guide). Count the aggregate number of physical cores or vCPUs across all OpenShift compute nodes running across all OpenShift clusters you want to entitle using core-pair subscriptions. Control plane node entitlements are included and do not need to be counted. Infrastructure node entitlements are included as long as no user application instances are running on them.

OpenShift Bare Metal Node (catalog row 9). Physical Node; Socket-pair with up to 64 Cores, or up to 128 Cores for subscriptions purchased after 1 January 2025 based on the new MSRP (Exhibit 1.B Note 2), including Virtual Nodes hosted on OpenShift Virtualization on the Physical Node. OpenShift Virtualization is supported only when OpenShift is installed on the bare metal server and is not installed within a virtual machine.

Every install (guide). The RHEL guide, citing the agreement: purchase subscriptions for every system and virtual instance in the organization where Red Hat Enterprise Linux is installed. Migration between systems with similar characteristics is allowed so long as the total number of subscriptions still matches the total number of installed systems.

IBM Z subcapacity (guide). For IBM Z and LinuxONE customers, Red Hat Enterprise Linux does not require the entire physical node to be entitled, only the cores used by Red Hat Enterprise Linux. RHEL for IBM Z Unit remains IBM Z IFL (Exhibit 1.A). No Socket-pair conversion is published.

Supported-use-case floors (Appendix 1 Table 1.2(b)). Academic: minimum 1,000 FTEs. HPC: minimum four Physical Nodes per Cluster — Catalog proof: HPC — minimum 4 Physical Nodes (backs HPC — minimum 4 Physical Nodes). Grid: minimum fifty Socket-pairs per Cluster — Catalog proof: Grid — minimum 50 Socket-pairs (backs Grid — minimum 50 Socket-pairs). Disaster Recovery: same Service Levels and configurations (e.g. Socket-pairs, Virtual Guests, Cores); the DR Use Case does not include execution of active workloads. The RHEL guide separately names hot / warm / cold DR (paid subscriptions needed for hot DR only) ; that guide taxonomy is separate from Appendix 1’s intermittent-DR Use Case.

Virtualization

RHEL Virtual Node counting is instance-based (2 Virtual Nodes per Socket-pair on the Server SKU), not virtual-socket-based. Red Hat publishes no 2-vCPU = 1-socket packing for RHEL.

RHEL for Virtual Datacenters — unlimited Virtual Nodes. Appendix 1 Exhibit 1.A: unlimited Virtual Nodes running on a Socket-pair. Note 1: Virtual Datacenters Subscriptions do not include an entitlement for the host operating system.[1] Catalog proof: RHEL for Virtual Datacenters — unlimited Virtual Nodes on a Socket-pair (backs RHEL for Virtual Datacenters — unlimited Virtual Nodes on a Socket-pair).

Virtual Guest pooling (Appendix 1 Exhibit 1.A Note 2). When RHEL is used as a Virtual Guest, Virtual Guests may be pooled or shared on any other System that has a Subscription with the same Service Level (Standard or Premium) and the same Virtual Guest count (1, 4, or unlimited), without exceeding the total Virtual Guests of the underlying Subscriptions.

OpenShift Core-pair subscriptions are counted at the cluster level and can span multiple cloud instances, VMs, and physical servers. Hyperscaler vCPU counting (4 vCPU = one core-pair) is the OpenShift guide’s rule, not a RHEL Socket-pair conversion. The 2016 entitlement-accounting PDF’s “single instance for virtual system” wording does not apply to current RHEL Server 2-Virtual-Node packaging.

Mobility

Physical↔virtual portability (Socket-pair ↔ 2 Virtual Guests). RHEL guide: subscription portability lets you transfer a physical 2-socket subscription to a 2-virtual-instance subscription without contacting Red Hat to adjust terms; transferring virtual instance-pairs as physical socket-pairs is also possible.[3] Catalog proof: Physical↔virtual portability (Socket-pair ↔ 2 Virtual Guests) (backs Physical↔virtual portability (Socket-pair ↔ 2 Virtual Guests)). Prefer Appendix 1 UoM where the educational guide and Appendix 1 diverge.

Cloud / BYOL

Related program: Cloud Access.

Cloud Access eligibility. Appendix 1 §3.1: you may deploy Subscriptions in a Vendor’s Cloud under Cloud Access if you have purchased a sufficient number of Units, provided the Subscriptions do not have Units that are solely based on physical attributes (as further described at the Red Hat Subscription Management Customer Portal). Deployment in a Vendor’s Cloud does not change the start date or duration of the original Subscriptions.[1] Catalog proof: Cloud Access — Eligible Subscriptions; Units not solely physical attributes (backs Cloud Access — Eligible Subscriptions; Units not solely physical attributes). Red Hat publishes no 2-vCPU = 1-socket Cloud Access conversion.

Vendor termination — 60-day notice. Appendix 1 §3.5: Red Hat may terminate the availability of a particular Vendor that offers Cloud Access with sixty (60) day notice; you may continue to use any Subscriptions for the remainder of the term on another Vendor’s Cloud or on your premises under the Agreement.[1] Catalog proof: Cloud Access — Vendor termination 60-day notice; migrate Vendor or on-prem (backs Cloud Access — Vendor termination 60-day notice; migrate Vendor or on-prem).

Programs (not metrics)

Related program: Cloud Access.

  • Red Hat Enterprise Agreement (NA). Base terms, November 2021 PDF. Defines Unit as the basis upon which Fees are determined, as set forth in Product Appendices or an Order Form. Subscriptions auto-renew unless written notice is given at least 30 days before expiration. Unused Services expire at the end of the Services Term. No newer NA version was found.
  • Product Appendix 1. Binding Units table and product Exhibits. Current NA English: February 2026 Version. July 2025 NA English remains on disk as the prior revision.
  • Cloud Access. Appendix 1 §3 — Eligible Subscriptions (Units not solely physical attributes); Vendor termination with 60-day notice and migrate to another Vendor or on-prem. See Cloud / BYOL.
  • Appendix 4 Online Services. Hosted / managed offerings (ROSA, ARO, OSD, hosted AAP). Not tabulated on this page.
  • EULAs. Standard / GPL / LGPL / RHEL AI EULAs grant component rights and state they do not provide Subscription Services. Units of measure live in Appendix 1, not in the EULA.
  • Service Levels (Self-support, Base, Standard, Premium). Purchase attributes, not catalog Units; Appendix 1 section 2.5.5 lists all four, depending on the product. Self-support RHEL cannot be stacked. See Red Hat Enterprise Agreement, Appendix 1 terms and support levels.[1]

Out of scope

  • Core Band — SKU packing of Cores (e.g. 2, 4, 16, 64), not a separate purchase kind.
  • Cluster — grouping; entitle Units in a Cluster, not a separate purchase meter.
  • App Services / JBoss Core packing beyond Exhibit 1.B Note 1.
  • 2-vCPU = 1-socket (Cloud Access does not publish that packing) and any unofficial Socket-pair↔Core-pair or “virtual guest = 0.5 socket-pair” formula.
  • Exhibit 1.B Core = 2 vCPUs applied outside Exhibit 1.B.
  • RH00003 / RH00004 quantity and consumption (access.redhat.com/articles/2020393) — behind a customer login.
  • Store SKU prices.
  • Hardware / certified hardware catalogs.
  • Appendix 4 hosted services (ROSA, ARO, OSD, hosted AAP).

Catalog rows

Sample catalog rows for this article, grouped by table.

References

  1. Product Appendix 1, Software and Support Subscriptions (NA English, February 2026 Version)February 2026 (Table 1.1; Exhibit 1.A / 1.B; Cloud Access §3; HPC / Grid floors)Retrieved 2026-08-31.
  2. Product Appendix 1 (NA English, July 2025)July 2025 prior NA revision on diskRetrieved 2026-08-31.
  3. Red Hat Enterprise Linux subscription guide4 November 2025 (Socket-pair stacking; one-socket cannot split; portability)Retrieved 2026-08-31.
  4. Self-managed Red Hat OpenShift subscription guide202601 (Core-pair; compute vs control-plane vs infrastructure)Retrieved 2026-08-31.
  5. The Red Hat Enterprise Agreement North AmericaNovember 2021 (Unit definition; auto-renewal)Retrieved 2026-08-31.
  6. Product Appendix 4, Red Hat Online Services5 August 2025 filename (hosted offerings; not tabulated here)Retrieved 2026-08-31.
  7. Red Hat agreements hubLive hubRetrieved 2026-08-31.
  8. Red Hat subscription model FAQPoints to Appendix 1 for units of measureRetrieved 2026-08-31.
  9. RHEL subscription guide landing pageLanding for Nov 2025 guideRetrieved 2026-08-31.
  10. Self-managed OpenShift subscription guide landing pageLanding for 202601 guideRetrieved 2026-08-31.
  11. Product Appendix 1 — Software and Support Subscriptions (NA English, February 2026)Catalog: Product Appendix 1 — Software and Support Subscriptions (NA English, February 2026)Effective 2026-02-01. Retrieved 2026-09-15.
  12. Red Hat Enterprise Linux subscription guideCatalog: Red Hat Enterprise Linux subscription guideEffective 2025-11-04. Retrieved 2026-09-15.
  13. Self-managed Red Hat OpenShift subscription guideCatalog: Self-managed Red Hat OpenShift subscription guideEffective 2026-01-01. Retrieved 2026-09-15.

See also

Esc