A supported Linux server is a specific combination of hardware, operating system, firmware, drivers and service arrangements. Before installing Red Hat Enterprise Linux on an HP or HPE server, assemble evidence for that complete combination.
The HP–Red Hat relationship helped bring enterprise Linux onto industry-standard servers in the early 2000s. For an existing machine, start with the product label and management inventory: historical HP branding, a familiar model family, or a successful installation does not describe the present support commitment. This guide focuses on enterprise servers; the Linux PCs guide covers desktop and laptop selection.
Identify the exact machine and proposed change
Record the full model and generation, processor family, storage controller, network adapters and any accelerators. Add the firmware baseline, boot mode, current operating system and proposed RHEL major and minor release. A used server may have replacement components that differ from its original configuration.
Keep serial numbers and contract identifiers in a private support record. The purpose is to connect the installed machine to a precise certification entry and an accountable support route. If the inventory is incomplete, settle that before buying a subscription or scheduling downtime.
Read both vendors' evidence
Search the Red Hat certified hardware catalog for the exact system. Open its certification record and inspect the product and release scope, relevant notes and component details. Then compare it with HPE's RHEL support and certification matrix. Read the footnotes as part of the entry: platform generations and processor variants can carry additional conditions.
On a small screen, scroll the table sideways to read all columns.
| Layer | Record | Decision it supports |
|---|---|---|
| Server | Exact model, generation, processor and certification reference | Whether the proposed hardware/release combination is covered |
| Components | Storage, networking and accelerator models; required drivers | Whether essential devices have a supported path |
| Firmware | System ROM, management controller and component baseline | Whether vendor prerequisites and update dependencies are met |
| RHEL | Major/minor release, architecture and subscription scope | Which packages and maintenance policy apply |
| Application | Vendor-supported OS, database and runtime versions | Whether the workload can use the proposed platform |
When entries seem inconsistent, preserve the exact URLs and ask the vendors to resolve the proposed configuration. A matrix can establish a supported starting point; the application test establishes whether the machine performs its intended work. Record both results.
Align hardware and operating-system lifecycles
Check the RHEL lifecycle policy for the intended major release and any applicable minor-release maintenance option. Coverage can vary by phase, subscription and add-on. Keep the policy reference and the contract entitlement together, and give an owner responsibility for reviewing them before the next upgrade.
Then check the hardware service term, available firmware and management-tool support for the same period. A long OS lifecycle does not extend a server warranty or make an old adapter supported on a newer kernel. Conversely, replacing a server can force a newer operating-system baseline that an old application does not support.
Plan a viable overlap: time to build a replacement, migrate data, validate the workload and keep a tested rollback route. Use a date-based plan for expiring coverage, with a documented decision about replacement or continued operation before the deadline arrives.
Know who handles an incident
Document where the OS subscription was purchased and who provides first-line support. HPE's RHEL product information describes an activation path for subscriptions purchased through HPE. Follow the instructions supplied with the actual order and verify access to the required update and support services.
Separate hardware replacement, firmware issues, operating-system defects and application incidents in the responsibility record. Capture support hours, response commitments, escalation contacts, log-collection expectations and any partner involvement. A promised response time describes an initial service commitment; plan recovery around a tested procedure rather than treating it as guaranteed repair time.
Check console access before making a remote change. An operating-system update can succeed while the new boot loses the network route used for administration. Test the authorized management path and account access while the machine is healthy.
Validate the installed configuration
- Save a baseline inventory and the current configuration. Confirm usable backups and the intended recovery method.
- Review the planned firmware, driver and OS sequence against the vendors' documentation.
- Install or upgrade in a representative test environment and record the actual resulting versions.
- Test storage visibility, network paths, boot recovery, monitoring and the application task that matters.
- Measure workload behavior and complete a restore or recovery rehearsal before accepting the change.
The final deliverable is a supportable configuration record with evidence and an owner. Revisit it when a component, release, firmware baseline, application requirement or support agreement changes.
Keep a working record
Download the server supportability checklist (plain text). Save a copy and fill in the evidence for your own task.