Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

Program Policy Guide

Red Hat Enterprise Linux Hardware Certification 1.0

For Use with Red Hat Enterprise Linux Hardware Certification

Red Hat Hardware Certification Team

Abstract

The Red Hat Hardware Certification Program Policy Guide covers the procedural, technical and policy requirements for achieving a Red Hat Hardware Certification.

Chapter 1. Introduction

1.1. Introduction

This guide explains 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.2. 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.3. Program Overview

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 Section 4.1, “Test Plan Overview” to create a test plan suitable for your hardware specifications.

A description of the hardware certification process can be found in the Section 2.1, “Certification Process Overview”

1.4. 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. It is expected to test all optional hardware configurations that are designated as part of the same model.
  • Testing must be performed with a standard installation of Red Hat Enterprise Linux without special configuration or additional software, including drivers that are not provided by Red Hat.
  • Certifications are currently available for:

    • Red Hat Enterprise Linux  6.x, 7.x, and upcoming versions of 8.x for 32/64-bit x86, IBM Power Big/Little-Endian, Power9 (LE), IBM System z, and ARM.

      Also, optionally for:

    • Red Hat Enterprise Linux OpenStack Platform Compute 13 and 14.
    • Red Hat Gluster Storage 3.
    • Red Hat Hyperconverged Infrastructure 1.
    • Red Hat Enterprise Linux for Real Time 7.
Important

The IBM Power9 (LE) and ARM architectures require an approved collaborative partnership to have been established to be eligible for certification. Your Engineering Partner Manager (EPM) should be consulted for further details, and discussion.

Chapter 3, Hardware Certification Policies describes each of the hardware certification policies in detail.

1.5. Giving Feedback and Getting Help

We Need Feedback!

If you find a typographical error in this guide, or if you think of a way to improve the certification program or documentation, we would appreciate hearing from you!

Submit a report in the Red Hat Bugzilla system against the product Red Hat Hardware Certification Program. If you have a suggestion for improvement, try to be as specific as possible when describing it. If you have found an error in the documentation, please include the section number and some of the surrounding text so we can find it easily.

Do You Need Help?

If you experience difficulty with a procedure described in this documentation, visit the Red Hat Customer Portal. Through the customer portal, you can:

  • search or browse through technical support articles and solutions about Red Hat products.
  • submit a support case to Red Hat Global Support Services (GSS).
  • access product documentation.

Questions During Certification

During the certification process, you may need to ask or reply to a question about topics which affect a specific certification. These questions and responses are recorded in the Additional Comments section of the Dialog tab of the certification entry.

Note

Personal emails are not a tracked support mechanism and do not include a Service Level Agreement. Please use the correct support procedure when asking questions.

Important

The Red Hat Hardware Certification Program presumes an advanced level of hardware and Red Hat product knowledge and skills. Red Hat product support is neither offered nor covered in the Red Hat Hardware Certification Program, but is available for purchase separately.

Warning

The Red Hat Hardware Certification Program does not resolve compatibility or product defect issues that may be encountered during the certification process. These issues may block a certification and may require resolution including hardware and/or Red Hat Product update(s) before the certification can proceed.

Chapter 2. Certification Process Overview

2.1. Certification Process Overview

Partners are required to follow the following preliminary steps:

  1. Establish a certification relationship with Red Hat.
  2. Establish a test environment consisting of your product and the Red Hat product combination to be certified.
  3. Perform preliminary testing to ensure this combination works well.
  4. Install the redhat-certification tool.

Certification Steps:

  1. Create a certification request for a specific system or hardware component using redhat-certification.
  2. Red Hat’s certification team applies the certification policies to the hardware specifications to create the official test plan.
  3. Run the tests specified in the official test plan and submit results using redhat-certification to Red Hat for analysis.
  4. The certification team analyzes the test results and marking credit as appropriate and communicating any required retesting.
  5. 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 https://access.redhat.com/certifications.

A full description of the hardware certification process can be found in the , Hardware Certification Process Summary 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.

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

Hardware certification entries for all products will not be posted publicly until the General Availability (GA) release of that product.

A Red Hat Hardware Certification is valid for the posted release and any subsequent minor updates. For example, a 32-bit certification granted on Red Hat Enterprise Linux 6.3 is also valid for 6.4, 6.5 and so on.

