Red Hat Enterprise Linux Hardware Certification - Program Policy Guide
2017-03-28 17:21
477 查看
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_Hardware_Certification/1/html-single/Program_Policy_Guide/index.html
Red Hat Enterprise Linux Hardware Certification
Engineering Services
This document is licensed by Red Hat under the
Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks
must be removed.
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, 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 Software Collections 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.
Abstract
The Red Hat Hardware Certification Program Policy Guide covers the procedural, technical and policy requirements for achieving a Red Hat Hardware Certification.
1. Introduction
1.1. Audience1.2. Program Overview1.3. Certification
Prerequisites2. The Certification
Process
2.1.
Process Overview2.2.
The Certification Process
2.2.1.
Creating Accounts2.2.2.
Creating a Certification2.2.3.
Reviewing the Test Plan2.2.4.
Testing the Hardware2.2.5.
Sample Hardware2.2.6.
GSS Support Approval2.3.
Giving Feedback and Getting Help3. Hardware Certification
Policies
3.1.
Program Policies
3.1.1.
Policy Changes3.1.2. Red Hat
Enterprise Linux3.1.3. Red Hat Enterprise Linux
OpenStack Compute (optional)3.1.4. Red Hat Enterprise
MRG for Realtime (RHEL6) and Red Hat Enterprise Linux for Real Time (RHEL7)3.1.5.
Red Hat Gluster Storage for On-Premise3.1.6.
Certification Life-cycle3.1.7. Submission
Window3.1.8.
Original Certifications3.1.9.
Unpublished Certifications3.1.10. Component Leveraging3.1.11. Component
Leverage Pools3.1.12.
System Pass-Through Certifications3.1.13.
Component Pass-Through Certifications3.1.14. Re-Certification3.1.15. Known
Issues3.2.
Software Policies
3.2.1.
Test Suite Versions3.2.2.
Red Hat Enterprise Linux Versions3.2.3. Red Hat Enterprise
MRG Realtime and Red Hat Enterprise Linux for Real Time Versions3.2.4.
Unmodified Red Hat Enterprise Linux3.2.5.
Kernel Boot Parameters3.2.6. Drivers3.2.7.
SELinux (Red Hat Enterprise Linux 6 and 7)3.2.8.
Red Hat Enterprise Linux as a Host3.2.9.
Red Hat Enterprise Linux as a Guest (Special Partnerships only)3.3.
BIOS/Firmware Policies
3.3.1.
Production Level3.3.2. Changes3.3.3. Settings3.3.4. OS Loaded3.4.
Hardware Policies
3.4.1. Stand-Alone3.4.2.
Components and Peripherals3.4.3. Production
Level3.4.4. Changes3.4.5. Configuration
Limits3.4.6. Performance
Minimums4. Creating the Test Plan
4.1. Test Plan
Overview4.2. Models4.3. Options4.4. Non-OS
Features and Unintentional Features4.5. Minimum
Test Set4.6.
Installation, Boot, and Kdump Requirements4.7.
Hardware Class Requirements4.8. Additional
Manual Testing
4.8.1.
External Storage and Multipath HBAs
Prerequisites
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.
Red Hat Certified Engineer accreditation is preferred and suggested before participating.
the Red Hat Certification Catalog.
The certification process is described in
Chapter 2, The Certification Process. 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
Chapter 4, Creating the Test Plan to create a test plan suitable for your hardware specifications.
Chapter 3, Hardware Certification Policies describes each of the hardware certification policies in detail.
Red Hat certifies hardware models and not specific configurations of a model. All optional hardware configurations designated as part of the same model must be tested.
Testing must be performed with a standard installation of Red Hat Enterprise Linux without special configuration or additional software, including drivers which are not provided by Red Hat.
Certifications are currently available for:
Red Hat Enterprise Linux 6 and 7.
Also, optionally for:
Red Hat Enterprise Linux OpenStack Compute 8 and 9
Red Hat Enterprise MRG Realtime 2
Red Hat Enterprise Linux for Real Time 7
Process Overview2.2.
The Certification Process
2.2.1.
Creating Accounts2.2.2.
Creating a Certification2.2.3.
Reviewing the Test Plan2.2.4.
Testing the Hardware2.2.5.
Sample Hardware2.2.6.
GSS Support Approval2.3.
Giving Feedback and Getting Help
Create an account with the
Red Hat Customer Portal,
Red Hat Bugzilla, and the
Red Hat Hardware Program.
The latest release(s) of the certification test suite (2.6-x and above) provide partners who certify hardware, the ability to use their Red Hat Customer Portal single sign-on (SSO) credentials to log in to the Red Hat Certification site and
the Red Hat Certification test suite. The earlier versions of the certification test suite (2.5-x and below) support only the Bugzilla-based login. The Bugzilla-based login method will not be supported after September 2016. We recommend partners who are certifying
for the first time to create and use the Red Hat Customer Portal SSO credentials throughout the certification process.
Existing partners who have commenced the certification process using Bugzilla credentials are recommended to use the same to complete the certifications which are in progress.
Create a new certification in the Hardware Catalog.
Review the test plan created for your hardware.
Test your hardware until all criteria in the test plan are complete.
Ship representative hardware to a Red Hat office.
Attain support approval from Red Hat Global Support Services (GSS).
The certification is then published to the Red Hat Hardware Catalog located at
https://access.redhat.com/certifications..
Red Hat Hardware Program,
Red Hat Bugzilla, and the
Red Hat Hardware Catalog. When creating accounts, please ensure to use official company addresses; personal and anonymous email accounts will not be accepted.
Note
The latest release(s) of the certification test suite (2.6-x and above) provide partners who certify hardware, the ability to use their Red Hat Customer Portal single sign-on (SSO) credentials to log in to the Red Hat Certification site and
the Red Hat Certification test suite. The earlier versions of the certification test suite (2.5-x and below) support only the Bugzilla-based login. The Bugzilla-based login method will not be supported after September 2016. We recommend partners who are certifying
for the first time to use the Red Hat Customer Portal SSO credentials throughout the certification process. Existing partners who have commenced the certification process using Bugzilla credentials are recommended to use the same to complete the certifications
which are in progress.
Procedure 2.1. Creating Accounts
Create an account with the Red Hat Hardware Program.
Email your sales contact and ask to purchase membership in the program. If you do not have a sales contact at Red Hat, email your technical account manager, partner manager or use the address hwcert@redhat.com for assistance with purchasing
program membership.
Click the Register button and follow the steps to create a new account with the
Red Hat Hardware Program.
The account created during this step may also be on the
Red Hat Customer Portal and also to log in to the Red Hat Certification site and the Red Hat Certification test suite if you are using the latest release(s) of the certification test suite (2.6-x and above).
Create a Red Hat Bugzilla account
We recommend partners who are certifying for the first time to use the Red Hat Customer Portal SSO credentials throughout the certification process. Existing partners who have commenced the certification process using Bugzilla credentials
are recommended to use the same to complete the certifications which are in progress.
The account created with the
Red Hat Hardware Program may be used on the
Red Hat Customer Portal, the Red Hat Certification site and the Red Hat Certification test suite if you are using the latest release(s) of the certification test suite (2.6-x and above).
Navigate to https://bugzilla.redhat.com/.
Select New Account in the menu and follow the instructions.
The Red Hat Bugzilla account is also used on the Hardware Catalog.
Obtain Red Hat Hardware Catalog permissions.
File a support request (see
Section 2.3, “Giving Feedback and Getting Help”) for create permissions; include your Red Hat Hardware Program (may also be used on the Customer Portal) and Bugzilla login names. A Bugzilla login name is only required
if you choose to complete the certification process using Bugzilla credentials supported in certification test suite version(s) 2.5-x and below.
After this request has been approved, the
Create button appears in the Hardware Catalog menu; this allows you to create a new certification request (see
Figure 2.1, “The Hardware Catalog Menu”).
a test plan for your hardware.
Procedure 2.2. Create a Certification using the Hardware Catalog.
To begin, you must log in to the catalog website located at https://hardware.redhat.com using Red Hat Bugzilla or Red Hat Customer Portal SSO credentials (whichever is applicable).
To log in the catalog website using Bugzilla credentials, navigate to
https://hardware.redhat.com/, click on the "Hardware Vendor Login" link, then log in to your Hardware Catalog account using your Red Hat Bugzilla login credentials.
To log in to the catalog website using Red Hat Customer Portal SSO account credentials, navigate to
https://hardware.redhat.com/, click the
Account button at the top right of the catalog website and log in using the credentials used on
Red Hat Hardware Program. You may also create and use an independent Red Hat Customer Portal SSO account. However it must be an organization account and not a personal account.
Click the Create create link from the
Hardware Catalog menu.
Figure 2.1. The Hardware Catalog Menu
Complete the certification form.
Be certain to provide the product specification in the the
Product Page URL field. The specifications provided to Red Hat are expected to be the same as would be provided to any customer. The preferred method to provide specifications is via the
Specification URL field as shown in
Figure 2.2, “The Certification Form - Certification Information” or by attaching the specification document using the
Upload Specification section.
Important
Red Hat does not create test plans for certifications without product specifications.
To upload a result package containing your hardware product data, select the
Acquire from Package radio button in the
Product Data Source field shown below. Alternatively, select the
Provide Manually radio button.
Figure 2.2. The Certification Form - Certification Information
Depending on the radio button selected, complete either the
Hardware Product Data or Upload Certification Package section.
Figure 2.3. The Certification Form - Hardware Product Data
Upload and provide a brief description of the test result package.
Figure 2.4. The Certification Form - Upload Certification Package
Click Continue to submit the request.
Record the Hardware Certification number displayed on the following screen.
in this guide. Ensure you understand the test plan creation process (Chapter 4,
Creating the Test Plan), as it defines the criteria required of your hardware.
Procedure 2.3. Review the Test Plan
Navigate to https://hardware.redhat.com/ and log on to your Hardware Catalog account.
Find your system in the Hardware Catalog using either the search functionality located at the top of the page, or by scrolling through the catalog.
Figure 2.5. The Hardware Catalog Search Bar
Click on the Review link in the
Sections list at the top of the page and scroll down to the
Test Plan Progress subsection.
Figure 2.6. Sections in the Hardware Catalog
Read through the test plan and ensure you understand how the requirements specified in
Section 4.7, “Hardware Class Requirements” apply to your hardware.
The figure below is an excerpt from a partially completed test plan. As results are submitted, the review team will analyze the packages and edits the test plan accordingly. The system under test in
Figure 2.7, “The Test Plan Section” shows one hardware test (MEMORY) completed, one hardware test (STORAGE) pending confirmation from a review, and two hardware
tests (CORE and
DVD) pending results from the vendor.
Figure 2.7. The Test Plan Section
Melted or Frozen.
Melted
The melted state indicates that the test plan is inaccurate or incomplete and is under review by the reviewer assigned to your certification. During this period the reviewer can alter the test plan, therefore, no test results are reviewed
when a test plan is in a melted state.
Important
Red Hat does not perform package reviews on certifications with melted test plans.
Should you find any inaccuracies with the test plan, you must
melt the plan. This process is described in
Procedure 2.4, “Changing the State of the Test Plan”.
Frozen
The frozen state indicates that the current test plan is valid and complete for the hardware listed in the specification. Test results submitted against a valid test plan are reviewed and recorded in the
Test Plan Progress section.
Procedure 2.4. Changing the State of the Test Plan
Log on to your
Hardware Catalog account and navigate to your certification.
In the Test Plan State section, select the
Change Test Plan to radio button and select
Melted in the drop down box.
Figure 2.8. The Test Plan State
Click the Save Changes button to submit.
Add a comment to the certification that describes why you have melted the plan. This process is described in the procedure
Procedure 2.5, “Adding a Comment to the Certification” below.
Procedure 2.5. Adding a Comment to the Certification
Log on to your account in the Hardware Catalog and navigate to the
Dialog tab.
In the Add Additional Comment section, enter the message in the text box.
Figure 2.9. The Add Additional Comment Section
Select either the No response requested or the
Request Information From radio button. The latter allows you to choose the intended message recipient.
Click the Save Changes button to send the message.
Red Hat Enterprise Linux Hardware Test Suite
Testing is performed by executing the hardware certification Test Suite, which is available from the
Red Hat Customer Portal. Test results are uploaded via your certification in the hardware catalog and reviewed by the Red Hat Hardware Certification team. A continuous cycle of testing and evaluation is
performed until all test plan criteria are passed. Refer to the
Hardware Certification How To Wiki at https://fedorahosted.org/v7/wiki/HwCertHowTo/ for information on the usage of and system configuration for the Hardware Test Suite.
The Red Hat Enterprise Linux Hardware Test Suite is open source software. Anyone can download the test suite RPMs, install them, and run the tests on their own hardware. This ad-hoc testing can be useful for discovering and diagnosing issues
before creating a certification request. Such testing is not a substitute for formal certification. A test plan is created after your request has been submitted and only then can the exact criteria to achieve certification be known. Informal testing with the
Test Suite should, therefore, be treated as such: an informal pre-cursor to certification.
Resources
The Red Hat Enterprise Linux Deployment Guide located at
https://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/ is a useful source of information regarding the deployment, configuration and administration of Red Hat Enterprise Linux. You may find this manual a useful reference during the hardware
testing stage.
The Hardware Certification How To Wiki located at
https://fedorahosted.org/v7/wiki/HwCertHowTo/ is a wiki which provides information regarding the hardware certification program, tooling and process. It includes guidance on best practices,
additional explanation on some of the more complex certification concepts, as well as detailed instruction on running individual tests. You may find this a useful reference and may also contribute to it, as it is in the wiki format.
Procedure 2.6. Testing Hardware
Execute the
Upload test result packages via your certification request.
Navigate to your certification request and click on the
Review section as is described in the procedure,
Procedure 2.3, “Review the Test Plan”.
Scroll down to the section, Upload Results Package or Other Document and complete the form. Please provide a comment describing what tests are expected to be covered by the attached result in
the comment box to expedite review.
Figure 2.10. Uploading Test Result Packages
Click on the Attach File button to submit your package.
The reviewer team will analyze the package and record the result in the
Test Plan Progress table (see
Figure 2.7, “The Test Plan Section”.
Note
Product Specification document must be submitted while filling the hardware details during certification creation.
Provide test plan leverage data (Optional)
To submit leverage data, choose one of the leverage options from the drop-down. Enter the hardware certification test identification number from which the leveraged data has come from.
The Red Hat Hardware Certification team reviews the leveraged data and records the results in the certification. Credited items are marked complete in the
Test Plan Progress section. Refer to the
Section 3.1.10, “Component Leveraging” section for more information.
Important
Comments and attachments identifying leveraged data are not reviewed. The procedure described above must be used.
Repeat this procedure until all test plan items in the
Test Plan Progress are marked as Confirmed.
testing. Hardware samples should be of configurations that provide full functionality of all model features. The prescribed test plan (see
Chapter 4, Creating the Test Plan) may be used as a minimum configuration guideline however Red Hat Support may 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 may 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.
Support ACK check-box on the
GSS Requirements dialog. If for any reason GSS is unable to acknowledge support approval, contact your TAM or support representative.
After the representative hardware has been received by Red Hat, and GSS has acknowledged their support, your certification is made public in the
Hardware Catalog.
We Need Feedback!
If you find a typographical error in this guide, or if you have thought of a way to improve the certification program, we would love to hear from you! Please 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, 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 at http://access.redhat.com. 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.
Procedure 2.5, “Adding a Comment to the Certification” above describes how to post a comment.
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.
Program Policies
3.1.1.
Policy Changes3.1.2. Red Hat
Enterprise Linux3.1.3. Red Hat Enterprise Linux
OpenStack Compute (optional)3.1.4. Red Hat Enterprise
MRG for Realtime (RHEL6) and Red Hat Enterprise Linux for Real Time (RHEL7)3.1.5.
Red Hat Gluster Storage for On-Premise3.1.6.
Certification Life-cycle3.1.7. Submission
Window3.1.8.
Original Certifications3.1.9.
Unpublished Certifications3.1.10. Component Leveraging3.1.11. Component
Leverage Pools3.1.12.
System Pass-Through Certifications3.1.13.
Component Pass-Through Certifications3.1.14. Re-Certification3.1.15. Known
Issues3.2.
Software Policies
3.2.1.
Test Suite Versions3.2.2.
Red Hat Enterprise Linux Versions3.2.3. Red Hat Enterprise
MRG Realtime and Red Hat Enterprise Linux for Real Time Versions3.2.4.
Unmodified Red Hat Enterprise Linux3.2.5.
Kernel Boot Parameters3.2.6. Drivers3.2.7.
SELinux (Red Hat Enterprise Linux 6 and 7)3.2.8.
Red Hat Enterprise Linux as a Host3.2.9.
Red Hat Enterprise Linux as a Guest (Special Partnerships only)3.3.
BIOS/Firmware Policies
3.3.1.
Production Level3.3.2. Changes3.3.3. Settings3.3.4. OS Loaded3.4.
Hardware Policies
3.4.1. Stand-Alone3.4.2.
Components and Peripherals3.4.3. Production
Level3.4.4. Changes3.4.5. Configuration
Limits3.4.6. Performance
Minimums
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. The 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. The web interface (https://www.redhat.com/mailman/listinfo/hwcert-announce-list)
may be used to subscribe to the list. Changes to the test suite will also be documented in the test suite errata notification and package changelog.
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 or 7.
Important
Red Hat no longer certifies hardware for Red Hat Enterprise Linux versions 2.1, 3, 4, or 5 on any architecture.
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, and is optionally available for select partners who are certifying for Red Hat Enterprise Linux 6.
A corresponding Red Hat Enterprise Linux OpenStack Platform Compute certification is automatically created when a new server certification request for Red Hat Enterprise Linux 7 is opened. Selected partners have the option to automatically
create a corresponding Red Hat Enterprise Linux OpenStack Platform Compute certification when creating a new Red Hat Enterprise Linux 6 certification request. Partners wanting to create a Red Hat Enterprise Linux OpenStack Platform Compute certification entry
for an existing Red Hat Enterprise Linux 6 certified server may do so in the Hardware Catalog by going to the Advanced section of the desired Red Hat Enterprise Linux 6 certification and then filling out the fields under the "Create New Layered Product Certification
- "Red Hat Enterprise Linux OpenStack Platform" heading.
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.
Important
Red Hat no longer certifies hardware for Red Hat Enterprise Linux Openstack Platform versions 3, or 4.
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 realtime test which may be performed to achieve Realtime
certification after completing the base Red Hat Enterprise Linux certification (see
Table 4.1, “Requirements by Class”). The additional Realtime packages will need to be installed and running to execute these tests.
Hardware Certification Partners may create new Realtime certifications requests in the Certification Workflow by selecting an existing Red Hat Enterprise Linux 6 or 7 certification entry, going to the
Advanced section, and then filling out the fields under the
Create New Layered Product Certification - MRG Realtime or RHEL Realtime heading. The base Red Hat Enterprise Linux certification is required to be completed and posted before the Realtime results will be reviewed.
Important
Red Hat no longer certifies hardware for any Red Hat Enterprise MRG Realtime 1.x versions.
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 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 server certification request. Partners who want to create an Red Hat Gluster Storage certification entry
for an existing Red Hat Enterprise Linux 6 certified server may do so in the Hardware Catalog by going to the Advanced section of the desired Red Hat Enterprise Linux 6 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 for Red Hat Gluster Storage should follow the
Red Hat Storage Architectural Review Process for further 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 the Knowledge Base article mentioned earlier 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.
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 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 (a) re-certification is required, (b) Red Hat no longer supports that version of Red Hat Enterprise Linux, or (c) the vendor ceases participation in the Hardware Program. This life-cycle policy also applies to both Red Hat Enterprise MRG Realtime, Red
hat Enterprise for Real Time, and Red Hat OpenStack optional certifications.
of Red Hat Enterprise Linux OpenStack Platform may typically be submitted until the second subsequent major version of Red Hat Enterprise Linux OpenStack Platform is released. New hardware certifications for a given major release of Red Hat Enterprse MRG may
typically be submitted until the next subsequent major version of Red Hat Enterprise MRG 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 Hardware Partner
Manager or Partner TAM. Certification requests that fall outside of the normal windows must be raised to your Hardware Partner Manager or Partner TAM. 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.).
partners may 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.
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.
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.13, “Component Pass-Through Certifications”. Additional requirements for leveraging are provided in
Table 4.1, “Requirements by Class”.
certifications. 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 may 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.
granted to their systems to another vendor's system where the original vendor (a) has permission from the third party, (b) 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 (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). 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.
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.11, “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.
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.
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.
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.2.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 and Red Hat Enterprise Linux 7 Server. 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.
Enterprise Linux. When a new Red Hat Enterprise MRG Realtime or 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.
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.
Red Hat Knowledge Base Solution associated with the certification listing.
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
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
Table 4.1, “Requirements by Class”) 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
Chapter 3, Hardware 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
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.
Table 4.1, “Requirements by Class” - System Virtualization for the specific list of required tests.
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.
Section 3.3.2, “Changes” criteria. The tested or subsequent revision is required to be available to customers by the posting date of the certification.
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.
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.
in a Red Hat Knowledge Base Solution associated to the certification listing.
if the console was only accessible via Internet Explorer on another system.
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.
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.
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.
is determined.
Overview4.2. Models4.3. Options4.4. Non-OS
Features and Unintentional Features4.5. Minimum
Test Set4.6.
Installation, Boot, and Kdump Requirements4.7.
Hardware Class Requirements4.8. Additional
Manual Testing
4.8.1.
External Storage and Multipath HBAs
Table 4.1, “Requirements by Class” is 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:
Define the model by its specification (Section 4.2,
“Models”)
Determine the options (Section 4.3,
“Options”)
Remove unsupported operating system features and unintentional hardware (Section 4.4,
“Non-OS Features and Unintentional Features”)
Apply the minimum test set criteria (Section 4.5,
“Minimum Test Set”)
Add the install, boot, and kdump requirements (Section 4.6,
“Installation, Boot, and Kdump Requirements”)
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 (see
Figure 2.7, “The Test Plan Section”). To post comments or questions about the test plan, refer to the procedure,
Procedure 2.5, “Adding a Comment to the Certification”.
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.
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.
Note
Optional Hardware was previously referred to as Config-To-Order (CTO). Additional Hardware was previously referred to as After-Market (AM).
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.
[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.
Important
Processor and memory are always considered integrated and unique.
Important
Integrated graphics controllers and displays are always considered integrated and unique.
As an example, if a system is available with and without a SCSI 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 includes
the SCSI controller and the two remaining optional network cards.
The Hardware Changes policy (see
Section 3.4.4, “Changes”) may be utilized when Optional Hardware (see
Section 4.2, “Models”) causes a newer than desired 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 release
required by the Optional Hardware.
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.
and timing. For these reasons we have defined a minimum test set policy by hardware class in the
Table 4.1, “Requirements by Class” table. These requirements are not intended as product release criteria and it is expected that internal Red Hat Enterprise Linux qualification testing in addition to and prior to certification testing is conducted.
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.
Table 4.1, “Requirements by Class” 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 and 7. 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 and 7 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.
Table 4.1. Requirements by Class
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.
[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...").
Red Hat Enterprise Linux Hardware Certification
Program Policy Guide
The Policies and Procedures of Hardware Certification
Edition 7.0-3Rob Landry
Red Hat, Inc.Engineering Services
rlandry@redhat.com
Legal Notice
Copyright © 2016 Red Hat, Inc.This document is licensed by Red Hat under the
Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks
must be removed.
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, 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 Software Collections 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.
Abstract
The Red Hat Hardware Certification Program Policy Guide covers the procedural, technical and policy requirements for achieving a Red Hat Hardware Certification.
1. Introduction
1.1. Audience1.2. Program Overview1.3. Certification
Prerequisites2. The Certification
Process
2.1.
Process Overview2.2.
The Certification Process
2.2.1.
Creating Accounts2.2.2.
Creating a Certification2.2.3.
Reviewing the Test Plan2.2.4.
Testing the Hardware2.2.5.
Sample Hardware2.2.6.
GSS Support Approval2.3.
Giving Feedback and Getting Help3. Hardware Certification
Policies
3.1.
Program Policies
3.1.1.
Policy Changes3.1.2. Red Hat
Enterprise Linux3.1.3. Red Hat Enterprise Linux
OpenStack Compute (optional)3.1.4. Red Hat Enterprise
MRG for Realtime (RHEL6) and Red Hat Enterprise Linux for Real Time (RHEL7)3.1.5.
Red Hat Gluster Storage for On-Premise3.1.6.
Certification Life-cycle3.1.7. Submission
Window3.1.8.
Original Certifications3.1.9.
Unpublished Certifications3.1.10. Component Leveraging3.1.11. Component
Leverage Pools3.1.12.
System Pass-Through Certifications3.1.13.
Component Pass-Through Certifications3.1.14. Re-Certification3.1.15. Known
Issues3.2.
Software Policies
3.2.1.
Test Suite Versions3.2.2.
Red Hat Enterprise Linux Versions3.2.3. Red Hat Enterprise
MRG Realtime and Red Hat Enterprise Linux for Real Time Versions3.2.4.
Unmodified Red Hat Enterprise Linux3.2.5.
Kernel Boot Parameters3.2.6. Drivers3.2.7.
SELinux (Red Hat Enterprise Linux 6 and 7)3.2.8.
Red Hat Enterprise Linux as a Host3.2.9.
Red Hat Enterprise Linux as a Guest (Special Partnerships only)3.3.
BIOS/Firmware Policies
3.3.1.
Production Level3.3.2. Changes3.3.3. Settings3.3.4. OS Loaded3.4.
Hardware Policies
3.4.1. Stand-Alone3.4.2.
Components and Peripherals3.4.3. Production
Level3.4.4. Changes3.4.5. Configuration
Limits3.4.6. Performance
Minimums4. Creating the Test Plan
4.1. Test Plan
Overview4.2. Models4.3. Options4.4. Non-OS
Features and Unintentional Features4.5. Minimum
Test Set4.6.
Installation, Boot, and Kdump Requirements4.7.
Hardware Class Requirements4.8. Additional
Manual Testing
4.8.1.
External Storage and Multipath HBAs
Chapter 1. Introduction
1.1. Audience1.2. Program Overview1.3. CertificationPrerequisites
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.1. Audience
The Red Hat Hardware Certification 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. ARed Hat Certified Engineer accreditation is preferred and suggested before participating.
1.2. 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 inthe Red Hat Certification Catalog.
The certification process is described in
Chapter 2, The Certification Process. 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
Chapter 4, Creating the Test Plan to create a test plan suitable for your hardware specifications.
1.3. Certification Prerequisites
To ensure you are eligible to join the Hardware Certification Program, a summary of the most important polices is listed below.Chapter 3, Hardware Certification Policies describes each of the hardware certification policies in detail.
Red Hat certifies hardware models and not specific configurations of a model. All optional hardware configurations designated as part of the same model must be tested.
Testing must be performed with a standard installation of Red Hat Enterprise Linux without special configuration or additional software, including drivers which are not provided by Red Hat.
Certifications are currently available for:
Red Hat Enterprise Linux 6 and 7.
Also, optionally for:
Red Hat Enterprise Linux OpenStack Compute 8 and 9
Red Hat Enterprise MRG Realtime 2
Red Hat Enterprise Linux for Real Time 7
Chapter 2. The Certification Process
2.1.Process Overview2.2.
The Certification Process
2.2.1.
Creating Accounts2.2.2.
Creating a Certification2.2.3.
Reviewing the Test Plan2.2.4.
Testing the Hardware2.2.5.
Sample Hardware2.2.6.
GSS Support Approval2.3.
Giving Feedback and Getting Help
2.1. Process Overview
The following steps outline the certification process.Create an account with the
Red Hat Customer Portal,
Red Hat Bugzilla, and the
Red Hat Hardware Program.
The latest release(s) of the certification test suite (2.6-x and above) provide partners who certify hardware, the ability to use their Red Hat Customer Portal single sign-on (SSO) credentials to log in to the Red Hat Certification site and
the Red Hat Certification test suite. The earlier versions of the certification test suite (2.5-x and below) support only the Bugzilla-based login. The Bugzilla-based login method will not be supported after September 2016. We recommend partners who are certifying
for the first time to create and use the Red Hat Customer Portal SSO credentials throughout the certification process.
Existing partners who have commenced the certification process using Bugzilla credentials are recommended to use the same to complete the certifications which are in progress.
Create a new certification in the Hardware Catalog.
Review the test plan created for your hardware.
Test your hardware until all criteria in the test plan are complete.
Ship representative hardware to a Red Hat office.
Attain support approval from Red Hat Global Support Services (GSS).
The certification is then published to the Red Hat Hardware Catalog located at
https://access.redhat.com/certifications..
2.2. The Certification Process
2.2.1. Creating Accounts
Complete the procedure below to create an account with theRed Hat Hardware Program,
Red Hat Bugzilla, and the
Red Hat Hardware Catalog. When creating accounts, please ensure to use official company addresses; personal and anonymous email accounts will not be accepted.
Note
The latest release(s) of the certification test suite (2.6-x and above) provide partners who certify hardware, the ability to use their Red Hat Customer Portal single sign-on (SSO) credentials to log in to the Red Hat Certification site and
the Red Hat Certification test suite. The earlier versions of the certification test suite (2.5-x and below) support only the Bugzilla-based login. The Bugzilla-based login method will not be supported after September 2016. We recommend partners who are certifying
for the first time to use the Red Hat Customer Portal SSO credentials throughout the certification process. Existing partners who have commenced the certification process using Bugzilla credentials are recommended to use the same to complete the certifications
which are in progress.
Procedure 2.1. Creating Accounts
Create an account with the Red Hat Hardware Program.
Email your sales contact and ask to purchase membership in the program. If you do not have a sales contact at Red Hat, email your technical account manager, partner manager or use the address hwcert@redhat.com for assistance with purchasing
program membership.
Click the Register button and follow the steps to create a new account with the
Red Hat Hardware Program.
The account created during this step may also be on the
Red Hat Customer Portal and also to log in to the Red Hat Certification site and the Red Hat Certification test suite if you are using the latest release(s) of the certification test suite (2.6-x and above).
Create a Red Hat Bugzilla account
We recommend partners who are certifying for the first time to use the Red Hat Customer Portal SSO credentials throughout the certification process. Existing partners who have commenced the certification process using Bugzilla credentials
are recommended to use the same to complete the certifications which are in progress.
The account created with the
Red Hat Hardware Program may be used on the
Red Hat Customer Portal, the Red Hat Certification site and the Red Hat Certification test suite if you are using the latest release(s) of the certification test suite (2.6-x and above).
Navigate to https://bugzilla.redhat.com/.
Select New Account in the menu and follow the instructions.
The Red Hat Bugzilla account is also used on the Hardware Catalog.
Obtain Red Hat Hardware Catalog permissions.
File a support request (see
Section 2.3, “Giving Feedback and Getting Help”) for create permissions; include your Red Hat Hardware Program (may also be used on the Customer Portal) and Bugzilla login names. A Bugzilla login name is only required
if you choose to complete the certification process using Bugzilla credentials supported in certification test suite version(s) 2.5-x and below.
After this request has been approved, the
Create button appears in the Hardware Catalog menu; this allows you to create a new certification request (see
Figure 2.1, “The Hardware Catalog Menu”).
2.2.2. Creating a Certification
The Create certification form creates a new request for the Hardware Certification Team. You must provide Vendor, Make, and Model information as well as a URL to the hardware specification. This information is used by our engineers to createa test plan for your hardware.
Procedure 2.2. Create a Certification using the Hardware Catalog.
To begin, you must log in to the catalog website located at https://hardware.redhat.com using Red Hat Bugzilla or Red Hat Customer Portal SSO credentials (whichever is applicable).
To log in the catalog website using Bugzilla credentials, navigate to
https://hardware.redhat.com/, click on the "Hardware Vendor Login" link, then log in to your Hardware Catalog account using your Red Hat Bugzilla login credentials.
To log in to the catalog website using Red Hat Customer Portal SSO account credentials, navigate to
https://hardware.redhat.com/, click the
Account button at the top right of the catalog website and log in using the credentials used on
Red Hat Hardware Program. You may also create and use an independent Red Hat Customer Portal SSO account. However it must be an organization account and not a personal account.
Click the Create create link from the
Hardware Catalog menu.
Figure 2.1. The Hardware Catalog Menu
Complete the certification form.
Be certain to provide the product specification in the the
Product Page URL field. The specifications provided to Red Hat are expected to be the same as would be provided to any customer. The preferred method to provide specifications is via the
Specification URL field as shown in
Figure 2.2, “The Certification Form - Certification Information” or by attaching the specification document using the
Upload Specification section.
Important
Red Hat does not create test plans for certifications without product specifications.
To upload a result package containing your hardware product data, select the
Acquire from Package radio button in the
Product Data Source field shown below. Alternatively, select the
Provide Manually radio button.
Figure 2.2. The Certification Form - Certification Information
Depending on the radio button selected, complete either the
Hardware Product Data or Upload Certification Package section.
Figure 2.3. The Certification Form - Hardware Product Data
Upload and provide a brief description of the test result package.
Figure 2.4. The Certification Form - Upload Certification Package
Click Continue to submit the request.
Record the Hardware Certification number displayed on the following screen.
2.2.3. Reviewing the Test Plan
An engineer from the Red Hat Hardware Certification Team, otherwise known as a reviewer, is assigned to your certification request. The reviewer creates a test plan for your system that is consistent with the policies and criteria definedin this guide. Ensure you understand the test plan creation process (Chapter 4,
Creating the Test Plan), as it defines the criteria required of your hardware.
Procedure 2.3. Review the Test Plan
Navigate to https://hardware.redhat.com/ and log on to your Hardware Catalog account.
Find your system in the Hardware Catalog using either the search functionality located at the top of the page, or by scrolling through the catalog.
Figure 2.5. The Hardware Catalog Search Bar
Click on the Review link in the
Sections list at the top of the page and scroll down to the
Test Plan Progress subsection.
Figure 2.6. Sections in the Hardware Catalog
Read through the test plan and ensure you understand how the requirements specified in
Section 4.7, “Hardware Class Requirements” apply to your hardware.
The figure below is an excerpt from a partially completed test plan. As results are submitted, the review team will analyze the packages and edits the test plan accordingly. The system under test in
Figure 2.7, “The Test Plan Section” shows one hardware test (MEMORY) completed, one hardware test (STORAGE) pending confirmation from a review, and two hardware
tests (CORE and
DVD) pending results from the vendor.
Figure 2.7. The Test Plan Section
2.2.3.1. The Test Plan State
A test plan can be in one of two states,Melted or Frozen.
Melted
The melted state indicates that the test plan is inaccurate or incomplete and is under review by the reviewer assigned to your certification. During this period the reviewer can alter the test plan, therefore, no test results are reviewed
when a test plan is in a melted state.
Important
Red Hat does not perform package reviews on certifications with melted test plans.
Should you find any inaccuracies with the test plan, you must
melt the plan. This process is described in
Procedure 2.4, “Changing the State of the Test Plan”.
Frozen
The frozen state indicates that the current test plan is valid and complete for the hardware listed in the specification. Test results submitted against a valid test plan are reviewed and recorded in the
Test Plan Progress section.
Procedure 2.4. Changing the State of the Test Plan
Log on to your
Hardware Catalog account and navigate to your certification.
In the Test Plan State section, select the
Change Test Plan to radio button and select
Melted in the drop down box.
Figure 2.8. The Test Plan State
Click the Save Changes button to submit.
Add a comment to the certification that describes why you have melted the plan. This process is described in the procedure
Procedure 2.5, “Adding a Comment to the Certification” below.
Procedure 2.5. Adding a Comment to the Certification
Log on to your account in the Hardware Catalog and navigate to the
Dialog tab.
In the Add Additional Comment section, enter the message in the text box.
Figure 2.9. The Add Additional Comment Section
Select either the No response requested or the
Request Information From radio button. The latter allows you to choose the intended message recipient.
Click the Save Changes button to send the message.
2.2.4. Testing the Hardware
Red Hat Enterprise Linux Hardware Test Suite
Testing is performed by executing the hardware certification Test Suite, which is available from the
Red Hat Customer Portal. Test results are uploaded via your certification in the hardware catalog and reviewed by the Red Hat Hardware Certification team. A continuous cycle of testing and evaluation is
performed until all test plan criteria are passed. Refer to the
Hardware Certification How To Wiki at https://fedorahosted.org/v7/wiki/HwCertHowTo/ for information on the usage of and system configuration for the Hardware Test Suite.
The Red Hat Enterprise Linux Hardware Test Suite is open source software. Anyone can download the test suite RPMs, install them, and run the tests on their own hardware. This ad-hoc testing can be useful for discovering and diagnosing issues
before creating a certification request. Such testing is not a substitute for formal certification. A test plan is created after your request has been submitted and only then can the exact criteria to achieve certification be known. Informal testing with the
Test Suite should, therefore, be treated as such: an informal pre-cursor to certification.
Resources
The Red Hat Enterprise Linux Deployment Guide located at
https://access.redhat.com/site/documentation/Red_Hat_Enterprise_Linux/ is a useful source of information regarding the deployment, configuration and administration of Red Hat Enterprise Linux. You may find this manual a useful reference during the hardware
testing stage.
The Hardware Certification How To Wiki located at
https://fedorahosted.org/v7/wiki/HwCertHowTo/ is a wiki which provides information regarding the hardware certification program, tooling and process. It includes guidance on best practices,
additional explanation on some of the more complex certification concepts, as well as detailed instruction on running individual tests. You may find this a useful reference and may also contribute to it, as it is in the wiki format.
Procedure 2.6. Testing Hardware
Execute the
hwcertutility on the hardware described in the test plan.
Upload test result packages via your certification request.
Navigate to your certification request and click on the
Review section as is described in the procedure,
Procedure 2.3, “Review the Test Plan”.
Scroll down to the section, Upload Results Package or Other Document and complete the form. Please provide a comment describing what tests are expected to be covered by the attached result in
the comment box to expedite review.
Figure 2.10. Uploading Test Result Packages
Click on the Attach File button to submit your package.
The reviewer team will analyze the package and record the result in the
Test Plan Progress table (see
Figure 2.7, “The Test Plan Section”.
Note
Product Specification document must be submitted while filling the hardware details during certification creation.
Provide test plan leverage data (Optional)
To submit leverage data, choose one of the leverage options from the drop-down. Enter the hardware certification test identification number from which the leveraged data has come from.
The Red Hat Hardware Certification team reviews the leveraged data and records the results in the certification. Credited items are marked complete in the
Test Plan Progress section. Refer to the
Section 3.1.10, “Component Leveraging” section for more information.
Important
Comments and attachments identifying leveraged data are not reviewed. The procedure described above must be used.
Repeat this procedure until all test plan items in the
Test Plan Progress are marked as Confirmed.
2.2.5. 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 producttesting. Hardware samples should be of configurations that provide full functionality of all model features. The prescribed test plan (see
Chapter 4, Creating the Test Plan) may be used as a minimum configuration guideline however Red Hat Support may 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 may 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.
2.2.6. GSS Support Approval
Red Hat GSS reviews support and engineering problem queues for known issues. After establishing that all hardware criteria have been met, and verifying that there are no known issues, GSS marks theSupport ACK check-box on the
GSS Requirements dialog. If for any reason GSS is unable to acknowledge support approval, contact your TAM or support representative.
After the representative hardware has been received by Red Hat, and GSS has acknowledged their support, your certification is made public in the
Hardware Catalog.
2.3. Giving Feedback and Getting Help
We Need Feedback!
If you find a typographical error in this guide, or if you have thought of a way to improve the certification program, we would love to hear from you! Please 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, 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 at http://access.redhat.com. 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.
Procedure 2.5, “Adding a Comment to the Certification” above describes how to post a comment.
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 3. Hardware Certification Policies
3.1.Program Policies
3.1.1.
Policy Changes3.1.2. Red Hat
Enterprise Linux3.1.3. Red Hat Enterprise Linux
OpenStack Compute (optional)3.1.4. Red Hat Enterprise
MRG for Realtime (RHEL6) and Red Hat Enterprise Linux for Real Time (RHEL7)3.1.5.
Red Hat Gluster Storage for On-Premise3.1.6.
Certification Life-cycle3.1.7. Submission
Window3.1.8.
Original Certifications3.1.9.
Unpublished Certifications3.1.10. Component Leveraging3.1.11. Component
Leverage Pools3.1.12.
System Pass-Through Certifications3.1.13.
Component Pass-Through Certifications3.1.14. Re-Certification3.1.15. Known
Issues3.2.
Software Policies
3.2.1.
Test Suite Versions3.2.2.
Red Hat Enterprise Linux Versions3.2.3. Red Hat Enterprise
MRG Realtime and Red Hat Enterprise Linux for Real Time Versions3.2.4.
Unmodified Red Hat Enterprise Linux3.2.5.
Kernel Boot Parameters3.2.6. Drivers3.2.7.
SELinux (Red Hat Enterprise Linux 6 and 7)3.2.8.
Red Hat Enterprise Linux as a Host3.2.9.
Red Hat Enterprise Linux as a Guest (Special Partnerships only)3.3.
BIOS/Firmware Policies
3.3.1.
Production Level3.3.2. Changes3.3.3. Settings3.3.4. OS Loaded3.4.
Hardware Policies
3.4.1. Stand-Alone3.4.2.
Components and Peripherals3.4.3. Production
Level3.4.4. Changes3.4.5. Configuration
Limits3.4.6. Performance
Minimums
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 may 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. The 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. The web interface (https://www.redhat.com/mailman/listinfo/hwcert-announce-list)
may be used to subscribe to the list. Changes to the test suite will also be documented in the test suite errata notification and package changelog.
3.1.2. 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 Linuxfor 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 or 7.
Important
Red Hat no longer certifies hardware for Red Hat Enterprise Linux versions 2.1, 3, 4, or 5 on any architecture.
3.1.3. Red Hat Enterprise Linux OpenStack Compute (optional)
Red Hat Enterprise Linux OpenStack Platform delivers the Red Hat OpenStack technology optimized for and integrated with Red Hat Enterprise Linux. Red Hat Enterprise Linux OpenStack Platform consists of additional packages that expand the capabilitiesof 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, and is optionally available for select partners who are certifying for Red Hat Enterprise Linux 6.
A corresponding Red Hat Enterprise Linux OpenStack Platform Compute certification is automatically created when a new server certification request for Red Hat Enterprise Linux 7 is opened. Selected partners have the option to automatically
create a corresponding Red Hat Enterprise Linux OpenStack Platform Compute certification when creating a new Red Hat Enterprise Linux 6 certification request. Partners wanting to create a Red Hat Enterprise Linux OpenStack Platform Compute certification entry
for an existing Red Hat Enterprise Linux 6 certified server may do so in the Hardware Catalog by going to the Advanced section of the desired Red Hat Enterprise Linux 6 certification and then filling out the fields under the "Create New Layered Product Certification
- "Red Hat Enterprise Linux OpenStack Platform" heading.
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.
Important
Red Hat no longer certifies hardware for Red Hat Enterprise Linux Openstack Platform versions 3, or 4.
3.1.4. Red Hat Enterprise MRG for Realtime (RHEL6) and Red Hat Enterprise Linux for Real Time (RHEL7)
Red Hat Enterprise MRG for Realtime and Red Hat Enterprise Linux for Real Time provide predictability for consistent low-latency system response times. These Realtime 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 realtime test which may be performed to achieve Realtime
certification after completing the base Red Hat Enterprise Linux certification (see
Table 4.1, “Requirements by Class”). The additional Realtime packages will need to be installed and running to execute these tests.
Hardware Certification Partners may create new Realtime certifications requests in the Certification Workflow by selecting an existing Red Hat Enterprise Linux 6 or 7 certification entry, going to the
Advanced section, and then filling out the fields under the
Create New Layered Product Certification - MRG Realtime or RHEL Realtime heading. The base Red Hat Enterprise Linux certification is required to be completed and posted before the Realtime results will be reviewed.
Important
Red Hat no longer certifies hardware for any Red Hat Enterprise MRG Realtime 1.x versions.
3.1.5. Red Hat Gluster Storage for On-Premise
Red Hat Gluster Storage for On-Premise combines reliable Red Hat software with an Intel 64 and AMD 64 commodity hardware, eliminating the need for high-cost, proprietary storage systems. Red Hat Gluster Storage combines additional packageswith 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 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 server certification request. Partners who want to create an Red Hat Gluster Storage certification entry
for an existing Red Hat Enterprise Linux 6 certified server may do so in the Hardware Catalog by going to the Advanced section of the desired Red Hat Enterprise Linux 6 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 for Red Hat Gluster Storage should follow the
Red Hat Storage Architectural Review Process for further 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 the Knowledge Base article mentioned earlier 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.1.6. Certification Life-cycle
Hardware certification entries for all products will not be posted publicly until the General Availability 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 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 (a) re-certification is required, (b) Red Hat no longer supports that version of Red Hat Enterprise Linux, or (c) the vendor ceases participation in the Hardware Program. This life-cycle policy also applies to both Red Hat Enterprise MRG Realtime, Red
hat Enterprise for Real Time, and Red Hat OpenStack optional certifications.
3.1.7. Submission Window
New hardware certifications for a given major release of Red Hat Enterprise Linux may typically be submitted until the 2nd subsequent major version of Red Hat Enterprise Linux is released. New hardware certifications for a given major releaseof Red Hat Enterprise Linux OpenStack Platform may typically be submitted until the second subsequent major version of Red Hat Enterprise Linux OpenStack Platform is released. New hardware certifications for a given major release of Red Hat Enterprse MRG may
typically be submitted until the next subsequent major version of Red Hat Enterprise MRG 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 Hardware Partner
Manager or Partner TAM. Certification requests that fall outside of the normal windows must be raised to your Hardware Partner Manager or Partner TAM. 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.8. 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 is required be submitted by the original hardware manufacturer to Red Hat. Hardwarepartners may 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.9. Unpublished Certifications
All hardware certification requests submitted to Red Hat are presumed to be requests for published entries on the Hardware Catalog. Certifications may remain unpublished where the certification is not already published on the Hardware Catalogupon 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.10. Component Leveraging
In order to maximize the efficiency of the hardware certification testing process, Red Hat allows Hardware Certification Partners to reuse, orleverage, 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.13, “Component Pass-Through Certifications”. Additional requirements for leveraging are provided in
Table 4.1, “Requirements by Class”.
3.1.11. 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 as leveraging during later systemcertifications. 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 may 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.12. System Pass-Through Certifications
A Pass-Through Certification refers to the ability for a third party system or component to be granted the same certification as hardware previously certified by the original hardware manufacturer. System manufacturers may extend a certificationgranted to their systems to another vendor's system where the original vendor (a) has permission from the third party, (b) 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 (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). 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.13. 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 responsibilitiesof 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.11, “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.14. Re-Certification
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 suchas 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.15. 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.2. Software Policies
3.2.1. Test Suite Versions
It is recommended 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 periodof 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.2.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 customerbase. 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.2.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 and Red Hat Enterprise Linux 7 Server. 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.
3.2.3. Red Hat Enterprise MRG Realtime and Red Hat Enterprise Linux for Real Time Versions
Red Hat Enterprise MRG Realtime and 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 HatEnterprise Linux. When a new Red Hat Enterprise MRG Realtime or 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.2.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 allowedwhen 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.2.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 parameternoacpiis 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
noacpiis 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.2.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 (seeTechnology 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/lsmodcommand 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:
when the driver is included in an official Red Hat Errata and is not required for boot or installation testing (see
Table 4.1, “Requirements by Class”) 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
Chapter 3, Hardware 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
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.2.7. SELinux (Red Hat Enterprise Linux 6 and 7)
Certifications must be run with SELinux enabled using the Targeted Policy and with Enforcing on. The test suite will check for these conditions.3.2.8. Red Hat Enterprise Linux as a Host
Red Hat Enterprise Linux 6 and 7 require testing of KVM Virtualization during certification on 32-bit (RHEL6 only) and 64-bit architectures. SeeTable 4.1, “Requirements by Class” - System Virtualization for the specific list of required tests.
3.2.9. Red Hat Enterprise Linux as a Guest (Special Partnerships only)
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.3. BIOS/Firmware Policies
3.3.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 theSection 3.3.2, “Changes” criteria. The tested or subsequent revision is required to be available to customers by the posting date of the certification.
3.3.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 changesto 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.3.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 informationmay 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.3.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 documentedin a Red Hat Knowledge Base Solution associated to the certification listing.
3.4. Hardware Policies
3.4.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 certificationif the console was only accessible via Internet Explorer on another system.
3.4.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 componenthas 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.4.3. Production Level
The Red Hat Hardware Certification Program requires testing with production level hardware. Pre-production hardware which has been upgraded to production level equivalent is also acceptable.3.4.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 arenot 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.4.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 thekernel 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.4.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 resolutionis determined.
Chapter 4. Creating the Test Plan
4.1. Test PlanOverview4.2. Models4.3. Options4.4. Non-OS
Features and Unintentional Features4.5. Minimum
Test Set4.6.
Installation, Boot, and Kdump Requirements4.7.
Hardware Class Requirements4.8. Additional
Manual Testing
4.8.1.
External Storage and Multipath HBAs
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.Table 4.1, “Requirements by Class” is 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:
Define the model by its specification (Section 4.2,
“Models”)
Determine the options (Section 4.3,
“Options”)
Remove unsupported operating system features and unintentional hardware (Section 4.4,
“Non-OS Features and Unintentional Features”)
Apply the minimum test set criteria (Section 4.5,
“Minimum Test Set”)
Add the install, boot, and kdump requirements (Section 4.6,
“Installation, Boot, and Kdump Requirements”)
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 (see
Figure 2.7, “The Test Plan Section”). To post comments or questions about the test plan, refer to the procedure,
Procedure 2.5, “Adding a Comment to the Certification”.
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 hardwarespecification. 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.
Note
Optional Hardware was previously referred to as Config-To-Order (CTO). Additional Hardware was previously referred to as After-Market (AM).
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
All Integrated Hardware of a model must be tested. 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.
Important
Processor and memory are always considered integrated and unique.
Important
Integrated graphics controllers and displays are always considered integrated and unique.
As an example, if a system is available with and without a SCSI 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 includes
the SCSI controller and the two remaining optional network cards.
The Hardware Changes policy (see
Section 3.4.4, “Changes”) may be utilized when Optional Hardware (see
Section 4.2, “Models”) causes a newer than desired 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 release
required by the Optional Hardware.
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 Linux6, 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 the maximum supported configuration of your hardware. It is also recognized that resourcing the maximum supported configuration can be difficult due to availability, cost,and timing. For these reasons we have defined a minimum test set policy by hardware class in the
Table 4.1, “Requirements by Class” table. These requirements are not intended as product release criteria and it is expected that internal Red Hat Enterprise Linux qualification testing in addition to and prior to certification testing is conducted.
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.Table 4.1, “Requirements by Class” 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 and 7. 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 and 7 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
Table 4.1. Requirements by Class
| Device Class | Required Tests | Minimum Requirements | Install, Boot, Kdump [a] [b] | General Notes | Leverage Notes |
|---|---|---|---|---|---|
| All | INFO | Info is required for all test runs. | Test runs without INFO are invalid and will be automatically discarded by the Hardware Catalog. | N/A | |
| Battery | BATTERY and SUSPEND | Required for all models capable of running from battery power. | None | ||
| Bluetooth | BLUETOOTH | A minimum of two machines with Bluetooth capability in proximity to each other. | Identical integrated chipsets and removable adapters. | ||
| CD-ROM, DVD, Blu-ray | CDROM or DVD or BLURAY | The highest media type in order of BD-RW(highest), BD-R, DVD-RW [c], DVD-R[c], CD-RW, CD-R, BD, DVD, CD(lowest) on each storage controller based on the collective media support of all drives available on that storage controller. | I,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. Production cycle drive change test results are not required to be submitted to Red Hat. | Drives with identical or lesser media support on the storage controller following the storage controller leveraging policies. |
| Display Adapter | VIDEO | The lower of VRAM/VBIOS limits, panel capabilities, or 1024x768 at 24 or 32 BPP. | I,B | VIDEO test runs may utilize the vesa driver. 3D is not currently tested. GPGPUs are not currently tested. | Identical removable cards or integrated chips without shared memory. Decreases in video memory. |
| Ethernet Adapters | ETHERNET or the aligning test from one of the following: 1GigEthernet 10GigEthernet 20GigEthernet 25GigEthernet 40GigEthernet 50GigEthernet [d] 100GigEthernet [e] | Each interface @ maximum connection speed. | I,B,K[f] | Nominal network connection speed is considered a feature. | Identical integrated chipsets and removable adapters. |
| Express Card Sockets | EXPRESSCARD | All accessible sockets | Devices and inaccessible ports require additional class testing as applicable Both USB and PCI-E portions are required. | None | |
| Fibre Channel | NETWORK and/or STORAGE | Each interface @ maximum connection speed. | I,B,K[f] | Nominal connection speed is considered a feature. Remote attached storage devices may require additional testing. (see Section 4.8.1, “External Storage and Multipath HBAs”) | Identical integrated chipsets, removable adapters, drives and arrays. |
| Fiber Channel over Ethernet (FCoE) | STORAGE | I,B,K [f] | The default driver selected by the installer should be used during testing. [g] | Identical integrated chipsets and removable adapters. | |
| IDE/SCSI/SATA/SAS Drives, Arrays, and HBAs | STORAGE | Maximum storage capacity of local attach arrays if greater than OS limit. | I,B,K[f] | Drive capacity are not tracked in context of a system. SATA Controllers require testing in a SATA mode. SAS Controllers require testing with SAS drives. | Identical integrated chipsets, removable adapters, drives and arrays. |
| Infiniband | INFINIBAND and NETWORK and/or STORAGE | Each interface @ maximum connection in FDR(highest), QDR, DDR, SDR(lowest) order. | I,B,K[f] | Nominal connection speed is considered a feature. Remote attached storage devices may require additional testing. (see Section 4.8.1, “External Storage and Multipath HBAs”) | Identical integrated chipsets, removable adapters, drives and arrays. |
| I/O Chassis, Port Expanders | Applicable testing for integrated additional CTO hardware. | I,B | Identical integrated chipsets, removable adapters, drives and arrays. | ||
| Integrated Graphics Display | VIDEO [LID] | Native resolution [h] [i]at adaptive or native color depths with available display + graphics controller combinations [j] [k] | I [l] | Backlight must respond to lid switch if present | Identical display + graphics controller + BIOS' |
| iSCSI Adapters | NETWORK and STORAGE | Each interface @ maximum connection speed. | I,B,K[f] | Nominal network connection speed is considered a feature. [g] | Identical integrated chipsets and removable adapters. |
| (e)MMC, SD, CompactFlash Memory Cards/Chips/Readers [m], USB Keys/Thumb drives | STORAGE | Each interface. Maximum storage capacity and format feature set. | I,B | Multi-Readers follow the Multi-Port Adapter criteria. | Identical integrated chipsets, removable adapters. Identical, smaller capacity or feature cards and sticks. |
| Motherboard / Mainboard | System Processor + Memory requirements + all integrated feature classes. | Follows the combined class leverage requirements. | |||
| Multi-Function Adapters | Applicable test for each function. | Follows the combined functional leverage requirements. | |||
| Multi-Port Adapters | Functional test(s) on all ports -or- single port where identical chips are replicated for each port -or- maximum number of ports per controller where heads are capped to create a port reduced variation. | Follows functional leverage requirements. | |||
| Network Interface Adapters | NETWORK | Each interface @ maximum connection speed. | I,B,K[f] | Nominal network connection speed is considered a feature. | Identical integrated chipsets and removable adapters. |
| PC Card Sockets | PCCARD | All accessible sockets | Devices and inaccessible ports require additional class testing as applicable | None | |
| PCIE, SAS, and SATA SSD Storage Cards and Drives | STORAGE | Maximum storage capacity and feature set. Capacity is not tracked for SATA and SAS attached SSDs in context of a system certification and should follow the standard SAS and SATA policies instead. | I,B,K[f] | PCIE SSD Storage testing will be required on option cards starting May 1st 2015. [o] | Identical integrated chipsets, removable adapters and drives. Models with the same host interface, hardware and firmware designs including reduced features and capacity. |
| RAID Controllers | 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. | I,B,K[f] | Host RAID/Driver RAID/Fake RAID/etc. use the applicable regular controller policy. Remote attached storage devices may require additional testing. (see Section 4.8.1, “External Storage and Multipath HBAs”) | Identical integrated chipsets, removable adapters, drives and arrays following type criteria. Reduced RAID levels, changes in memory amounts or battery presence. |
| Sound Cards | AUDIO | Stereo record and playback as applicable. | Identical integrated chipsets + codec and removable adapters. | ||
| System Buses | Each bus by proxy testing [p]. | I,B | Buses without possible active devices do not require testing. | Identical integrated chipsets, removable adapters | |
| System Virtualization | CORE [q] and CPUSCALING and PROFILER [FV_CORE and FV_MEMORY] [REALTIME[q] OR RTEVAL[q] and HWLATDETECT[q]] | Maximum number of processors, cores [r], and feature set [s]; this may require multiple runs with different processors. | Core clock speed, FSB speed, cache size, cache depth and manufacturing size are not considered for feature set review. [t] A fully virtualized guest environment using KVM. PROFILER test runs may utilize timer mode. [u] REALTIME, RTEVAL and HWLATDETECT require the realtime kernel. | Equal or lesser feature set within a model. Processor/core count downward on scaling designs. Feature set and core count upgrades [v] to existing certifications. | |
| System Memory | MEMORY | Lower of 1GB Per Logical CPU, system limit, or OS limit. [w] | The vendor must support the maximum amount of RAM listed in the specification irrespective of the test results submitted. Memory clock speed is not considered for feature review. | Equal or lesser quantities where RAM type and memory controller match. | |
| System Virtualization | INFO and CORE and MEMORY in the guest | A fully virtualized guest environment (Xen on Red Hat Enterprise Linux 5, KVM on Red Hat Enterprise Linux 6) | 32-bit and 64-bit Intel and AMD systems with pae and vmx on Red Hat Enterprise Linux 5; 64-bit Intel and AMD systems only on Red Hat Enterprise Linux 6. | None [x] | |
| Tape Drives and Changers | TAPE | Each drive | Changers require manual testing with test description and results report. | 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. | |
| USB ports | USB, USB2 or USB3, USB 3.1 | All pluggable ports at the stated connection version. [y] | inaccessible ports may substitute attached device class testing. | None | |
| USB devices | Each function class at the stated connection version. | Class testing as applicable | Identical devices. | ||
| Virtual Hardware | Each virtualized hardware class. | class testing as applicable | None | ||
| Wireless Network Interface Adapters | WirelessG WirelessN WirelessAC [z] | Each interface @ maximum connection in N(highest), G, B, A(lowest) order. | I,B | Nominal network connection speed is considered a feature. | Identical integrated chipsets and removable adapters. |
| [a] Red Hat Enterprise Linux 6 only. [b] Not required on s390x. [c] "+" and "-" are considered equal for feature review. [d] For systems with 50 and 100Gb/s Ethernet options, testing is not required until September 9th 2016. A knowledgebase entry will be added to certifications without passing test results. [e] For systems with 50 and 100Gb/s Ethernet options, testing is not required until September 9th 2016. A knowledgebase entry will be added to certifications without passing test results. [f] Required only for integrated hardware. [g] An alternate valid driver (see Section 3.2.6, “Drivers”) may be utilized during testing when required; for example use of the software initatior or target instead of the hardware offload engine. A knowledge base entry may be added to the certification to clarify which drivers should be used to end users. [h] Compensation/Stretching does not qualify as native testing. [i] A horizontal resolution of 1360 may be used on 1366 native panels. [j] Optional graphics controllers excluded by other policies are not required to be tested. At least one display + controller combination is required for each display. [k] Display and graphics controller combinations may be clarified in a Red Hat Knowledge Base Article entry to avoid confusion. [l] Native resolutions not required during install [m] Including variants for each (eg. mini, micro, etc.). Network devices that support NIC partitioning are required to demonstrate both the complete bandwidth and a single partition in one or more test runs. [o] A knowledge base entry may be added to the certification to clarify when passing results are not provided before the requirement date. [p] For example, testing a PCI NIC with the NETWORK test tests the PCI bus. [q] The minimum installed memory is required to match the System Memory testing requirement. [r] System or OS maximum, whichever is lower. [s] Integrated non-usable GPUs are ignored during feature set comparison. [t] Additional testing may be required where maximum system core count is greater than the currently listed OS Certified maximum. [u] To force timer mode operation, include options oprofile timer=1to /etc/modprobe.conf [v] Processor upgrades are defined as field installable physical packages and may require field installable BIOS/firmware upgrades (Section 3.3, “BIOS/Firmware Policies” apply). [w] Additional testing may be required where maximum system memory is greater than the currently listed OS Certified maximum. [x] System Virtualization is leverageable in CPU upgrade leveraging where the existing certification already includes System Virtualization testing. [y] RHEL 7.3 supports testing of USB 3.1 ports. These ports may be tested using a USB 3.1 device. RHEL 7.3 is required in all RHEL 7.x certifications. In RHEL 6.8, all ports will be tested as USB 3.0 ports. [z] Red Hat Enterprise Linux 7 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 is available. |
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 attests 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.
[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...").
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- A Practical Guide to Red Hat(R) Linux(R): Fedora(TM) Core and Red Hat Enterprise Linux (3rd Edition)
- 官网Red Hat Enterprise Linux 6 Power Management Guide
- OpenStack Installation Guide for Red Hat Enterprise Linux 7, CentOS 7, and Fedora 20
- Red Hat Enterprise Linux 4 System Administration Guide
- Oracle 9i 在 Red Hat Enterprise Linux 3 AS U2 上的安装
- 如何用APT维护Red Hat Enterprise Linux (RHEL)
- vsftpd dead , but subsys locked --解除方法汇总(Red Hat Enterprise Linux 4)
- Build Resin on "Red Hat Enterprise Linux AS release 3 (Taroon)"
- Red Hat Enterprise Linux 4 与 WLS8.1sp5的安装
- red hat Enterprise linux4下DNS的构建
- 在Red Hat Enterprise Linux AS release 3 (Taroon) 配置TOMCAT
- Red Hat Enterprise Linux 4 Beta 1发布
- Red Hat Enterprise Linux 4.1下配置jdk-1.5.0.04安装笔记
- Red Hat Enterprise Linux AS 3 标准版
- 如何用APT维护Red Hat Enterprise Linux (RHEL)
- Red Hat Enterprise Linux 4 Beta 1发布
- Red Hat Linux Reference Guide & OpenSolaris/Solaris
- Red Hat Enterprise Linux 5 正式发布
- Red Hat Enterprise Linux AS 安装 Oracle 9i过程整理