Why Traditional SAM Doesn't Work for Red Hat and SUSE
Traditional Software Asset Management was largely built around a relatively simple question:
How many copies of the software do we have, and how many licenses have we purchased?
For many traditional software products, that question still has value.
But try applying the same approach to an enterprise Linux environment and things become considerably more complicated.
A Red Hat or SUSE environment isn't simply a collection of software installations. It is an interconnected technology ecosystem involving physical servers, virtual machines, hypervisors, clusters, cloud infrastructure, containers, subscriptions and contractual rights.
The result is that traditional "count the installations and compare them to the licenses" SAM can produce a very incomplete picture.
The installation count isn't the answer
Imagine an organisation tells you:
"We have 1,500 Linux servers."
At first glance, that sounds like useful SAM information.
It isn't enough.
Those 1,500 systems could include:
Physical servers
Virtual machines
Cloud instances
Development environments
Test environments
Disaster recovery systems
High-availability clusters
Virtualisation hosts
Container platforms
Systems running different Linux distributions
Systems covered by different subscription agreements
Even within a single vendor ecosystem, the commercial treatment can vary depending on how the technology is deployed.
Red Hat's current subscription documentation, for example, distinguishes between physical and virtual deployments and offers different subscription models, including physical socket-pair and virtual-node approaches, as well as models designed for high-density virtual environments.
SUSE similarly distinguishes between physical, virtual, public-cloud and high-density virtualisation scenarios in its subscription guidance.
So the question isn't simply:
"How many Linux installations do we have?"
It is:
"What exactly are those installations, where are they running, how are they connected to the underlying infrastructure, and what subscription rights apply to each deployment?"
That is a very different SAM problem.
Subscription management is not the same as licence counting
The language itself matters.
Traditional SAM often talks about licenses.
Enterprise Linux vendors frequently operate through subscriptions.
A subscription can provide much more than permission to install software. Depending on the product and agreement, it can provide access to software, updates, support, repositories, knowledge resources and other services.
Red Hat describes its subscription model as providing access to tested and certified enterprise software together with support and other subscription benefits.
That changes the SAM conversation.
The organisation isn't simply buying a static quantity of software.
It is managing an ongoing relationship between:
deployment
→ subscription
→ entitlement
→ support
→ contract
→ infrastructure
→ commercial consumption
And that relationship needs to be understood continuously.
Physical servers can create a very different calculation
Consider a physical Linux server.
A traditional SAM tool might tell you:
RHEL installed: Yes
That's useful, but it doesn't necessarily tell you what is required to determine the relevant subscription position.
You may need to understand the physical server's characteristics and the applicable subscription model.
For example, Red Hat's current RHEL subscription guidance describes physical deployments in terms of socket-pairs, while other Red Hat products and subscription models can use cores, vCPUs or other units of measurement.
This means that a software inventory containing only:
Server 123 → RHEL
is insufficient for a meaningful commercial analysis.
You may need information about:
Physical CPU configuration
Socket count
Core count
Product and version
Subscription type
Support level
Deployment environment
Relevant contract
Additional products or add-ons
The SAM challenge therefore moves from software identification to infrastructure-aware entitlement analysis.
Virtualisation changes the equation
This is where traditional SAM approaches can really start to struggle.
One physical server might host:
20 virtual machines
And those virtual machines could potentially move between hosts.
Suddenly, counting installations doesn't tell you the whole story.
You need to understand the relationship between:
VM → hypervisor → physical host → cluster → subscription
Red Hat provides host-based subscription models for certain virtualised environments, where subscriptions attached to a hypervisor can provide entitlement to virtual machines running on that host. Red Hat's documentation also explains the role of virt-who in communicating hypervisor and VM information for subscription management.
SUSE likewise provides subscription models designed for high-density virtualisation, where the relationship between the virtualisation host and its virtual machines becomes important when determining the appropriate subscription coverage.
This creates an important SAM principle:
You cannot always understand the software position by looking at the software instance alone.
You have to understand the infrastructure underneath it.
The infrastructure relationship matters
This is one of the biggest differences between traditional SAM and modern infrastructure-oriented SAM.
Consider:
Physical Host
│
Hypervisor
│
┌────────────┼────────────┐
│ │ │
VM1 VM2 VM3
│ │ │
RHEL RHEL RHELA traditional inventory might report:
3 RHEL installations
But a SAM analysis may need to understand:
What physical host are the VMs running on?
How many sockets and cores does the host have?
Is the host part of a cluster?
Can the VMs move between hosts?
What subscription model is being used?
Are host-based subscriptions available?
Is the infrastructure configured correctly to support the subscription model?
What happens when another VM is created?
What happens when a VM moves to another host?
The answer can materially affect the commercial analysis.
Clusters make the problem even more interesting
Modern enterprise environments rarely operate as isolated servers.
They operate as clusters.
A cluster might contain:
Cluster A
Host 1 ── VM1
├─ VM2
└─ VM3
Host 2 ── VM4
├─ VM5
└─ VM6
Host 3 ── VM7
├─ VM8
└─ VM9VMs may be moved, restarted, replicated or automatically provisioned.
That creates a fundamental SAM challenge:
What is the actual licensing or subscription boundary?
Is it:
The VM?
The physical host?
The cluster?
The cores?
The sockets?
The virtual CPUs?
The maximum possible deployment?
The concurrent deployment?
The answer depends on the specific vendor, product, subscription and contractual terms.
This is why SAM practitioners should avoid applying generic "license rules" to enterprise Linux environments.
The product, metric, subscription model and contract terms must be understood together.
Cloud adds another dimension
The physical server may no longer even belong to the customer.
An organisation might run Linux workloads across:
AWS
Microsoft Azure
Google Cloud
Private cloud
Hosted infrastructure
Managed Kubernetes
Hybrid environments
The infrastructure can change dynamically.
Instances can be created and destroyed.
Workloads can scale automatically.
And the commercial relationship can depend on how the software is consumed.
Red Hat's subscription documentation explicitly addresses physical, virtual and public-cloud deployment models, while its Cloud Access documentation describes different unit conversions and entitlement approaches for cloud deployments.
This means that a monthly or quarterly SAM review based on a static inventory can quickly become outdated.
The organisation needs to understand consumption, not simply installation.
Containers change the SAM conversation again
Then we introduce containers.
A modern platform might look something like:
Cloud Infrastructure
│
Kubernetes / OpenShift
│
┌──────┼──────┐
Pod Pod Pod
│ │ │
App App AppThe traditional question:
"How many installations do we have?"
becomes increasingly difficult to answer.
Containerised workloads can be:
Started
Stopped
Rescheduled
Scaled
Recreated
Moved between nodes
The infrastructure is dynamic by design.
For some Red Hat products, subscription measurement can involve cores, vCPUs, nodes or other defined units, depending on the product and deployment model. Red Hat's current OpenShift guidance, for example, defines a core-pair for self-managed OpenShift and distinguishes physical cores from vCPUs in its sizing methodology.
This is fundamentally different from counting copies of software installed on a desktop PC.
Your CMDB isn't automatically an ELP
This leads to another important point.
Many organisations assume:
"We already have a CMDB, so we know our software estate."
A CMDB can be an extremely valuable source of information.
But a CMDB is not automatically an Effective License Position.
The same applies to discovery tools, endpoint management platforms, cloud management platforms and vendor subscription portals.
Each provides a different view of the environment.
A mature SAM programme needs to bring those views together.
For example:
Data source | What it can tell you |
CMDB | Configuration relationships |
Discovery tool | Installed software |
Hypervisor platform | VM and host relationships |
Cloud platform | Cloud instances and consumption |
Red Hat tooling | Red Hat system/subscription information |
SUSE tooling | SUSE deployment/subscription information |
Procurement system | Purchases |
Contract repository | Contractual rights |
SAM platform | Reconciled commercial position |
The value comes from connecting the information.
The real SAM data model
For enterprise Linux, the data model needs to move beyond:
Software → License
A more useful model is:
Software
↓
Instance
↓
Workload
↓
VM / Container
↓
Host
↓
Cluster
↓
Infrastructure
↓
Subscription
↓
Entitlement
↓
Contract
That model provides the context needed to perform meaningful analysis.
This is where ELP becomes much more powerful
An Effective License Position should not simply answer:
"Are we over or under licensed?"
For Red Hat, SUSE and similar vendors, it can answer much broader questions:
Compliance
Are deployments covered by the appropriate subscriptions and contractual rights?
Utilisation
Are purchased subscriptions actually being used?
Optimisation
Are there opportunities to consolidate, reallocate or reduce subscriptions?
Architecture
Is the infrastructure configured in a way that supports the organisation's chosen commercial model?
Risk
Where are there gaps in deployment or entitlement data?
Procurement
What should the organisation actually purchase at renewal?
Audit readiness
Can the organisation demonstrate how it arrived at its position?
That is a much more valuable outcome than simply producing a licence count.
SAM needs to become infrastructure-aware
The lesson isn't that traditional SAM is obsolete.
It is that traditional SAM methodologies need to evolve.
For enterprise Linux environments, a SAM practitioner needs to understand at least three layers.
Layer 1: The technology
What software is actually being used?
Layer 2: The infrastructure
Where and how is that software being consumed?
Layer 3: The commercial model
What subscription, entitlement and contractual rights govern that consumption?
Only when those three layers are connected can an organisation confidently understand its position.
The new question for SAM
The old SAM question was:
"How many licenses do we have?"
The better question is:
"How is our technology actually being consumed, what rights do we have to that consumption, and are we using those rights effectively?"
That shift is particularly important for Red Hat, SUSE and other enterprise vendors built around open-source technologies.
The software may be open source.
The infrastructure may be dynamic.
The subscription model may be complex.
But the underlying SAM principle remains the same:
Understand what you have. Understand what you are using. Understand what you are entitled to. Then make better commercial and technology decisions.
And that requires much more than counting installations.
Comments