Certifications do not apply to past or future major Red Hat Enterprise Linux versions nor additional or alternate architectures of Red Hat Enterprise Linux, such as Red Hat Enterprise Linux 8 or Red Hat Enterprise Linux 7 or Red Hat Enterprise Linux 6 for Intel 64 and AMD64 in relation to the previous example. These certifications must be obtained separately.

Once a hardware model has been certified, the hardware will retain its certification until

  1. re-certification is required,
  2. Red Hat no longer supports that version of Red Hat Enterprise Linux, OR
  3. the vendor ceases participation in the Hardware Program.

This life cycle policy also applies to Red Hat Enterprise for Real Time, Red Hat Gluster Storage, Red Hat Hyperconverged Infrastructure, and Red Hat OpenStack optional 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. This option is only available for major versions (5.0,6.0 etc.) and is not available for update releases (6.6, 7.1, etc.).

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.

The partner is 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 Section 3.1.9, “Component Pass-Through Certifications”. Additional requirements for leveraging are provided in Section 4.7, “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

  1. has permission from the third party,
  2. 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
  3. 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, and

(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 Section 3.1.7, “Component Leverage Pools”).

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. For example, an increase to the number of CPUs supported or the addition of new components such as network or storage controllers requires re-certification. Refer to Section 4.1, “Test Plan Overview” for further information on test plan criteria.

A new supplemental certification should be opened to process the hardware changes.

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 Section 4.1, “Test Plan Overview”) 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. Hardware Policy for RHEL 8

Starting with RHEL 8, hardware certifications will implement a more granular display of certifications published on the Red Hat Certification Catalog. However, all the established procedures and policies that were applied for previous versions of RHEL will be implied to RHEL 8 as well. Implementing granular publishing of certifications will reduce the customer effort required to find and use certified solutions that meet their needs. This additional level of detail includes the certified capabilities (features) of your hardware.

3.2.1. Component Certification

Red Hat will continue to certify models of system components with RHEL 8. A component is hardware that implements a fixed subset of one or more system features as defined by a specification provided by a partner. Red Hat will also continue to support pass-through, pass-through for leverage, and component leverage pools when certifying component hardware for RHEL 8. The superset of features from the specification will be considered as part of the model definition unless excluded by unique component model names for different feature sets.

Red Hat will create a test plan for the component certification, based on the identified and enabled RHEL 8 hardware features as defined and designated by Red Hat. The test plan for RHEL 8 hardware certification will continue to build and function using the process and criteria of the previous RHEL releases.

Success Criteria

  • A component can be certified with RHEL 8 when all enabled features are tested and passed in accordance to the Red Hat provided certification test plan.
  • A component can also be certified in RHEL 8 when one or more enabled features are tested and passed in accordance to the test plan.

3.2.2. System Certification

Red Hat will continue to certify system models with RHEL 8. A system is a RHEL 8 bootable, installable, and operableable collection of component hardware as defined by a specification provided by a partner. Red Hat will also continue to support pass-through, leverage, supplemental, and pass-through with supplemental in hardware certification for RHEL 8.

The specification may define components as standard, or optional. The system model is considered to provide all of the features from the complete collection of standard and optional components unless explicitly excluded by or from the specification.

Red Hat will create a test plan for the system certification, based on the identified and enabled RHEL 8 hardware features as defined and designated by Red Hat. The test plan for RHEL 8 hardware certification will continue to build and function using the process and criteria of the previous RHEL releases.

Success Criteria

  • A system can be certified with RHEL 8 when all enabled features are tested and passed according to the Red Hat provided certification test plan.
  • A system can also be certified with RHEL 8 when at least one available and installable combination of components that are tested and passed provide a minimum set of one compute, management, network, and storage features.
Note

To provide clarity to customers a knowledge base entry may be added if the minimum feature set is not provided as standard within the model.

3.2.3. Certification and Feature Publication

A certification that meets the success criteria can be published. All of the features within the test plan will be listed in the certification catalog when the certification is published. The features will appear with one of the following statuses:

  • Supported: tested and pass, or tested and pass with condition.
  • Not Supported: tested and failed, or not tested.

3.2.4. Catalog Search Results

Certified hardware will appear in the Red Hat certification catalog with a detailed list that includes all of the identified features in the test plan. A customer can search the catalog by the name of your product or by the certified features available to them.

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 which is certified for their required features. With the modified catalog search experience, kbases applied to the certification can be filtered.

Important

Features not tested or that did not pass when the system was first certified can be updated using a supplemental certification for the system. The additional features, if certified, will then be added to the certification catalog.

3.3. Hardware Policy for RHEL 6, 7, and Layered Products

Following policies are part of RHEL 6, 7, and layered products:

3.3.1. Red Hat Enterprise Linux

Red Hat Hardware Certification is available for the Red Hat Enterprise Linux family of products. Certifications are awarded per version and architecture pair (Red Hat Enterprise Linux 6 for x86_64, for example) and not by variant (Red Hat Enterprise Linux for Desktops).

A critical feature of the Red Hat Enterprise Linux product family is that all family members share a common core (e.g. the kernel, development tool chain, libraries, etc.); therefore, certifications apply to all variants of the same version and architecture.

At this time, Red Hat only accepts hardware test results that have been conducted on Red Hat Enterprise Linux 6.x or 7.x or 8.x releases.

3.3.2. Red Hat Enterprise Linux OpenStack Platform Compute (Optional)

Red Hat Enterprise Linux OpenStack Platform Compute delivers the Red Hat OpenStack technology optimized for, and integrated with, Red Hat Enterprise Linux.

Red Hat Enterprise Linux OpenStack Platform Compute consists of additional packages that expand the capabilities of Red Hat Enterprise Linux to quickly scale up to tens of thousands of virtual machines without requiring a unique kernel or specialized hardware support. Because of this common base, additional testing beyond the Red Hat Enterprise Linux certification with Virtualization is not required for servers to receive Red Hat Enterprise Linux OpenStack Platform Compute certification.

This certification is automatically included for all new Intel64 and AMD64 server certifications submitted for Red Hat Enterprise Linux 7.

The base Red Hat Enterprise Linux certification is required to be successfully completed, including virtualization testing, and the base certification must be posted before Red Hat Enterprise Linux OpenStack Platform Compute certification is processed.

3.3.3. Red Hat Enterprise Linux for Real-Time (RHEL7 and RHEL8)

Red Hat Enterprise Linux for Real-Time offer predictability, for consistent low-latency system response times. These Real-Time products consist of additional packages that expand Red Hat Enterprise Linux, including a uniquely tuned replacement kernel. These packages add to, but do not modify, the user-space portion of Red Hat Enterprise Linux.

The Hardware Certification Test Suite contains an additional Real-Time test that can be performed to achieve Real-Time certification after completing the base, Red Hat Enterprise Linux certification (see Section 4.7, “Hardware Class Requirements”). The additional Real-Time packages must be installed and running to perform these tests.

Hardware Certification Partners can create new Real-Time certifications requests in the certification workflow by selecting an existing Red Hat Enterprise Linux 7 or Red Hat Enterprise Linux 8 certification entry, going to the Advanced section, and then filling out the fields under the Create New Layered Product Certification - RHEL Real-Time heading.

The base Red Hat Enterprise Linux certification is required to have been completed and posted before the Real-Time results will be reviewed.

3.3.4. Red Hat OpenStack Platform for Real-Time Applications

Red Hat Openstack Platform for Real-Time Applications is designed to deliver ultra-low latency for performance-sensitive virtual environments. The Red Hat OpenStack Platform for Real-Time Applications products consist of additional packages that expand Red Hat OpenStack Platform, including a uniquely tuned replacement kernel, KVM, and additional tuned profiles. These packages enable Real-Time applications to run in guests virtual machine using RHOSP.

The Red Hat Hardware Certification Test Suite contains an additional fv_real-time test that is to be performed to achieve Red Hat OpenStack Platform for Real-Time Applications certification. This test will be the default test plan for any Red Hat OpenStack Platform for Real-Time Applications certification. Red Hat OpenStack Platform for Real-Time Applications certifications should be opened after completing the Red Hat Enterprise Linux for Real-Time and Red Hat Enterprise Linux certification

Hardware Certification Partners can create new Red Hat OpenStack Platform for Real-Time Applications certifications requests in the certification workflow by selecting an existing Red Hat Enterprise Linux 7 certification entry, going to the Advanced section, and then filling out the fields under the Create New Layered Product Certification - RHEL Real-Time heading.

Partners are expected to perform the fv_real-time test from the host RHEL OS with the Real-Time kernel (kernel-rt) running, and the supported full virtualization enabled on the system.

Important

