RHEL storage add ons, and the base they sit on.

RHEL storage add ons sit on top of a base subscription that already includes a substantial storage and clustering surface. The RHEL base ships with LVM for volume management, XFS as the default file system, ext4 as a supported alternative, NFS client and server, the Samba stack for CIFS, multipath device handling, the iSCSI initiator, and the Stratis volume manager on supported releases. The base subscription supports these components in production on the supported hardware and release combinations1.

The structural consequence for buyers reading the add on quote is that a substantial part of what the storage estate runs on is already paid for in the base line. The base supports local storage, attached SAN with multipath, attached iSCSI, NFS mounted file systems, and Samba mounted shares without any further subscription. A workload that reads and writes to local XFS, an NFS share, or an iSCSI target does not require any add on. The add on is required when the workload uses one of the specific capabilities the add on adds on top of the base.

The reading at the renewal table is on which specific capability each add on adds, and on whether that specific capability is in production on the estate. The Resilient Storage add on adds the GFS2 cluster file system and the cluster aware LVM stack. The High Availability add on adds the Pacemaker cluster manager. The Smart Management add on adds the Satellite content and patch lifecycle stack. Each is independently priced. Each earns its line only if the specific capability is in production. The base line carries everything else.

The Resilient Storage add on adds the GFS2 cluster file system, the cluster aware LVM (formerly clvm, now lvmlockd with sanlock), and the Distributed Lock Manager. The capability set is a shared disk cluster file system that allows multiple RHEL nodes to mount the same block device read write at the same time, with locking coordinated through the cluster stack. The add on is a narrow capability with a narrow use case2.

The narrow use case is a workload that requires multiple nodes to write to the same block device concurrently with full POSIX semantics. The set of workloads that genuinely require this profile is small. Database clusters typically use either a shared nothing replication model that does not require GFS2, or a clustered file system specific to the database product. Application clusters typically use NFS or an object store for shared content rather than GFS2. Web tier clusters typically use shared storage through NFS rather than GFS2.

The frequent misreading at the renewal table is that the Resilient Storage add on is required for any clustered RHEL workload. It is not. A cluster of RHEL nodes that share an NFS mount does not require Resilient Storage; the NFS client is in the base. A cluster of RHEL nodes that each have their own local storage does not require Resilient Storage. A cluster of RHEL nodes that use a replicated database does not require Resilient Storage. The add on is required when, and only when, GFS2 or cluster aware LVM is in production on the estate.

The High Availability add on adds the Pacemaker cluster resource manager, the Corosync membership and messaging layer, the cluster fencing infrastructure, and the suite of cluster resource agents that wrap common services in a Pacemaker compatible interface. The capability set is a cluster manager that fails resources between nodes on a defined policy. The add on is required when Pacemaker is in production on the estate.

The frequent misreading at the renewal table is that the High Availability add on is required for any RHEL workload that the buyer considers highly available. It is not. A pair of RHEL nodes behind a load balancer where each runs the same application against a replicated database is highly available and does not require the High Availability add on. A pair of RHEL nodes where the application itself handles failover does not require the add on. A pair of RHEL nodes that share an NFS mount and run the same service does not require the add on. The add on is required when, and only when, the Pacemaker stack is in production.

The narrow use case for High Availability is a workload that genuinely requires Pacemaker as the resource manager. The set is typically databases that are clustered with vendor specific Pacemaker resource agents, classical SAP HANA system replication clusters that ship Pacemaker configurations, file server clusters that fail an NFS export between nodes, and a small set of other classical cluster workloads. Where Pacemaker is in production, the add on earns its line. Where it is not, the add on is paying for a capability the estate does not use.

The Smart Management add on, sold as the Satellite entitlement on the RHEL line, adds the Satellite content lifecycle and patch management surface. The capability set is the Satellite server itself, the Capsule infrastructure, the content view and lifecycle environment constructs, the host registration and subscription distribution layer, and the patch and errata workflow that sits on top. Smart Management is the add on that pays for Satellite to run3.

The reading at the renewal table is on whether Satellite is in production on the estate and on which RHEL hosts are managed through Satellite. The frequent misreading is that Smart Management is required on every RHEL host in the estate. It is not. Smart Management is required on each RHEL host that is registered to Satellite for content delivery and patch management. A RHEL host that consumes content directly from the Red Hat Content Delivery Network does not require Smart Management; the base subscription provides CDN access.

The reconciliation exercise sizes the Satellite managed footprint against the entitled Smart Management footprint, and the gap is the recoverable amount on the renewal. For estates that registered Satellite on a subset of hosts but renewed Smart Management across the full estate, the recoverable amount is the Smart Management line on the unmanaged remainder. For the Satellite reading in full, see the Satellite and Insights practice.

The reconciliation for RHEL storage add ons sizes the Resilient Storage entitlement against actual GFS2 deployment, sizes the High Availability entitlement against actual Pacemaker deployment, sizes the Smart Management entitlement against actual Satellite registration, and produces a gap on each line. The gap is the recoverable amount on the next renewal cycle.

The mechanical exercise is straightforward. The Resilient Storage gap is the entitled count minus the count of hosts running GFS2 or cluster aware LVM. The High Availability gap is the entitled count minus the count of hosts running Pacemaker in the active cluster configuration. The Smart Management gap is the entitled count minus the count of hosts actively registered to Satellite with a current registration. Each gap is recoverable on the next contract action.

The contract action that recovers the gap depends on the renewal posture. On the renewal, the gap is removed from the renewal line and the renewal sizes against the actual usage. Mid term, the add on may be reduced on the next true up cycle if the contract supports a downward true up; not every contract does. For estates with a multi year commit that does not support downward adjustment, the gap is locked in for the duration of the commit and the recovery is on the renewal at term end. The reading at signature is to never sign an add on count higher than the usage will justify across the commit, because the add on count is the floor, not the ceiling.

For the broader subscription reconciliation discipline, see the subscription assessment service. For the renewal posture, see the renewal negotiation service. For the RHEL counting mechanics across the base subscription, see counting RHEL systems accurately. For the storage practice context across the full storage and virtualization line, see the storage and virtualization practice.

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.