Storage subscriptions, assessed against the deployment.
Storage subscription assessment on Red Hat estates is the work of reading what the storage layer serves against the entitlement the buyer paid for. Capacity allocated at procurement carries a different relationship to capacity consumed than core based products carry, and the gap moves faster on storage than on any other Red Hat surface. This note sets out the three product surfaces, the evidence streams, and the patterns that recur.
What the storage subscription actually counts.
Storage subscription assessment on Red Hat estates is the work of reading what the storage layer actually serves against the entitlement record that names the capacity or the nodes the buyer paid for. The storage layer in 2026 carries three product surfaces inside the Red Hat catalogue: Ceph Storage as the standalone offering, OpenShift Data Foundation as the integrated container storage layer, and the residual Red Hat Virtualization storage surface that is in end of life transition. Each surface is sold against a different model, each surface produces a different evidence stream, and the buyer that reads the storage line on the contract without the assessment in hand will read the contract record as if it were the deployment record. The two diverge faster on storage than on any other Red Hat surface in the estate.1
This note frames storage subscription assessment as a discipline that sits inside the broader subscription assessment practice. It walks the three product surfaces, the two dominant counting models, the four evidence streams the practice reads, and the recurring patterns where the assessment surfaces material excess or material exposure. For the broader practice context on the product surface, see the storage practice hub; for the matching standalone product readings, see Ceph storage subscription explained and OpenShift Data Foundation pricing.
The frame matters because storage is one of the surfaces where the deployment changes shape between purchase and consumption. Capacity allocated at procurement carries a different relationship to capacity consumed than core based products carry between entitlement and execution. A buyer that bought a capacity tier in one year and grew the data footprint over the next two will frequently carry an entitlement that is materially below the deployment, while a buyer that bought a capacity tier with growth headroom may carry an entitlement materially above. The assessment closes both gaps on the working paper before the renewal quote arrives.
Three product surfaces, two counting models.
The three Red Hat storage product surfaces in 2026 are Ceph Storage, OpenShift Data Foundation, and the residual Red Hat Virtualization storage layer. Each surface sits in a distinct deployment posture and reads against a distinct entitlement model.2
Ceph Storage is the standalone object, block, and file storage platform. Entitlement is sold by capacity tier in current contracts, with bands that reflect the raw capacity served by the cluster. The assessment reads the raw capacity served by each Ceph cluster the buyer operates, the replication factor the cluster runs under, and the resulting usable capacity that the deployment consumes. The raw capacity number is the one the entitlement counts against. The usable capacity number is the one the application teams measure against. Both numbers belong on the working paper.
OpenShift Data Foundation is the integrated storage layer that runs inside OpenShift clusters. Entitlement is bundled with the OpenShift Plus offering and is otherwise sold against a per terabyte or per node model in the current order form. The assessment reads the storage cluster topology inside OpenShift, the storage class allocation against persistent volume claims, and the node count attributed to the storage operator. For the matching reading on the storage operator surface, see the container storage interface entitlement crossover.
Red Hat Virtualization storage is the residual layer on estates that have not yet completed the migration off the platform. Entitlement is sold against host counts with a storage component embedded in the broader virtualization subscription. The assessment reads the residual host count, the storage domains attached to each host, and the operating window across which the entitlement remains active. For the migration reading, see Red Hat Virtualization end of life planning.
| Surface | Counting model | Drift driver |
|---|---|---|
| Ceph Storage | Raw capacity tier in TiB. | Replication factor not modelled. |
| OpenShift Data Foundation | Per TB or per node, bundle aware. | Bundle credit not reconciled. |
| RHV storage | Embedded in host subscription. | End of life window not tracked. |
Four evidence streams the assessment reads.
The assessment reads four streams of evidence. Each stream lives outside the contract record and inside the storage operating estate.3
The first stream is the cluster topology view. Each Ceph cluster carries a monitor view of the OSD layout, the pool configuration, and the replication factor. The assessment reads the topology and identifies the raw capacity served by the cluster, the usable capacity available to the applications, and the replication overhead between the two. The same view, in different form, is available inside OpenShift Data Foundation through the storage operator. Both reads produce the input for the capacity tier reading.
The second stream is the application consumption record. Persistent volume claims inside OpenShift carry a request and a status that name the storage class, the size, and the bound state. The assessment reads the consumption record per namespace and aggregates against the storage cluster to produce a usable capacity consumption number per application tier. The number matters because the renewal posture frequently moves from capacity tier headroom toward more efficient tiering, and the application consumption record is what makes the tiering exercise legible.
The third stream is the storage operations record. Each storage cluster produces telemetry on growth, on rebalance activity, on backfill state, and on the health of each OSD or persistent volume. The assessment reads the telemetry across the operative window and identifies the trajectory of the deployment relative to the capacity tier. A cluster that is steady against the tier reads as a different reconciliation candidate from a cluster that is approaching the tier ceiling within the renewal window.
The fourth stream is the procurement record. The capacity tier the buyer signed against is held in procurement. The assessment reads that quantity as the entitled total, identifies amendment activity, and reads the resulting net entitlement against the deployment evidence from the prior three streams.
Three recurring assessment patterns.
Three assessment patterns recur across storage reconciliations the practice has closed in the trailing twelve months. Each produces a different renewal posture.4
The first pattern is the over provisioned Ceph estate. A buyer that procured a generous capacity tier ahead of a multi year programme and has grown into it more slowly than projected will frequently carry an entitlement materially above the deployment. The over provisioned pattern produces a renewal posture that moves the capacity tier down to match the operative trajectory and recovers the difference on the next signature. The recovery is typically expressed as a band rather than as a point estimate, because storage growth is non linear and the renewal posture has to leave room for the trajectory the cluster is on.
The second pattern is the bundle overlap on OpenShift Data Foundation. A buyer that has procured OpenShift Plus carries a Data Foundation credit inside the bundle, and a separate Data Foundation entitlement on the order form would duplicate the credit on every cluster that runs under the bundle. The assessment reads the bundle credit, identifies the duplication, and produces a working paper that names which clusters consume the bundle credit and which consume the standalone entitlement. For the bundle reading, see OpenShift Plus bundle when it pays.
The third pattern is the Red Hat Virtualization residual. A buyer mid migration off the platform carries a residual host count that continues to consume the storage subscription embedded in the virtualization line. The assessment reads the residual host count, the storage domain footprint, and the migration trajectory against the operative renewal window. The residual is treated as a finite line that depletes against the migration timeline rather than as a permanent entitlement that needs full renewal headroom.
What the working paper closes on.
The output of the assessment is a working paper that names the deployment, the entitlement, and the variance per storage surface. The paper carries the raw capacity served, the usable capacity consumed, the replication factor, the application tier consumption, the storage growth trajectory across the operative window, and the procurement amendment trail. The variance is expressed as a band rather than a point estimate because storage growth carries genuine uncertainty.
The paper is the buyer's working document. It is read against the order form, reviewed alongside the broader subscription assessment, and used to set posture into the next engagement. For the matching renewal posture, see renewal negotiation; for the migration economics on the residual virtualization layer, see exit planning. The paper is not filed with Red Hat, is not exported to the account team, and is not the input to any consumption conversation that the renewal team initiates.
For each surface, the paper produces a posture recommendation against the next renewal cycle. The recommendation is grounded in the deployment evidence and the trajectory, and it names the capacity tier, the bundle posture, and the residual depletion schedule the buyer can take into the engagement. The recommendation is reviewable and reversible. It is not a commitment.
Five recurring failure modes.
Five failure modes recur on storage subscription engagements where the assessment is not run with the discipline this note describes. Each is correctable on the working paper before the renewal quote arrives.5
The first is reading usable capacity as raw capacity. Ceph is sold against raw capacity, and a reconciliation that reads the usable number will under count the entitlement requirement by the replication factor. The assessment reads both numbers and applies the factor explicitly.
The second is treating OpenShift Data Foundation as a separate line where the bundle credit is in force. The bundle credit is duplicated on every cluster that runs under OpenShift Plus and carries a separate Data Foundation entitlement. The assessment reads the bundle and identifies the duplication on the working paper.
The third is reading a single point in time rather than the trajectory. Storage clusters grow. A reconciliation that reads a single quarter rather than the operative window will under model the trajectory and miss the renewal headroom question. The assessment reads the trailing twelve months and projects the next twelve.
The fourth is treating the Red Hat Virtualization residual as a permanent line. The platform is in end of life transition and the residual entitlement should be modelled as a finite line that depletes against the migration timeline. The assessment reads the timeline and recommends the depletion schedule on the order form.
The fifth is reading the storage line without the host or container surface that consumes it. Storage is consumed by applications and by virtualization. The reconciliation reads the consuming surface alongside the storage cluster and identifies any consumer that is not accounted for. For the broader reading on the related surfaces, see OpenShift Virtualization licensing and the contact desk.
Notes & references
- 1. Red Hat storage in 2026 covers Ceph Storage, OpenShift Data Foundation, and the residual Red Hat Virtualization storage layer. The three surfaces are sold against different models and consumed by different application tiers. The assessment discipline reads each surface separately and reconciles against the order form line that names it.
- 2. The counting models in § 2 reflect Red Hat order forms observed in the trailing twelve months. Older contracts may carry historical models that read against host counts or against different capacity bands. The assessment reads the operative order form rather than the historical model.
- 3. The four evidence streams in § 3 reflect the practice standard on storage subscription engagements. Estates with smaller storage footprints can be reconciled against fewer streams; estates with mixed Ceph and Data Foundation deployments require all four.
- 4. The three assessment patterns in § 4 reflect the deployment patterns the practice has seen most often in the trailing twelve months. The over provisioned pattern produces the cleanest recovery on the renewal posture; the bundle overlap pattern produces the largest single line saving on a Data Foundation reconciliation.
- 5. The five failure modes in § 6 are observed across storage subscription engagements closed in the trailing twelve months. The most common is the third, where a single point in time read substitutes for a trajectory reading and the renewal headroom question is not answered.
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.