The Red Hat Enterprise Linux for Real Time certification is required to have been completed and posted before the Red Hat OpenStack Platform for Real-Time Application results will be reviewed.

3.3.5. Red Hat Gluster Storage for On-Premise

Red Hat Gluster Storage for On-Premise combines reliable Red Hat software with Intel 64 and AMD 64 commodity hardware, eliminating the need for high-cost, proprietary storage systems.

Red Hat Gluster Storage combines additional packages with a Red Hat Enterprise Linux ISO for easy deployment. Because it is based on Red Hat Enterprise Linux, only an additional hardware specification review is required for Red Hat Gluster Storage certification. Additional testing beyond the Red Hat Enterprise Linux 6 and Red Hat Enterprise Linux 7 certification testing is not required. The review will confirm that the server’s specifications conform to the supported hardware configurations of the Red Hat Gluster Storage image as outlined in the Minimum Hardware Requirements section of the Red Hat Gluster Storage 3.0 Compatible Physical, Virtual Server and Client OS Platforms Knowledge Base article.

Partners have the option to create a corresponding Red Hat Gluster Storage certification when creating a new Red Hat Enterprise Linux 6, 6.10 server certification request. Partners who want to create a Red Hat Gluster Storage certification entry for an existing Red Hat Enterprise Linux 6, 6.10 certified server may do so in the Hardware Catalog by going to the Advanced section of the desired Red Hat Enterprise Linux 6, 6.10 certification and then filling out the fields under the Create New Layered Product Certification - Red Hat Gluster Storage heading. Partners who are not currently able to create Red Hat Gluster Storage certifications but would like to certify Red Hat Gluster storage should review the Red Hat Storage Architectural Review Process for more information.

A successfully completed and posted base Red Hat Enterprise Linux certification is required before the Red Hat Gluster Storage certification is processed.

During the Red Hat Gluster Storage certification process, the system’s specifications are compared to the minimum Red Hat Gluster Storage hardware requirements (see Red Hat Storage Architectural Review Process for specifics).

Systems that fail to meet the requirements are rejected.

If a system meets the necessary requirements, its Red Hat Enterprise Linux 6 certification entry is checked for associated Red Hat Knowledge Base articles. Any applicable Red Hat Knowledge Base entries from the Red Hat Enterprise Linux certification are reviewed to ensure that they provide appropriate and sufficient information for end users. When any necessary Knowledge Base review and updates are completed, the Red Hat Gluster Storage certification can be published.

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.

Important

The test suite should not be modified for certification test runs. The test suite will perform a self check and will fail the info 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 Section 3.4.6, “Drivers” policies. Any testing performed with unnecessary errata installed may require retesting.

Note

The test suite is only tested against Red Hat Enterprise Linux 6 Server, Red Hat Enterprise Linux 7 Server, and and Red Hat Enterprise Linux 8 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

Additional kernel parameters may be utilized if they (a) are used to correct hardware configuration, (b) do not disable functionality, and (c) do not expose a potential for data loss when not in use. For example, if the kernel parameter noacpi is required to boot a system which does not install without that parameter, this would likely be acceptable. If, however, 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 certification are documented in Red Hat Knowledge Base Solution associated with the certification listing.

3.4.6. 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 (link). Starting with Red Hat Enterprise Linux 6.1, the /sbin/lsmod command will also mark technology preview modules with the letter "T" similar to the "U" for unsigned modules.

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:

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 info 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.7. SELinux (Red Hat Enterprise Linux 6, 7, and 8)

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.8. Red Hat Enterprise Linux as a Host

Red Hat Enterprise Linux 6, 7, and 8 require testing of KVM Virtualization during certification on 32-bit (RHEL6 only) and 64-bit architectures. See Section 4.7, “Hardware Class Requirements” - System Virtualization for the specific list of required tests.

3.4.9. 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 (e.g. feature complete without major changes pending) during testing. BIOS/Firmware changes subsequent to testing are required to meet the Section 3.5.2, “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 package(s). 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.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.

Chapter 4. Creating the Test Plan

4.1. Test Plan Overview

This chapter describes the process followed by the Red Hat Hardware Certification team to create a test plan for a system or hardware component. Section Section 4.7, “Hardware Class Requirements” provides a useful reference that defines the testing required for each hardware class item.

A hardware certification engineer creates a test plan by following these steps:

  1. Define the model by its specification (Section 4.2, “Models”)
  2. Determine the options (Section 4.3, “Options”)
  3. Remove unsupported operating system features and unintentional hardware (Section 4.4, “Non-OS Features and Unintentional Features”)
  4. Apply the minimum test set criteria (Section 4.5, “Minimum Test Set”)
  5. Add the install, boot, and kdump requirements (Section 4.6, “Installation, Boot, and Kdump Requirements”)
  6. Add additional policy requirements (Chapter 3, Hardware Certification Policies)

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.

Figure 4.1. Test Plan Progress

hwp Test Plan
Note

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 models, not specific configurations of models. Red Hat defines a model as inclusive of all Integrated Hardware and all Optional Hardware described by the Hardware Partner on the hardware specification. Integrated Hardware is hardware required to be present in all configurations of a model. Optional Hardware is hardware which is present in some configurations of a model. Additional Hardware may also appear on the model specification. Additional Hardware is hardware that can be purchased in addition to but is not included as part of any configuration of the model. Additional Hardware is not required to be tested but must be clearly identifiable as Additional Hardware and not confused with Integrated Hardware or Optional Hardware. A Red Hat Knowledge Base Article may be associated with the certification listing for clarity of Additional Hardware.

Model names are required to be unique and have a particular hardware specification.

Tiered model naming schemes are allowed and supported by the Red Hat Hardware Certification program. A tiered naming scheme is any naming scheme which 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; three model names, 3000, 3000a, and 3000s. If 3000 reflects the collection which includes the 3000a and 3000s models and 3000 is submitted, the specification would include the content of the 3000a and 3000s models. If, however, 3000s was submitted the specification would be limited to only the hardware listed in the 3000s specification. If 3000 is instead a model separate from 3000a and 3000s this would not be a tiered scheme but similar model naming and only the hardware listed in the 3000 specification would be considered.

Red Hat may alter the listed model name for clarity; for example in NUMA and cluster situations when a quantity of systems/nodes alters the specification and a Red Hat Knowledge Base entry is not considered sufficient to avoid customer confusion; e.g. the addition of "(up to 2 nodes)" after a model name.

Important

For simplicity, a leverage pool certification model name may utilize the component vendor’s model information in the make and model fields. The model name must be unique within the system vendor’s pool and will remain unpublished.

4.3. Options

4.3.1. Integrated Hardware

All integrated hardware, CPU options, memory options, integrated graphic controllers, integrated displays, and other non field removable hardware of a model must be tested. This includes features integrated into System-on-Chip (SoC), System-in-Package (SiP), and other full or partial integrated systems solution designs.

Specific portions of integrated hardware may be excluded from the certification when they provide features which qualify for exclusion based on the policies outlined in Section 4.4, “Non-OS Features and Unintentional Features” or system processor leveraging.

4.3.2. Optional Hardware

All Optional Hardware must be tested except when the Optional Hardware is field removable, does not provide a unique function within the model [1] , and is clearly noted for use with another operating system [2] or marked to disclose any Service Level impacts as appropriate on at least one of the model specification or the model support URL and on all materials using the Red Hat Hardware Certification mark(s) in association with the model.

As an example, if a system is available with and without a SAS controller, and is also available with three functionally identical optional network cards, one of which is identified for use with Fedora only, the required testing would include the SAS controller and the two remaining optional network cards.

4.3.3. Special Cases

The Hardware Changes policy (see Section 3.6.4, “Changes”) may be utilized when Optional Hardware or a (series of) CPU(s) causes a higher than desired minor release to be required during an original certification. This may allow the model to be tested and posted with the desired release with an associated Red Hat Knowledge Base Article to reflect the higher release required by the Optional Hardware or CPU(s).



[1] Quantity of a function is not considered unique; for example, a dual and a quad Ethernet adapter with all other capabilities being the same are considered to provide the same function.
[2] Notes must be in the positive tone (e.g. "for use with…​") and not the negative (e.g. "not for use with…​").

4.4. 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. For example, IEEE 1394, a type of storage not currently supported in Red Hat Enterprise Linux 6, would not require testing in a Red Hat Enterprise Linux 6.x certification. If, however, the system only had IEEE 1394 storage, it would not qualify for a Red Hat Enterprise Linux 6 certification. 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. For 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.5. 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 Section 4.7, “Hardware Class Requirements”. This column in combination with Section 3.1.6, “Component Leveraging” and Section 3.1.9, “Component Pass-Through Certifications” are designed to ensure an appropriate and reasonable testing effort to achieve certification.

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.

