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 versions. Note 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 RHEL versions and architectures Policies for layered product certifications 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. Note 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. Important Requests to keep a certification unpublished should be made in the comment dialog of the certification request when the certification is initially opened. Note 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 section 2.1 of the Hardware Certification Program Appendix , which is part of the Red Hat Partner Agreements , for further details). 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 section 2.1 of the Hardware Certification Program Appendix , which is part of the Red Hat Partner Agreements , for further details). 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 major version. It does not carry over to the or major versions or other architectures. The following table shows the RHEL versions and architectures that can be combined in a certification: RHEL version Architecture RHEL 9 AMD and Intel 64-bit 64-bit IBM Z ARM 64-bit Little endian IBM Power systems RHEL 8 AMD and Intel 64-bit IBM Z 64-bit ARM 64-bit Little endian IBM Power systems Important 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. 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 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 Red Hat Enterprise Linux for Real Time Life Cycle 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 Red Hat Virtualization Red Hat Virtualization Life Cycle Certifying Red Hat Enterprise Linux as a KVM host 3.3.3. Red Hat Enterprise Linux OpenStack Platform Compute Supported RHEL versions Supported RHEL for Real Time versions Prerequisite certifications 8 and 9 Consult the supportability matrix 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 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. Additional resources Red Hat OpenStack Platform Red Hat OpenStack Platform Life Cycle Red Hat OpenStack Platform Hardware Bare Metal Certification Policy Guide Red Hat Bare Metal Hardware Certification Workflow Guide . 3.3.4. Red Hat OpenStack Platform for Real-Time Applications Supported RHEL versions Supported RHEL for Real Time versions Prerequisite certifications 8 Consult the supportability matrix RHEL (basic virtualization tests must have passed) Red Hat Enterprise Linux for Real Time Red Hat OpenStack Platform Compute Apply for the Red Hat OpenStack Platform for Real-Time Applications certification after has been awarded the prerequisite certifications detailed in the 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) Consult the supportability matrix RHEL (basic virtualization tests must have passed) 8 (RHOCP 4.12) Consult the supportability matrix 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 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. Additional resources Red Hat OpenShift Container Platform Red Hat OpenShift Life Cycle Red Hat OpenStack Platform Hardware Bare Metal Certification Policy Guide Red Hat Bare Metal Hardware Certification Workflow Guide . 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 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. Important 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. Note The test suite is only tested against 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 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 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. Note 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. Important Technology preview drivers are not supported by Red Hat and may be not be used during certification. Important 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. Warning 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. Note 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. Note KVM virtualization tests are planned for: ARM, beginning with RHEL 9.4. 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 system under test (SUT) meets the minimum hardware requirements. RHEL 8 and 9 : Minimum system RAM should be 1.5GB, 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. Additional resources Minimum required memory Hardware support available in RHEL 8 but removed from RHEL 9 . 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. Note 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.

Commands: