Red Hat Training
A Red Hat training course is available for Red Hat Enterprise Linux
Red Hat Hardware Certification Program Policy Guide
For Use with Red Hat Hardware Certification
Abstract
Making open source more inclusive
Red Hat is committed to replacing problematic language in our code and documentation. We are beginning with these four terms: master, slave, blacklist, and whitelist. Due to the enormity of this endeavor, these changes will be gradually implemented over upcoming releases. For more details on making our language more inclusive, see our CTO Chris Wright’s message.
Chapter 1. Introduction to the Red Hat hardware certification program
Use this guide to understand the certification process, the policies pertaining to hardware certification, and the process followed by the Red Hat Hardware Certification Team to create hardware test plans.
1.1. Audience
The Red Hat Hardware Certification Program Policy Guide is intended for hardware vendors interested in certifying hardware with Red Hat. A strong working knowledge of Red Hat Enterprise Linux is required. A Red Hat Certified Engineer accreditation is preferred and suggested before participating.
1.2. Overview of the program
The Red Hat Hardware Certification Program provides a formal means for you to work with Red Hat to establish official support for your hardware. Certified hardware is supported by Red Hat’s Global Support Services (GSS) and is published in the Red Hat Certification Ecosystem Catalog.
During the certification process, Red Hat engineers create a test plan that defines the hardware criteria required to achieve certification. Red Hat engineers follow the process described in Overview of test plan to create a test plan suitable for your hardware specifications.
A description of the hardware certification process can be found in the Overview of certification process.
1.3. Certification prerequisites
To verify that you are eligible to join the Hardware Certification Program, a summary of the most important policies are as follows:
- Red Hat certifies hardware models, but not specific configurations of a model. You must test all optional hardware configurations that are designated as part of the same model.
- You must test your hardware on a standard installation of Red Hat Enterprise Linux (RHEL) with no special configuration or additional software. Do not install drivers that are not provided by Red Hat.
Certifications are currently available for:
- RHEL versions 7, 8, and 9.
- Red Hat OpenStack Platform for compute nodes and bare metal.
- Red Hat Enterprise Linux for Real Time versions 7, 8, and 9.
- Red Hat OpenShift Container Platform for working nodes and IPI systems.
- Red Hat Virtualization 4.
The IBM Power (little endian) architecture requires an approved collaborative partnership established to be eligible for certification. Consult your engineering partner manager (EPM) for more information.
Additional resources
- For more information about supported architectures, see RHEL versions and architectures.
- For more information about certification policies, see Hardware certification policies.
Chapter 2. Overview of certification process
Prerequisites
- Establish a certification relationship with Red Hat.
- Establish a test environment consisting of your product and the Red Hat product combination to be certified.
- Perform preliminary testing to ensure this combination works well.
- Install the redhat-certification tool.
Procedure
- Create a certification request for a specific system or hardware component using redhat-certification.
- Red Hat’s certification team applies the certification policies to the hardware specifications to create the official test plan.
- Run the tests specified in the official test plan and submit results using redhat-certification to Red Hat for analysis.
- The certification team analyzes the test results and marking credit as appropriate and communicating any required retesting.
- Provide Red Hat with a representative hardware sample that covers the items that are being certified.
When all tests have passing results, the certification is complete and the entry is made visible to the public on the external Red Hat Hardware Certification website at Certifications.
Additional resources
For more information about hardware certification process, see Hardware Certification Program Overview section of the Hardware Certification Test Suite User Guide.
Chapter 3. Hardware certification policies
3.1. Program policies
3.1.1. Policy changes
Typically, Red Hat limits major revisions in the certification tests and criteria to major releases of Red Hat Enterprise Linux.
Red Hat might also release updates to the Hardware Certification policy, criteria, and/or test suite(s) at any point, including at minor OS releases, where new hardware support features are introduced, or any other point as deemed necessary.
Only a single version of the policy is active at any one time. This current policy is effective upon its release and supersedes all previous versions.
The Policy Guide version applied during the certification process will be recorded in certifications upon successful completion.
Changes to the policy or criteria will be sent as a notification to the hwcert-announce-list@redhat.com mailing list. Subscribe to the list via the web interface (https://www.redhat.com/mailman/listinfo/hwcert-announce-list).
Changes to the test suite will also be documented in the test suite errata notification and package changelog.
3.1.2. Certification lifecycle
The certification life cycle starts when Red Hat awards a certification to a combination of a hardware system or component and a specific architecture and version of RHEL. A hardware system or component will retain its certification until one of the following occurs:
- Recertification is required.
- Red Hat no longer supports that version of RHEL.
- You cease participation in the Hardware Program.
This life cycle policy also applies to layered certifications.
3.1.2.1. Additional resources
3.1.3. Submission window
New hardware certifications for a given, major release of Red Hat Enterprise Linux can typically be submitted until the 2nd, subsequent major version of Red Hat Enterprise Linux is released.
A notice will typically be sent to the hwcert-announce@redhat.com mailing list 30 days in advance announcing the upcoming closing of the window. Planning for each of these window closures should be done in coordination with your Enterprise Partner Manager.
Certification requests that fall outside of the normal window must be raised with your Enterprise Partner Manager.
These requests are reviewed on a case-by-case basis. Certification requests beyond the submission window must not require additional updates to the operating system.
During the period leading up to the release of a new major version of Red Hat Enterprise Linux, partners may elect to begin certification testing using the release candidate media. This option allows these vendors to potentially have systems certified at the launch of the new product.
Further testing may be required if significant changes exist between the release candidate and general availability versions. The certification will not be published until the GA version is officially released.
3.1.4. Original certifications
Partner support of certified hardware is a fundamental part of Red Hat Hardware Certification. All requests and information about the hardware to be certified must be submitted by the original hardware manufacturer to Red Hat.
Hardware partners can use their own outside partners for any portion of their hardware and testing but all benefits and additional costs are the responsibility of the partner.
Red Hat will only interact with the partner who submitted the certification request and will only post original certifications with a vendor+make+model value easily identifiable by Red Hat as the submitting partner.
3.1.5. Unpublished certifications
All hardware certification requests submitted to Red Hat are presumed to be requests for published entries on the Hardware Catalog. Certifications can remain unpublished, where the certification is not already published on the Hardware Catalog, upon request by the partner.
Unpublished certifications follow the same policies as published certifications but are not made available on the Internet.
Certification requests that fail to meet the certification criteria will remain unpublished in all cases.
Requests to keep a certification unpublished should be made in the comment dialog of the certification request when the certification is initially opened.
A comment may be provided within the unpublished certification for content normally provided by a Red Hat Article or Solution.
3.1.6. Component Leveraging
In order to maximize the efficiency of the Hardware Certification testing process, Red Hat allows Hardware Certification Partners to reuse, or leverage, specific test cases for the same (or later minor) release and architecture of Red Hat Enterprise Linux to satisfy test plan requirements where components are reused between similar models.
You are required to have a Red Hat Enterprise Linux quality assurance (QA) process that encompasses all hardware to be certified with leveraging. This QA process is in turn leveraged by Red Hat to offer this feature, as such partners cannot leverage testing of other partners except as described in Component Pass-Through certifications. Additional requirements for leveraging are provided in Hardware class requirements.
3.1.7. Component Leverage Pools
A leverage pool is a series of unpublished component certifications performed by a system vendor for the purpose of establishing a list of components intended for use via leveraging during later system certifications. The following conditions apply to leverage pools:
- Leverage pool certifications certifications are required to pass the regular certification criteria for the component.
- Leverage Pool certifications should be opened using the normal Create page in the Hardware Catalog.
- A comment should be added requesting the type of certification to be set to Leverage Pool.
- Only a single component can be in a leverage pool certification.
- To utilize a leverage pool certification test result in a system certification, the certification ID of the leverage pool certification should be provided in the system certification test plan leverage field.
3.1.8. System Pass-Through certifications
A Pass-Through Certification refers to the ability of a third party system or component to be granted the same certification as hardware previously certified by the original hardware manufacturer.
System manufacturers can extend a certification granted to their systems to another vendor’s system where the original vendor
- has permission from the third party,
- has the mechanics to ensure the third party does not alter the hardware in such a way that it would no longer be considered a subset of the original model certified by Red Hat, and
- extends their responsibilities of support and representative hardware to include situations involving the third party hardware (refer to sections 1.2 and 1.3 of the Hardware Certification Agreement).
The third party cannot then extend their pass-through certification to another vendor. While both vendors are required to be members of the Hardware Certification program, only the original vendor may request pass-through certifications.
Pass-through requests should be opened using the Pass-Through dialog under the Advanced tab in the Hardware Catalog entry of the original certification.
Vendors may also utilize the pass-through process where the same vendor has multiple names for the same hardware.
3.1.9. Component Pass-Through certifications
Component vendors may utilize the pass-through process where the component vendor
(a) has permission from the third party
(b) has the mechanics to ensure the third party does not alter the hardware
(c) extends their responsibilities of support and representative hardware to include situations involving the third party hardware (refer to sections 1.2 and 1.3 of the Hardware Certification Agreement).
Third-party vendors may not extend their pass-through certification to another vendor. While both vendors are required to be members of the Hardware Certification program, only the original component vendor may request pass-through certifications. The original and pass-through certifications may be published or unpublished.
Third party system vendors may choose to leverage these component certifications in their system certifications for standard PCIe form factor Ethernet, Fibre Channel, Infiniband, iSCSI, SATA, SAS, RAID, CNA, and WLAN option cards.
The regular leverage policies apply to the system certification leveraging the component pass-through certification, including the internal QE process encompasses all hardware to be certified with leveraging. Component pass-through certifications may also follow the leverage pool policies (see Program policies component leveraging pool).
Component pass-through certifications are opened using the Pass-Through dialog under the Advanced tab in the Hardware Catalog entry of the original component certification by the original component vendor.
Upon successful completion, the pass-through certification will be made available to the system vendor. The system vendor may then provide the pass-through certification ID as the leverage value in their system certification test plan.
3.1.10. Recertification
Changes to the model that would alter the original test plan criteria require re-certification. Model changes include hardware, BIOS, or firmware.
Example
An increase to the number of CPUs supported or the addition of new components such as network or storage controllers requires re-certification.
A new supplemental certification should be opened to process the hardware changes.
Additional resources
- For more information about test plan criteria, see Overview of test plan.
3.1.11. Known issues
A model must have no known major issues with Red Hat Enterprise Linux. As part of the certification process, Red Hat will investigate to ensure that no significant unresolved customer-impacting issues exist.
3.1.12. Sample Hardware
Representative hardware samples are required by Red Hat Engineering and Support in both self-tested and Red Hat-tested certifications. This hardware is utilized by Red Hat to verify, debug, and fix customer issues and/or in future product testing. Be aware of the following conditions regarding hardware samples:
- Hardware samples should be of configurations that provide full functionality of all model features.
- The prescribed test plan (see Overview of test plan) can be used as a minimum configuration guideline; however, Red Hat Support might request specific configurations depending on the particular hardware, planned customer deployments, and other factors.
- Hardware samples should additionally include any required accessories for proper installation and operation.
- Hardware must be present at a Red Hat location before certification posting.
- Red Hat Support might accept the promise of future delivery of hardware at their discretion.
- Your Technical Account Manager (TAM) or support representative can provide location and configuration details and should be consulted prior to shipment of hardware.
3.2. Policies for RHEL certifications
The following policies apply to Red Hat Enterprise Linux (RHEL) certifications:
3.2.1. Supported RHEL version and architecture
A hardware certification is specific to a major RHEL version and a processor architecture. The certification is valid from the posted minor version forward until the next major version. It does not carry over to the next or previous major versions or other architectures.
For RHEL 7, certifications apply to all variants of the same version and architecture.
The following table shows the RHEL versions and architectures that can be combined in a certification:
| RHEL version | Architecture |
|---|---|
| RHEL 9 |
|
| RHEL 8 |
|
| RHEL 7 |
|
From RHEL 9.2 onwards, RHEL for ARM includes an optional kernel supporting a 64k page size. Partners interested in certification with the 64k page size, first need to complete a RHEL 9 certification using the default 4k kernel, then conduct a second certification with the 64k kernel. Leveraging is not supported between the 4k and 64k certifications. After successful completion of the 64k certification a Knowledgebase article will be attached to the 4k certification indicating support for the 64k page size with instructions on how to use the 64k kernel.
3.2.2. System and component certification
At the start of the certification process, you must provide a specification for the hardware model that you want to certify. Model specifications must include factory-standard and optional components. Additional hardware specified as compatible with the model may be included on the specification, but must be identifiable by customers as separate from the model.
Red Hat awards a hardware certification to a system or a component:
- A system is hardware that can boot, install, and operate RHEL.
- A component is hardware that can be utilized as a subset of a system which can boot, install, and operate RHEL.
Based on the specification, Red Hat will create a test plan to certify the component or system with RHEL.
Certification success criteria
Certification is successful when the program requirements and the model specific test plan criteria are met.
If you consider that the certification test plan does not meet your requirements, submit a request for an exception by adding a comment in your certification.
3.2.3. Catalog publication
A certification that meets the success criteria can be published in the Red Hat Ecosystem Catalog. However, Red Hat will only make public those hardware certification entries that are awarded to products that have reached general availability (GA).
The Red Hat Catalog displays certifications differently depending on the RHEL version. Certification publications for RHEL 8 or RHEL 9 that are published in the catalog will show the features that were listed within the test plan alongside one of the following statuses:
- Supported: Tested and pass, or tested and pass with a condition.
- Not Supported: Tested and failed, or not tested.
For RHEL 7, the catalog displays a basic view of the certified hardware that does not include a feature list of your system.
3.2.4. Catalog search results
When a customer searches for a product by features, your product will appear in the search results only when a supported feature in your product’s certification matches the features in the search request. This allows customers to find hardware that is certified for their required features.
Features that are either not tested or that did not pass when the system was certified can be updated using a supplemental certification for the system. Once certified, the additional features will be added to the certification catalog entry for RHEL 8 or RHEL 9 as appropriate.
3.3. Policies for layered product certifications
Layered product certifications are additional certifications awarded to systems already certified for RHEL.
Red Hat offers the following layered certifications:
- Red Hat Enterprise Linux for Real Time
- Red Hat Virtualization
- Red Hat OpenStack Platform Compute
- Red Hat OpenStack Platform Bare Metal
- Red Hat OpenStack Platform for Real-Time Applications
- Red Hat OpenShift Container Platform
- Red Hat OpenShift Container Platform Bare Metal
3.3.1. Red Hat Enterprise Linux for Real-Time
| Supported RHEL versions | Supported RHEL for Real Time versions | Prerequisite certifications |
|---|---|---|
| 7, 8, and 9 | 7, 8, and 9 | RHEL |
Apply for the Red Hat Enterprise Linux for Real Time certification after your system has been awarded the prerequisite certifications detailed in the previous table.
The Red Hat Hardware Certification test suite includes the necessary test to obtain a Real Time certification.
For more information, see Hardware class requirements.
3.3.1.1. Additional resources
3.3.2. Red Hat Virtualization
| Supported RHEL versions | Supported RHEL for Real Time versions | Prerequisite certifications |
|---|---|---|
| 7 and 8 | 7 and 8 | RHEL |
Red Hat Virtualization relies on and is co-engineered with RHEL. As a result of this common base, if your system passes the basic virtualization tests during the Red Hat Enterprise Linux certification, you do not need to run additional tests to receive the Red Hat Virtualization certification. If your system also passes the advanced virtualization tests, your Red Hat Virtualization certification will automatically also include the advanced features.
Red Hat will open the Red Hat Virtualization certification on your behalf automatically for all 64-bit Intel and AMD, and all IBM Power little endian server certifications submitted for RHEL.
If you want but did not automatically receive the certification, create a new layered certification request for the Red Hat Virtualization product.
3.3.2.1. Additional resources
3.3.3. Red Hat Enterprise Linux OpenStack Platform Compute
| Supported RHEL versions | Supported RHEL for Real Time versions | Prerequisite certifications |
|---|---|---|
| 8 and 9 | RHEL (basic virtualization tests must have passed) |
Red Hat OpenStack Platform relies on and is co-engineered with RHEL. As a result of this common base, you do not need to run additional tests to receive the Red Hat OpenStack Platform Compute certification if your system meets prerequisite certifications detailed in the previous table. You also do not need to open a new certification.
However, for Red Hat OpenStack Platform RHEL 8, layered product certification specifically applies to POWER systems that are not LPAR (logical partition) based. To qualify for layered product certification on RHEL 8, the system must function as a bare metal hypervisor during testing.
For RHEL 9, Red Hat doesn’t support KVM on POWER systems. Hence there is no creation of virtualization-based layered product certifications.
For other architectures or categories, or in any situation where you want but did not automatically receive the certification, create a new layered certification request for the Red Hat OpenStack Platform Compute product.
Red Hat encourages partners certifying systems with baseboard management controllers (BMC) to apply for the Red Hat OpenStack Platform Bare Metal certification as well.
3.3.4. Red Hat OpenStack Platform for Real-Time Applications
| Supported RHEL versions | Supported RHEL for Real Time versions | Prerequisite certifications |
|---|---|---|
| 8 |
|
Apply for the Red Hat OpenStack Platform for Real-Time Applications certification after has been awarded the prerequisite certifications detailed in the previous table. The Red Hat Hardware Certification test suite includes the necessary test to obtain a Real Time certification.
3.3.5. Red Hat OpenShift Container Platform
| Supported RHEL versions | Supported RHEL for Real Time versions | Prerequisite certifications |
|---|---|---|
| 9.2, 9.3, and 9.4 (RHOCP 4.13, 4.14, or 4.15) | RHEL (basic virtualization tests must have passed) | |
| 8 (RHOCP 4.12) | RHEL (basic virtualization tests must have passed) |
Red Hat OpenShift Container Platform relies on and is co-engineered with RHEL. As a result of this common base, you do not need to run additional tests to receive the Red Hat OpenShift Container Platform certification if your system meets prerequisite certifications detailed in the previous table.
However, for Red Hat OpenShift Container Platform, supported versions based on RHEL 8 (currently v4.11 and v4.12), layered product certification specifically applies to POWER systems that are not LPAR (logical partition) based. To qualify for layered product certification on RHEL 8, the system must function as a bare metal hypervisor during testing.
For RHEL 9, Red Hat doesn’t support KVM on POWER systems. Hence there is no creation of virtualization-based layered product certifications.
For other architectures or categories, or in any situation where you want but did not automatically receive the certification, create a new layered certification request for the Red Hat OpenShift Container Platform product.
Apply for the Red Hat OpenShift Platform Bare Metal certification to add IPI and assisted installer capabilities to the RHOCP entry in the catalog.
3.4. Software Policies
3.4.1. Test Suite Versions
Red Hat recommends that the latest version of the test suite packages be used for all testing. When a new version of any test suite package is made available, results created using previous versions will continue to be accepted for a period of three months. At the end of this period the Hardware Catalog will automatically reject result packages created with the older versions and testing will need to be repeated with valid packages. The current valid package versions are displayed on the results package submission form.
The test suite should not be modified for certification test runs. The test suite will perform a self check and will fail the supportable test if modified.
3.4.2. Red Hat Enterprise Linux Versions
The latest minor release of Red Hat Enterprise Linux version is always recommended; however, any release that satisfies the full testing criteria may be used. Testing on the earliest fully-supported release will maximize the potential customer base. If multiple minor releases are used during testing, the newest minor release will be used as the posted release for the model. Depending on the features of a given model a minimum release may be required other than what is desired.
Red Hat Enterprise Linux should not be updated with errata packages except when recommended by the Red Hat Hardware Certification Review team or in accordance with the software driver policies. Any testing performed with unnecessary errata installed may require retesting.
The test suite is only tested against Red Hat Enterprise Linux 7 Server, Red Hat Enterprise Linux 8 Base OS, and Red Hat Enterprise Linux 9 Base OS. All variants of Red Hat Enterprise Linux (Workstation, Desktop, etc.) of the same major version share a common core set of packages. Use of these variants is allowed during certification testing, however they may only provide a subset of the required packages which may result in the need for retesting.
Technical assistance during certification is not offered when using these variants.
Configure the OS as explained in the appropriate RHEL kickstart file available at http://people.redhat.com/gcase/rhcert-2/ks/.
3.4.3. Red Hat Enterprise Linux for Real-Time Versions
Red Hat Enterprise Linux for Real-Time test results are only accepted on the current minor release of the Realtime product installed on the current and previous minor release of the corresponding Red Hat Enterprise Linux. When a new Red Hat Enterprise Linux for Real-Time minor release is made available results on the previous minor Realtime release will continue to be accepted for a period of 30 days.
3.4.4. Unmodified Red Hat Enterprise Linux
The Red Hat Hardware Certification Program requires testing on a standard installation of Red Hat Enterprise Linux with-out any modifications. Changes to the default configuration presented by the installer and first boot utilities are allowed when the configuration change can be made using one of the standard system tools and when the default configuration does not create the potential for data loss. Required changes to the default configuration must be documented in a Red Hat Knowledge Base Solution that is associated with the certification listing. A customer purchasing a Red Hat certified system can therefore be confident the system will work as expected with a standard installation of Red Hat Enterprise Linux.
3.4.5. Kernel boot parameters
Kernel boot parameters are additional parameters that you can utilize to correct hardware configuration. These parameters can be used if they:
- Do not disable the functionality.
- Do not expose the potential for data loss when not in use.
Example
If the kernel parameter noacpi is required to boot a system that does not install without that parameter, this would likely be acceptable. However, if the system would install but corrupts data over time when noacpi is not specified, the certification would be suspended until the the situation is resolved. Additional kernel parameters utilized during the certification can be documented in Red Hat knowledge base solution and the solution can be linked to the certification listing for clarity.
3.4.6. Kernel taint values
Red Hat expects partners to conduct hardware certification testing on systems running kernels that have not been tainted (value of 0). Non-zero values of tainted kernels may be acceptable when a result of supported and required kernel driver is from the Red Hat Driver Update Program or a cosmetic benign kernel warning. Any non-zero taint value approved during certification will be documented in a Red Hat knowledge base Solution associated with the certification publication.
3.4.7. Drivers
Red Hat may provide drivers as a Technology Preview, granting early access to upcoming product innovations. These drivers are not fully supported and cannot be used to achieve certification (see Technology Preview features support scope). Drivers are designated as technology preview in the release notes of the Red Hat Enterprise Linux product documentation.
Red Hat recognizes that it is not possible for some drivers to be included within Red Hat Enterprise Linux. While use of additional drivers is discouraged, in certain cases such drivers may be used during the certification process. These cases include the following:
- When the driver is included in an official Red Hat Errata and is not required for boot or installation testing (see Hardware class requirements) OR
- When the driver is included in an official Red Hat Enterprise Linux Driver Update Disk OR
- When the driver is for use with optional hardware (see Certification policies) that is not required to be tested to complete the certification.
A knowledge base entry will be associated with all certifications where Driver Update Program is used.
Additional drivers not officially shipped by Red Hat that are used in hardware certifications should be built using the standard kmod process as described on kerneldrivers.org, only use approved symbols, must not add subsystems, and must not replace nor conflict with any Red Hat provided driver. Providing hardware support already present in a Red Hat provided driver is considered a conflict. No quality nor source review shall be performed by Red Hat on any additional driver.
Where additional driver use is believe valid, a comment should be added to the certification request including the name of the driver, the hardware which requires the driver, if the above driver construction recommendations are met, the vendor URL address to the driver information and End User Customer Support information (where applicable) when the certification is opened.
Technology preview drivers are not supported by Red Hat and may be not be used during certification.
Testing must be conducted without the use of the additional and technology preview drivers when possible. The supportable test will return a failure for all technology preview and non Red Hat provided drivers.
Drivers not provided in the Red Hat Enterprise MRG Realtime or Red Hat Enterprise Linux for Realtime kernel are not allowed during Realtime testing, this includes Red Hat provided driver disks, tech preview driver packages, and third party drivers.
The above requirements do not themselves preclude vendors from offering or installing alternative open source, proprietary, binary, source code, or other drivers with their certified hardware. The criteria is meant only to apply to Red Hat Hardware Certification testing and listings.
3.4.8. SELinux
Certifications must be run with SELinux enabled using the Targeted Policy and with Enforcing on. The test suite will check for these conditions.
3.4.9. Red Hat Enterprise Linux as a KVM host
RHEL certifications test whether your system can host kernel virtual machines (KVMs). The hardware certification test plan contains the following virtualization tests:
- System Virtualization tests: Mandatory for the Red Hat Enterprise Linux certification.
- Advanced System Virtualization tests: Recommended for the Red Hat Virtualization certification. Passing the advanced system virtualization tests will add more features to the Red Hat Virtualization certification.
Both the basic and advanced tests are planned for the RHEL certification.
KVM virtualization tests are planned for:
- ARM, beginning with RHEL 9.4.
KVM virtualization tests are not planned for:
- IBM z, on RHEL 7 systems.
3.4.9.1. Additional resources
- For more information about the virtualization tests, see System virtualization and Advanced system virtualization in the System Processors table.
3.4.10. Red Hat Enterprise Linux as a guest
Certifications involving Red Hat Enterprise Linux in a virtualized environment may only occur where approved collaborative partnerships have been established (see your Partner Manager for details). All policies and criteria, including recertification, apply to the virtualized hardware as presented to Red Hat Enterprise Linux. Changes to the underlying hardware and/or virtualization layers are the responsibility of the vendor to disclose and test as appropriate.
3.5. BIOS and Firmware Policies
3.5.1. Production level
BIOS/Firmware versions are required to be production-level during testing.
Example
Feature complete without major changes pending.
BIOS/Firmware changes subsequent to testing are required to meet the BIOS/Firmware policy changes criteria. The tested or subsequent revision is required to be available to customers by the posting date of the certification.
3.5.2. Changes
BIOS/Firmware changes that enable or disable features necessitate re-certification. Re-certification is not required for BIOS changes to correct bugs and/or alter superficial items like splash screens. Vendor internal testing of these changes to verify they do not adversely affect the hardware, Red Hat Enterprise Linux, or the certification status is required, but the results of this testing is not required to be submitted to Red Hat.
3.5.3. Settings
Any required BIOS/Firmware configuration information must be provided in a comment in the certification request. Providing suggested and/or default configuration data is encouraged but not required. Vendor provided configuration information may be provided in the certification listing using an associated Red Hat Knowledge Base Solution. Validating alternate configuration settings do not expose data corruption issues or unexpectedly disrupt functionality is the responsibility of the hardware vendor.
User configurable BIOS settings that enable/disable hardware features and/or functions must be set such that the feature or function is enabled during testing. For example, a setting to control on-board networking must be configured to enable the network interface.
3.5.4. OS Loaded
Firmware that is loaded via supported mechanisms of the OS may be used where they follow the guidelines above and have a perma-link to the supported binary RPM packages. OS Loaded firmware not included with the Red Hat product will be documented in a Red Hat Knowledge Base Solution associated to the certification listing.
3.5.5. Hardware Health subtest
The Hardware Health subtest checks the system’s health by testing if the hardware is supported, meets the requirements, and has any known hardware vulnerabilities. The subtest does the following:
Checks that the Red Hat Enterprise Linux (RHEL) kernel does not identify hardware as unsupported. When the kernel identifies unsupported hardware, it will display an unsupported hardware message in the system logs and/or trigger an unsupported kernel taint. This subtest prevents customers from possible production risks which may arise from running Red Hat products on unsupported configurations and environments.
In hypervisor, partitioning, cloud instances, and other virtual machine situations, the kernel may trigger an unsupported hardware message or taint based on the hardware data presented to RHEL by the virtual machine (VM).
Checks that the Host Under Test (HUT) meets the minimum hardware requirements.
- RHEL 8 and 9: Minimum system RAM should be 1.5GB, per CPU logical core count.
- RHEL 7: Minimum system RAM should be 1GB, per CPU logical core count.
- Checks if the kernel has reported any known hardware vulnerabilities, if those vulnerabilities have mitigations and if those mitigations have resolved the vulnerability. Many mitigations are automatic to ensure that customers do not need to take active steps to resolve vulnerabilities. In some cases this is not possible; where most of these remaining cases require changes to the configuration of the system BIOS/firmware which may not be modifiable by customers in all situations.
- Confirms the system does not have any offline CPUs.
- Confirms if Simultaneous Multithreading (SMT) is available, enabled, and active in the system.
Failing any of these tests will result in a WARN from the test suite and should be verified by the partner to have correct and intended behavior.
Success criteria
- The kernel does not have the UNSUPPORTEDHARDWARE taint bit set.
- The kernel does not report an unsupported hardware system message.
- The kernel should not report any vulnerabilities with mitigations as vulnerable.
- The kernel does not report the logic core to installed memory ratio as out of range.
- The kernel does not report CPUs in an offline state.
3.6. Hardware policies
3.6.1. Stand-Alone
A model must include all hardware and software to enable full functionality in a Red Hat Enterprise Linux-only environment. For example, a system that requires a management console to boot and/or be configured, would not qualify for certification if the console was only accessible via Internet Explorer on another system.
3.6.2. Components and peripherals
Components and peripherals to be listed independently are required be tested with Virtualization if available on the architecture. Components listed in the hardware catalog carry a generic disclaimer informing customers that while the component has demonstrated compatibility with Red Hat Enterprise Linux, we cannot guarantee that it will work in a specific system and the customer should contact their system vendor to ensure compatibility.
3.6.3. Production level
The Red Hat Hardware Certification Program requires testing with production level hardware. Preproduction hardware which has been upgraded to production level equivalent is also acceptable.
3.6.4. Changes
Certified models may not be altered such that a regression in the certification testing results or change in criteria occurs. Minor changes that do not add or alter features or functionality are expected to be tested by the vendor but are not required to be resubmitted. For example cable length or passive backplane port count changes. Vendors are expected to notify Red Hat of any significant changes including those which add features or functions. If re-certification is required, a new supplemental certification entry should be opened from the original certification. Any additional testing required should be performed using the same Red Hat Enterprise Linux version as the original submissions. Where a version mismatch occurs between the updated testing and the original submission, a Red Hat Knowledge Base article may be associated with the original certification for clarity. Supplemental certifications are processed in queue with other certifications, but are not published.
3.6.5. Configuration limits
Models available in configurations beyond the Red Hat product limits may still be eligible for certification. Testing will need to be performed demonstrating the model within the limits by manual or automatic configuration, for example the kernel automatically ignores memory beyond the limit, or CPU’s above the limit, etc. Manual configuration follows the standard configuration and kernel parameters policies. A Red Hat Knowledge Base article may be added to the certification listing for clarity.
Vendors are encouraged to work with their Hardware Partner Manager and Partner TAMs on feature requests to raise the relevant Red Hat Enterprise Linux product limits prior the certification effort. Like all Red Hat Enterprise Linux feature requests the required time lines, development, and testing efforts are determined on a case-by-case basis outside of the certification process.
The current supported limits for Red Hat Enterprise Linux are listed here: https://access.redhat.com/articles/rhel-limits.
3.6.6. Performance minimums
In general, Red Hat Hardware Certification places the responsibility of performance testing on the hardware vendor; however, major performance issues that are deemed to have significant customer impact may delay certification until a resolution is determined.
3.6.7. External industry standards and certifications
Red Hat expects hardware partners will conduct relevant testing and certifications to meet applicable government, market, and industry standards for their hardware outside of the Red Hardware Certification program. Red Hat will not do a specific evaluation or verification that such standards or certifications have been met or awarded except for how the same relates to the interoperability and functionality of the hardware with Red Hat products.
Standards such as but not limited to PCI-SIG, USB-SIG, ARM Server Ready, CE, FCC, etc. are independent from Red Hat and the responsibility of the hardware partner to archive or obtain as warranted.
Chapter 4. Creating a test plan
4.1. Overview of test plan
A hardware certification engineer creates a test plan by following these steps:
- Define the model by its specification.
- Determine the option.
- Remove unsupported operating system features and unintentional hardware.
- Apply the minimum test set criteria.
- Add the install, boot, and kdump requirements.
- Add additional policy requirements.
After performing the steps above, the items remaining determine the test plan for your hardware. The Hardware Catalog records the test plan under the Test Plan Progress.
Additional resources
- For more information about defining the testing required for each hardware class item, see Hardware class requirements.
Red Hat Hardware Certification Test Plans are not meant to substitute for proper and complete internal quality assurance testing, criteria, and processes. Each vendor is responsible for their own internal shipment criteria and is encouraged to do testing in excess of the required certification test plan items.
4.2. Models
The Red Hat Hardware Certification program certifies entire hardware models, rather than specific configurations of models. A model includes all Integrated Hardware and Optional Hardware as described by the Hardware Partner in the hardware specification.
4.2.1. Model names
Model names are required to be unique and have a particular hardware specification.
The Red Hat Hardware Certification program supports tiered naming schemes. A tiered naming scheme is any naming scheme that includes a hierarchical collection of models and submodels. When employing tiered naming schemes for the purposes of certification the specification is considered to include all submodels which would reasonably be represented by the name provided in the certification request.
For example; consider three model names: 3000, 3000a, and 3000s. If 3000 represents the collection that includes the 3000a and 3000s models, submitting 3000 as the model name incorporates the specifications of 3000a and 3000s. Conversely, if 3000s is submitted, the specification is limited to only the hardware detailed in the 3000s specification. In cases where 3000 is a distinct model separate from 3000a and 3000s, the certification will only consider the hardware outlined in the 3000 specification. The published model name may be altered for clarity in certain situations. Any changes should be discussed during the certification process and prior to publication. Such alterations are made at the discretion of Red Hat.
4.3. Specifications
To maintain consistency and accuracy in hardware specifications, ensure to provide the same specifications to both Red Hat and customers. Also, follow the listed guidelines to guarantee precise and comprehensive hardware specifications:
- Provide a publicly accessible URL containing all available specifications for the hardware. This URL should host the finalized, public specifications. Early specifications can be submitted before the product’s official launch, even in different formats. However, these early specifications must align with the format and structure of the final customer specifications, as Red Hat will validate them against the finalized public specifications before publication.
- For any generalized specifications, you must provide precise and detailed information to Red Hat. For example, while mentioning "10gig Ethernet," you must specify the manufacturer such as Broadcom, Intel, Mellanox, or any other specific variant. Additionally, we recommend including the specific device model, like 'Intel 40GbE XL710-QDA’, this allows Red Hat in creating test plans more efficiently.
- In cases where generalized specifications can be interpreted in multiple ways or cover a range of possibilities, you must provide clear details to Red Hat. For example, if your hardware can potentially support up to 80 cores, but you intend to offer only 40 cores, Red Hat will consider the 40-core limit for certification purposes. However, If you plan to offer more than 40 cores to customers, a supplemental certification will be necessary before such configurations can be made available.
4.4. Types of options
It is important to understand the different types of options that can be associated with a model when certifying hardware. These options help define what components are included and how they impact the certification process.
4.4.1. Integrated hardware
Integrated Hardware is the hardware required to be present in all configurations of a model. All integrated hardware components, including CPU options, memory options, integrated graphic controllers, integrated displays, and other non-field-removable hardware within a model, must be tested. This includes features integrated into System-on-Chip (SoC), System-in-Package (SiP), and other fully or partially integrated system solution designs. Specific portions of integrated hardware may be exempted from the certification if they provide features that meet the exclusion criteria specified in the non-os features and system processors table section.
4.4.2. Optional hardware
Optional Hardware is hardware that is present in some configurations of a model.
Testing of Optional Hardware is not required in the following conditions:
- The Optional Hardware is field removable.
- It does not provide a unique function within the model [1]
- It is clearly indicated for use with another operating system [2]
- It is clearly marked to disclose any Service Level impacts, as necessary, on either the model specification or the model support URL, and on all materials using the Red Hat Hardware Certification marks in association with the model.
4.4.3. Additional hardware
Additional Hardware is hardware that can be purchased in addition to but is not included as part of any configuration of the model and is not required to be tested. Additional Hardware may appear on the model specification but must be clearly identifiable. Check KB articles attached to the certification listing of the particular additional hardware for more information.
4.4.4. Special cases
The Hardware policy changes may be used when Optional Hardware or a series of CPUs causes a minor release higher than initially desired during the original certification process. This may allow the testing and posting of the model with the desired release along with the associated Red Hat Knowledge Base Article to reflect the higher release required by the Optional Hardware or CPUs.
4.5. Non-OS features and unintentional features
Hardware feature classes not offered by the operating system are not required to be tested if the remaining hardware continues to be fully functional. A Red Hat Knowledge Base Article may be added to the certification listing for clarity.
An Unintentional Feature is defined as any feature offered on integrated or optional hardware that is not intentionally included by the hardware partner. This feature must not be mentioned in the hardware specification unless it is called out as not supported. Unintentional features can not be supported by the hardware partner on any OS. Unintentional features are not required to be tested if the remaining hardware continues to be fully functional, even if the provided feature is unique. We recommend that unintentional features are masked from end users where possible, i.e. by disabling or removing features from the BIOS, not providing power, not including connectors, headers, etc. to minimize confusion. A Red Hat Knowledge Base Article may be added to add clarity. Changes to unintentional features are considered to be hardware changes and subject to the hardware changes policies and requirements.
Unintentional features can also cover items that are not available on all architectures.
Example
If an Infiniband storage controller were supported by a system vendor on the Intel 64 and AMD64 architecture only, the controller could be considered an unintentional feature for the system’s i386 certification. The feature must not be supported on any i386 architecture operating system for the unintentional feature status to be granted.
4.6. Minimum Test Set
The Red Hat Hardware Certification program encourages testing with all configurations including the maximum and minimum supported configuration of your hardware. It is also recognized that resourcing these configuration can be difficult due to availability, cost, timing, and other constraints.
For these reasons we have defined a minimum requirements policy by hardware class in the Hardware class requirements. This column in combination with Component, Component leveraging pool and Component Pass-Through certifications.
The minimum testing requirements are not intended as product release criteria and it is expected that internal Red Hat Enterprise Linux and other Red Hat product interoperability, and qualification testing is conducted in addition to and prior to certification testing.
All hardware used during testing is required to be part of the model specification. Similar hardware that might otherwise qualify as part of the minimum test set if it were part of the model is not accepted. For example, only those CPUs which appear in the model specification may be used. Results from other members of the same CPU product family are not accepted.
The maximum supported limits for Red Hat Enterprise Linux are defined at https://access.redhat.com/articles/rhel-limits.
4.7. Installation, Boot, and Kdump requirements
The installation of Red Hat Enterprise Linux may require testing via a number of mediums (Optical Media and Network for example). Additionally, all boot devices must be tested to ensure a successful boot of Red Hat Enterprise Linux. The Hardware class requirements table shows the hardware that requires installation and boot testing. A complete installation is not required to fulfill the boot testing requirement.
For increased testing efficiency, Red Hat recommends combining boot and install testing where possible. For example, booting from the Red Hat Enterprise Linux installation media on a CD and performing a full installation fulfills the CD boot and installation testing requirement.
Kdump is utilized in the event of a crash to capture the state of the previous kernel. This feature is enabled by default and must be tested to ensure this critical information can be captured properly to debug issues.
Kdump testing is required on an integrated storage controller and an integrated network adapter when these items are available in the model. These requirements apply to all RHEL certifications.
4.8. Hardware class requirements
Hardware Requirements by Class
The Hardware Class Requirements are categorized in Compute, Management, Network, and Storage.
4.8.1. Compute
The hardware features that are included in Compute are:
Table 4.1. System Processors
| Hardware Class | Catalog Features | Required Tests | Required Hardware | Install, Boot, kdump |
|---|---|---|---|---|
| System Processors, System-on-Chip (SoC), System-in-Package (SiP) | Maximum Logical Cores | CORE | Maximum number of logical cores [a] and feature set from available CPUs. | Install, Boot |
| CPU Frequency Control | Maximum number of logical cores [d] and feature set from available CPUs. | |||
| HW_PROFILER or SW_PROFILER | Maximum number of logical cores [e] and feature set from available CPUs. | |||
| Realtime System | REALTIME | REALTIME [f] | Maximum number of logical cores and feature set from available CPUs with the realtime kernel. [g] | |
| System Virtualization | SUPPORTABLE and CORE and MEMORY on the guest | SUPPORTABLE and CORE and MEMORY on the guest FV_CORE and FV_MEMORY | Run on a fully virtualized guest environment. Run on the host machine. | |
| Advanced System Virtualization [h] | CPU Pinning, | FV_CPU_PINNING, | Run on a fully virtualized guest environment. | |
| Pass-Through Storage, PCIE Pass-Through Storage, USB Pass-Through Network, PCIE Pass-Through Network, Virtual Machine Live Migration | FV_USB_STORAGE_PASSTHROUGH, FV_PCIE_STORAGE_PASSTHROUGH, FV_USB_NETWORK_PASSTHROUGH, FV_PCIE_NETWORK_PASSTHROUGH, and fv_live_migration [i] | Run on the host machine that has IOMMU enabled. | ||
[a]
The Core clock speed, FSB speed, cache size, cache depth and manufacturing size are not considered for feature set review.
[b]
Available in RHEL versions 8.3 and later
[c]
The Core clock speed, FSB speed, cache size, cache depth and manufacturing size are not considered for feature set review.
[d]
The Core clock speed, FSB speed, cache size, cache depth and manufacturing size are not considered for feature set review.
[e]
The Core clock speed, FSB speed, cache size, cache depth and manufacturing size are not considered for feature set review.
[f]
These tests are used to certify the Red Hat (Red Hat Enterprise Linux for Real-Time and Red Hat OpenStack Platform for Real-Time Applications) products.
[g]
The memory per CPU core check has been added as per the RHEL minimum requirement memory standards, as a planning condition for the hardware certification tests namely memory, core, realtime, and all the full-virtualization tests, for RHEL7 as well as RHEL8. If the memory per CPU core check does not pass, the above tests will not be added to the test plans automatically. However, they can be planned manually via CLI.
[h]
These features appear only on Red Hat Virtualization certifications.
[i]
Starting with RHEL 9.4, all fv_tests, except fv_live_migration, are supported to run on ARM systems.
| ||||
- Leverage Notes: Equal or lesser feature set within a model. Processor/core count downward on scaling designs. Feature set and core count upgrades to existing certifications. Processor upgrades are defined as field installable physical packages and may require field installable BIOS/firmware upgrades Section 3.5.3, “Settings”.
Table 4.2. System Memory
| Hardware Class | Catalog Features | Required Tests | Required Hardware | Install, Boot, kdump |
|---|---|---|---|---|
| System Memory | Maximum supported System memory | memory, memory_HBM_only, memory_HBM_cache, memory_HBM_flat | Minimum of 1GB per logical core using the maximum number of logical cores.[a][b] Maximum HBM memory size using the corresponding number of logical Cores [c] Maximum supported HBM memory size for HBM_only, HBM_cache and HBM_flat | Install, Boot |
| NVDIMM - Memory Mode | NVDIMM - Memory Mode[d] | Memory[e] | Any size NVDIMM | Install, Boot |
| NVDIMM - App Direct | NVDIMM - AppDirect Mode[f] | NVDIMM[g] | Any size NVDIMM | Install, Boot, Kdump |
[a]
Systems must be in configurations within the memory requirements listed in the RHEL limits article
[b]
Additional testing is required when the maximum system memory available is greater than the maximum memory listed in the Red Hat Enterprise Linux Technology Capabilities and Limits article.
[c]
Depending on the available system configurations, the required HBM memory testing may need to be conducted separately from regular system memory.
[d]
Available in RHEL versions 7.6 and later
[e]
Additional EET testing is also required for NVDIMM - Memory Mode
[f]
Available in RHEL versions 7.3 and later
[g]
The NVDIMM test utilizes sector
| ||||
- Leverage Notes: Equal or lesser quantities where RAM type and memory controller match.
- Leverage Notes for NVDIMM Hardware Class: The storage mode is only for identical implementations with smaller or greater capacity within the OS limits.
Table 4.3. System Elements
| Hardware Class | Catalog Features | Required Tests | Required Hardware | Install, Boot, Kdump |
|---|---|---|---|---|
| Mainboard, Chassis, I/O Chassis, Docking Stations, Port Expanders | Applicable class for the integrated and optional hardware. | Applicable class tests for the integrated and optional hardware. hardware. | Applicable test for each function as required by the device class(es) | Install, Boot |
| Multi-Function/Multi-Port Adapters | Applicable class for each function/port | Applicable test for each function as required by the device class(es) | Install, Boot | |
[a]
Unusable ports need to be tested
[b]
To create multiple ports on a removable card, identical chips are replicated. Leverage may enclose multi-port.
| ||||
Table 4.4. Sound
| Hardware Class | Catalog Features | Required Tests | Required Hardware |
|---|---|---|---|
| Sound Cards | Stereo Audio Playback, and Stereo Audio Record | Audio | Stereo record and playback as applicable |
| HDMI Audio | HDMI Audio Playback | Audio | HDMI Port |
- Leverage Notes: Identical integrated chipsets+codec and removable adapters.
Table 4.5. Thunderbolt Ports
| Hardware Class | Catalog Features | Required Tests | Required Hardware |
|---|---|---|---|
| Thunderbolt 3, Thunderbolt 4 | Thunderbolt 3, Thunderbolt 4 | Thunderbolt 3, Thunderbolt 4 | Each port with a device with the equivalent capability hotplug |
Table 4.6. USB Ports
| Hardware Class | Catalog Features | Required Tests | Required Hardware |
|---|---|---|---|
| USB 2, USB 3 (5 Gigabit), USB C (5 Gigabit), USB 3 (10 Gigabit), USB C (10 Gigabit), USB 3 (20 Gigabit), USB C (20 Gigabit), USB 4 (20 Gigabit), USB 4 (40 Gigabit) | USB 2 Ports, USB 3 (5 Gigabit) Ports, USB C (5 Gigabit) Ports, USB 3 (10 Gigabit) Ports, USB C (10 Gigabit) Ports, USB 3 (20 Gigabit) Ports, USB C (20 Gigabit) Ports, USB 4 (20 Gigabit) Ports, USB 4 (40 Gigabit) Ports | USB2, USB3, USB3_5Gbps, USB3_10Gbps, USB3_20Gbps, USB4, USB4_20Gbps, or USB4_40Gbps | Each port with a device with the equivalent capability hotplug. [a][b][c][d] |
[a]
In all RHEL 7.x certifications, USB 3.1 gen2 ports require testing with RHEL 7.3 or higher.
[b]
USB 3.1 gen2 ports that are tested only with the gen1 devices can be certified.
[c]
USB 3.1 Gen2 at 10Gbps is supported in later versions of RHEL 7.
[d]
USB 3.1 Gen2 ports are supported/tested at 5Gbps only, prior to RHEL 7.5 or later and RHEL 7.4 (EUS).
| |||
4.8.2. Management
The hardware features that are included in Management are:
Table 4.7. Console
| Hardware Class | Catalog Features | Required Tests | Required Hardware | Install, Boot, kdump |
|---|---|---|---|---|
| Display Adapters, and Virtual Consoles | Graphic Console | VIDEO | The lower of VRAM/VBIOS limits, panel capabilities, or 1024x768 at 24 or 32 BPP | Install[a], Boot |
| Display Adapters | Basic GPU Graphics | VIDEO_DRM | DRM Kernel Module supported graphics controller | |
| Display Adapters | Accelerated GPU Graphics | VIDEO_DRM_3D | DRM Kernel Module supported graphics controller + Hardware Acceleration Supported graphics controller | |
| Laptop Panels | Graphic Console LCD | Video [LID][b] | Native resolution[c][d] at adaptive or native color depths with available display + graphics controller combinations[e][f] | Install |
| LCD backlight control | ||||
[a]
Native resolutions not required during install
[b]
The backlight must respond to lid switch if present.
[c]
Compensation/Stretching does not qualify as native resolution for testing.
[d]
A horizontal resolution of 1360 may be used on 1366 native panels.
[e]
Optional graphics controllers excluded by other policies are not required to be tested. At least one display + controller combination is required for each display.
[f]
Display and graphics controller combinations may be clarified in a Red Hat Knowledge Base Article entry to avoid confusion.
[g]
Backlight test does not support external displays.
[h]
Available, but not required, in RHEL versions 8.0 and later certifications.
| ||||
- Leverage Notes: Identical removable cards or integrated chips without shared memory,processor-integrated. Decreases in video memory.
Table 4.8. Power Control
| Hardware Class | Catalog Features | Required Tests | Required Hardware |
|---|---|---|---|
| Power Management, Battery | Suspend to Disk, Suspend to Memory, Battery Monitoring | Battery, Lid and Suspend | Required for all models capable of running from battery power. |
Table 4.9. Identity Management
| Hardware Class | Catalog Features | Required Tests | Required Hardware |
|---|---|---|---|
| fingerprintreader | Fingerprint Reader | fingerprintreader | Built-in or External fingerprint reader |
4.8.3. Network
The hardware features that are included in Network are:
Table 4.10. Ethernet
| Hardware Class | Catalog Features | Required Tests | Required Hardware | Install, Boot, kdump |
|---|---|---|---|---|
| Ethernet | 1 Gigabit Ethernet, 2.5 Gigabit Ethernet, 5 Gigabit Ethernet, 10 Gigabit Ethernet, 20 Gigabit Ethernet, 25 Gigabit Ethernet, 40 Gigabit Ethernet, 50 Gigabit Ethernet, 100 Gigabit Ethernet, 200 Gigabit Ethernet | 1GigEthernet, 2.5GigEthernet, 5GigEthernet, 10GigEthernet, 20GigEthernet, 25GigEthernet, 40GigEthernet, 50GigEthernet, 100GigEthernet, 200GigEthernet | Each interface at maximum connection speed.[a] | Install, Boot, kdump |
[a]
Devices that support network partitioning are required to demonstrate both the complete bandwidth and a single partition in one or more test runs.
| ||||
- Leverage Notes: Identical integrated chipsets and removable adapters.
Table 4.11. Fibre Channel
| Hardware Class | Catalog Features | Required Tests | Required Hardware | Install, Boot, kdump |
|---|---|---|---|---|
| Fibre Channel | 16 Gigabit Fibre Channel, 32 Gigabit Fibre Channel, 64 Gigabit Fibre Channel, 128 Gigabit Fibre Channel | Network or Storage[a] | Each interface at maximum connection speed | Install, Boot, kdump |
[a]
Nominal connection speed is considered a feature. Remote attached storage devices may require additional testing.
| ||||
- Leverage Notes: Identical integrated chipsets, removable adapters, drivers, and arrays.
Table 4.12. Fibre Channel over Ethernet (FCoE)
- Leverage Notes: Identical integrated chipsets, removable adapters, drivers, and arrays.
Table 4.13. iSCSI
| Hardware Class | Catalog Features | Required Tests | Required Hardware | Install, Boot, kdump |
|---|---|---|---|---|
| iSCSI Adapters | iSCSI | Network and Storage[a] | Each interface at maximum connection speed | Install, Boot, kdump |
[a]
Nominal connection speed is considered a feature. Remote attached storage devices may require additional testing.
| ||||
- Leverage Notes: Identical integrated chipsets, removable adapters, drivers, and arrays.
Table 4.14. Infiniband
| Hardware Class | Catalog Features | Required Tests | Required Hardware | Install, Boot, kdump |
|---|---|---|---|---|
| Infiniband[a] | QDR Infiniband, FDR Infiniband, EDR Infiniband, HDR Infiniband, Socket Direct | Infiniband_QDR, Infiniband_FDR Infiniband_EDR, Infiniband_HDR, Infiniband_Socket_Direct | Install, Boot, kdump | |
[a]
Multiple hosts to be connected into a single adapter by separating the PCIe interface into multiple and independent interfaces.
[b]
Implements a connection in hardware for efficient data delivery with minimal latency.
[c]
Devices that support network partitioning are required to demonstrate both the complete bandwidth and a single partition in one or more test runs.
| ||||
- Leverage Notes: Identical integrated chipsets, removable adapters, drivers, and arrays.
Table 4.15. iWarp
| Hardware Class | Catalog Features | Required Tests | Required Hardware |
|---|---|---|---|
| iWarp | 10 Gigabit iWarp, 20 Gigabit iWarp, 25 Gigabit iWarp, 40 Gigabit iWarp, 50 Gigabit iWarp, 100 Gigabit iWarp, 200 Gigabit iWarp | 10GigiWarp, 20GigiWarp, 25GigiWarp, 40GigiWarp, 50GigiWarp, 100GigiWarp, 200GigiWarp | Each interface with the corresponding test for the maximum claimed connection speed.footnote:[a] |
[a]
Devices that support network partitioning are required to demonstrate both the complete bandwidth and a single partition in one or more test runs.
| |||
- Leverage Notes: Identical integrated chipsets and removable adapters.
Table 4.16. Omnipath
| Hardware Class | Catalog Features | Required Tests | Required Hardware |
|---|---|---|---|
| OmniPath | OmniPath | OmniPath | Each interface with the corresponding test for the maximum claimed connection speed. |
- Leverage Notes: Identical integrated chipsets, processors, and removable adapters.
Table 4.17. RDMA over Converged Ethernet (RoCE)
| Hardware Class | Catalog Features | Required Tests | Required Hardware |
|---|---|---|---|
| RoCE | 2.5 Gigabit RoCE, 5 Gigabit RoCE, 10 Gigabit RoCE, 20 Gigabit RoCE, 25 Gigabit RoCE, 40 Gigabit RoCE, 50 Gigabit RoCE, 100 Gigabit RoCE, 200 Gigabit RoCE | 2.5 GigRoCE, 5 GigRoCE, 10GigRoCE, 20GigRoCE, 25GigRoCE, 40GigRoCE, 50GigRoCE, 100GigRoCE, 200GigRoCE | Each interface with the corresponding test for the maximum claimed connection speed.[a] |
[a]
Devices that support network partitioning are required to demonstrate both the complete bandwidth and a single partition in one or more test runs.
| |||
- Leverage Notes: Identical integrated chipsets, processors, and removable adapters.
Table 4.18. WiFi
| Hardware Class | Catalog Features | Required Tests | Required Hardware | Install,Boot, kdump |
|---|---|---|---|---|
| Wireless Network, Interface Adapters | Wireless N, Wireless AC, USB Wireless N, USB Wireless AC, Wireless G, and USB Wireless G | Wireless G, Wireless N, Wireless AC[a], WiFi6 (Previously WirelessAX) | Each interface at maximum connection in N(highest), G, B, A(lowest) order. | Install,Boot |
[a]
Red Hat Enterprise Linux 7.0 only supports 802.11ac devices at 802.11n speeds. Results will be accepted from the WirelessN test on 802.11ac devices until an erratum that provides full 802.11ac connection speeds to Red Hat Enterprise Linux 7.0 is available.
| ||||
- Leverage Notes: Identical integrated chipsets, processors, and removable adapters.
Table 4.19. Bluetooth
| Hardware Class | Catalog Features | Required Tests | Required Hardware |
|---|---|---|---|
| Bluetooth | Bluetooth 3.x, Bluetooth 4.x, Bluetooth 5.x | BLUETOOTH3, BLUETOOTH4, BLUETOOTH5 | Each interface at maximum bluetooth version |
- Leverage Notes: Identical integrated chipsets and removable adapters.
4.8.4. Storage
The hardware features that are included in Storage are:
Table 4.20. HBA, HDD, and SDD
| Hardware Class | Catalog Features | Required Tests | Required Hardware | Install, Boot, kdump |
|---|---|---|---|---|
| M.2 NVMe, M.2 SATA, PCIe NVMe, SATA HDD, SATA SSD, SAS[a], SAS SSD, U.2 NVMe, U.2 SATA | M.2 NVMe, M.2 SATA, NVMe, SATA, SATA SSD, SAS, SAS SSD, U.2 NVMe, U.2 SATA | M2_NVMe, M2_SATA, NVMe, SATA, SATA_SSD, SAS, SAS SSD, U2_NVMe (PCI Express), U2_SATA | Any capacity[b] drive[c] attached to the controller or the maximum storage capacity of local attach arrays if greater than OS limit | Install, Boot, kdump |
| RAID Controllers | Storage | Storage | Each OS code path (e.g. where multiple drivers are used) for each interface. Maximum storage capacity of arrays if greater than OS limit. | Install, Boot, kdump |
| NVMe over Fabric | NVMe over Infiniband, NVMe over iWarp, NVMe over Omnipath, NVMe over RoCE, NVMe over TCP | nvme_infiniband, nvme_iwarp, nvme_omnipath, nvme_roce, nvme_tcp | An NVMe SSD drive shared from the test server to HUT ethernet controller sized under the maximum storage capacity of the OS limit. | |
[a]
SAS Controllers require testing with SAS drives.
[b]
Drive capacity is not tracked in the context of a system.
[c]
SSD features require SSD drives to be tested.
| ||||
- Leverage Notes: Identical integrated chipsets, removable adapters, drives, and arrays.
- Leverage Notes for RAID Controllers: Identical integrated chipsets, removable adapters, drives and arrays following type criteria. Reduced RAID levels, changes in memory amounts or battery presence.
Table 4.21. Tape
- Leverage Notes: Identical drives and changers. Internal and external versions of the same drives. Models with the same host interface, hardware and firmware designs including reduced features, capacity, media size and/or total slots and drive count in changers/libraries.
Table 4.22. Memory Cards or Readers
| Hardware Class | Catalog Features | Required Tests | Required Hardware | Install, Boot, kdump |
|---|---|---|---|---|
| eMMC, PCIE SD Card Reader, SD Card, USB Flash Key, USB SD Card Reader[a] | eMMC, PCIE SD Card Reader, SD Card, USB Flash Key, USB SD Card Reader | Storage | The maximum storage capacity and format feature set | Install,Boot |
[a]
Including variants for each (eg. mini, micro, etc.).
| ||||
- Leverage Notes: Identical integrated chipsets, removable adapters. Identical, smaller capacity or feature cards and sticks.
Multi-Readers follow the Multi-Port Adapter criteria.
Table 4.23. Optical
| Hardware Class | Catalog Features | Required Tests | Required Hardware | Install, Boot, kdump |
|---|---|---|---|---|
| CD-ROM drive, DVD drive, or Blu-ray | BD-RE, BD-R, Blu-ray, DVD-RW, DVD-R, DVD, CD-RW, CD-R, CD | CDROM drive, DVD drive, or BLURAY | The highest media type in order of BD-RW (highest), BD-R, DVD-RW[a], DVD-R, CD-RW, CD-R, BD, DVD, CD (lowest) on each storage controller, based on the collective media support of all drives[b] available on that storage controller | Install, Boot |
[a]
"+" and "-" are considered equal for feature review.
[b]
The hardware partner is required to support all drives that are part of the model regardless of the specific drive or number of drives used during testing. Equivalent production cycle drive changes are required to be tested internally by the hardware partner. The production cycle drive change test results are not required to be submitted to Red Hat
| ||||
- Leverage Notes: Drives with identical or lesser media support on the storage controller following the storage controller leveraging policies.
4.9. Additional manual testing
The additional manual testing consists of the external storage and multipath HBAs.
4.9.1. External storage and multipath HBAs
In addition to the base requirements for storage controllers/devices; vendors must verify that their internal quality assurance processes have tested full functionality with Red Hat Enterprise Linux under the following scenarios as appropriate:
- multi-controllers/single host
- multi-host/single controller
- multi-controller/multi-host
- with/without multi-path
- with/without LUN masking (i.e., dedicating LUNs to specific hosts)
- a short cable pull (remove cable and restore prior to failure detection)
- any special features listed as supported on Red Hat Enterprise Linux
Testing result packages are not required to be submitted to Red Hat for the above testing.