Warning

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.6. 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 Section 4.7, “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, we recommend 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 a common feature of both Red Hat Enterprise Linux 6, 7, and 8. Kdump utilizes the Linux kernel kexec feature to boot a kernel without a hardware reset in the event of a crash and capture the state of the previous kernel. This feature is enabled by default and must be tested to ensure this critical debug information can be captured properly. The kdump test will automatically be planned when the kdump service is enabled.

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 Red Hat Enterprise Linux 6, 7, and 8 certifications on the 32-bit and 64-bit Intel and AMD systems , and 64-bit IBM PowerPC architectures. Additionally, Red Hat Enterprise Linux allows testing of Kdump on IBM System z architectures.

Note

Red Hat Enterprise Linux 6.0 and 6.1 certifications may optionally use Red Hat Enterprise Linux 6.2 kdump results to satisfy the kdump testing criteria as the kdump requirement policy was established subsequent to these releases. A Red Hat Knowledge Base Article will be added to these certs noting that the minimum version for kdump functionality is Red Hat Enterprise Linux 6.2.

4.7. Hardware Class Requirements

The Hardware Class Requirements are categorized in Compute, Management, Network, and Storage.

4.7.1. Compute

The hardware features that are included in Compute are:

Table 4.1. System Processors

Hardware ClassCatalog FeaturesRequired TestsRequired HardwareInstall, Boot, kdump

System Processors, System-on-Chip (SoC), System-in-Package (SiP)

System Processor (Maximum quantity of Cores)

cpu_scaling, CORE, FV_CORE, FV_MEMORY, HW_PROFILER or PROFILER[a]

Maximum number of logical cores[b]and feature set from available CPUs. [c]

Install, Boot

Realtime System

REALTIME

REALTIME

Maximum number of logical cores and feature set from available CPUs with the realtime kernel

 

System Virtualization

INFO and CORE and MEMORY on the guest

INFO and CORE and MEMORY on the guest

A fully virtualized guest environment

 
[a] Use HW_PROFILER test while testing with RHEL 8 or RHEL 7 else use PROFILER test while testing with RHEL 6.
[b] The Core clock speed, FSB speed, cache size, cache depth and manufacturing size are not considered for feature set review.
[c] The minimum installed memory is required to match the System Memory testing requirement.
  • 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 ClassCatalog FeaturesRequired TestsRequired HardwareInstall, Boot, kdump

System Memory

Maximum supported System memory

Memory

Minimum of the lower of 1GB per logical CPU, system limit, or OS limit[a][b]

Install, Boot

NVDIMM - Memory Mode

NVDIMM - Memory Mode[c]

Memory[d]

Any size NVDIMM

Install, Boot

NVDIMM - App Direct

NVDIMM - AppDirect Mode[e]

NVDIMM[f]

Any size NVDIMM

Install, Boot, Kdump

[a] The current maximum memory listed in RHEL limits article will require additional testing when the maximum system memory is greater than the current maximum memory
[b] Additional testing may be required when the maximum system memory requires the use of NVDIMM(s)
[c] Available in RHEL versions 7.6 and later
[d] Additional EET testing is also required for NVDIMM - Memory Mode
[e] Available in RHEL versions 7.3 and later
[f] 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 ClassCatalog FeaturesRequired TestsRequired HardwareInstall, 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 class testing for each function/port[a][b]

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 ClassCatalog FeaturesRequired TestsRequired 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. USB Ports

Hardware ClassCatalog FeaturesRequired TestsRequired Hardware

USB 2.0, USB 3.1 (5 Gigabit), USB 3.1 (10 Gigabit), USB C (5 Gigabit), USB C (10 Gigabit)

USB 2.0,USB 3.1 (5 Gigabit) Ports, USB 3.1 (10 Gigabit) Ports, USB C (5 Gigabit) Ports, USB C (10 Gigabit) Ports

USB2, or USB3

Each port with a device with the equivalent capability hotplug.[a][b][c][d][e]

[a] In REHL 6.x all USB 3.x ports will be tested as USB 3.0.
[b] In all RHEL 7.x certifications, USB 3.1 gen2 ports require testing with RHEL 7.3 or higher.
[c] USB 3.1 gen2 ports that are tested only with the gen1 devices can be certified.
[d] USB 3.1 Gen2 at 10Gbps is supported in later versions of RHEL 7.
[e] USB 3.1 Gen2 ports are supported/tested at 5Gbps only, prior to RHEL 7.5 or later and RHEL 7.4 (EUS).

4.7.2. Management

The hardware features that are included in Management are:

Table 4.6. Console

Hardware ClassCatalog FeaturesRequired TestsRequired HardwareInstall, Boot, kdump

Display Adapters, and Virtual Consoles

Graphic Console

Video[a]

The lower of VRAM/VBIOS limits, panel capabilities, or 1024x768 at 24 or 32 BPP

Install[b], Boot

Laptop Panels

Graphic Console

Video [LID][c]

Native resolution[d][e] at adaptive or native color depths with available display + graphics controller combinations[f][g]

Install

[a] 3D/GPGU support is not currently tested
[b] Native resolutions not required during install
[c] Backlight must respond to lid switch if present.
[d] Compensation/Stretching does not qualify as native testing.
[e] A horizontal resolution of 1360 may be used on 1366 native panels.
[f] Optional graphics controllers excluded by other policies are not required to be tested. At least one display + controller combination is required for each display.
[g] Display and graphics controller combinations may be clarified in a Red Hat Knowledge Base Article entry to avoid confusion.
  • Leverage Notes: Identical removable cards or integrated chips without shared memory,processor-integrated. Decreases in video memory.

Table 4.7. Power Control

Hardware ClassCatalog FeaturesRequired TestsRequired 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.

4.7.3. Network

The hardware features that are included in Network are:

Table 4.8. Ethernet

Hardware ClassCatalog FeaturesRequired TestsRequired HardwareInstall, 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

1GigEthernet, 2.5GigEthernet, 5GigEthernet, 10GigEthernet, 20GigEthernet, 25GigEthernet, 40GigEthernet, 50GigEthernet, 100GigEthernet

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.9. Fibre Channel

Hardware ClassCatalog FeaturesRequired TestsRequired HardwareInstall, 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.10. iSCSI

Hardware ClassCatalog FeaturesRequired TestsRequired HardwareInstall, 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.11. Infiniband

Hardware ClassCatalog FeaturesRequired TestsRequired HardwareInstall, Boot, kdump

Infiniband[a]

QDR Infiniband, FDR Infiniband, EDR Infiniband

Infiniband_QDR, Infiniband_FDR, or Infiniband_ED

Each interface at maximum connection speed.[b][c]

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.12. iWarp

Hardware ClassCatalog FeaturesRequired TestsRequired Hardware

iWarp

10 Gigabit iWarp, 20 Gigabit iWarp, 25 Gigabit iWarp, 40 Gigabit iWarp, 50 Gigabit iWarp, 100 Gigabit iWarp

10GigiWarp, 20GigiWarp, 25GigiWarp, 40GigiWarp, 50GigiWarp, or 100GigiWarp

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.13. Omnipath

Hardware ClassCatalog FeaturesRequired TestsRequired 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.14. RDMA over Converged Ethernet (RoCE)

Hardware ClassCatalog FeaturesRequired TestsRequired 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

2.5 GigRoCE, 5 GigRoCE, 10GigRoCE, 20GigRoCE, 25GigRoCE, 40GigRoCE, 50GigRoCE, or 100GigRoCE

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.15. WiFi

Hardware ClassCatalog FeaturesRequired TestsRequired HardwareInstall,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]

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.

4.7.4. Storage

The hardware features that are included in Storage are:

Table 4.16. HBA, HDD, and SDD

Hardware ClassCatalog FeaturesRequired TestsRequired HardwareInstall, 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

[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.17. Tape

Hardware ClassCatalog FeaturesRequired TestsRequired Hardware

Tape Drives and Changers[a]

Tape drive, Tape changer

TAPE

Each drive

[a] Changers require manual testing with test description and results report
  • 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.18. Memory Cards or Readers

Hardware ClassCatalog FeaturesRequired TestsRequired HardwareInstall, 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.
Note

Multi-Readers follow the Multi-Port Adapter criteria.

Table 4.19. Optical

Hardware ClassCatalog FeaturesRequired TestsRequired HardwareInstall, 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.8. Additional Manual Testing

4.8.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.

Revised on 2019-09-11 12:21:16 UTC

Legal Notice

Copyright © 2019 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.