Red Hat Enterprise Linux Hardware Certification

Program Policy Guide

The Policies and Procedures of Hardware Certification

Edition 6.0-2.0-5

Legal Notice

Copyright © 2013 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, MetaMatrix, 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 Enterprise Linux Hardware Certification Program Policy Guide covers the procedural, technical and policy requirements for achieving Red Hat Enterprise Linux Hardware Certification.

Preface

1. Document Conventions

This manual uses several conventions to highlight certain words and phrases and draw attention to specific pieces of information.
In PDF and paper editions, this manual uses typefaces drawn from the Liberation Fonts set. The Liberation Fonts set is also used in HTML editions if the set is installed on your system. If not, alternative but equivalent typefaces are displayed. Note: Red Hat Enterprise Linux 5 and later include the Liberation Fonts set by default.

1.1. Typographic Conventions

Four typographic conventions are used to call attention to specific words and phrases. These conventions, and the circumstances they apply to, are as follows.
Mono-spaced Bold
Used to highlight system input, including shell commands, file names and paths. Also used to highlight keys and key combinations. For example:
To see the contents of the file my_next_bestselling_novel in your current working directory, enter the cat my_next_bestselling_novel command at the shell prompt and press Enter to execute the command.
The above includes a file name, a shell command and a key, all presented in mono-spaced bold and all distinguishable thanks to context.
Key combinations can be distinguished from an individual key by the plus sign that connects each part of a key combination. For example:
Press Enter to execute the command.
Press Ctrl+Alt+F2 to switch to a virtual terminal.
The first example highlights a particular key to press. The second example highlights a key combination: a set of three keys pressed simultaneously.
If source code is discussed, class names, methods, functions, variable names and returned values mentioned within a paragraph will be presented as above, in mono-spaced bold. For example:
File-related classes include filesystem for file systems, file for files, and dir for directories. Each class has its own associated set of permissions.
Proportional Bold
This denotes words or phrases encountered on a system, including application names; dialog-box text; labeled buttons; check-box and radio-button labels; menu titles and submenu titles. For example:
Choose SystemPreferencesMouse from the main menu bar to launch Mouse Preferences. In the Buttons tab, select the Left-handed mouse check box and click Close to switch the primary mouse button from the left to the right (making the mouse suitable for use in the left hand).
To insert a special character into a gedit file, choose ApplicationsAccessoriesCharacter Map from the main menu bar. Next, choose SearchFind… from the Character Map menu bar, type the name of the character in the Search field and click Next. The character you sought will be highlighted in the Character Table. Double-click this highlighted character to place it in the Text to copy field and then click the Copy button. Now switch back to your document and choose EditPaste from the gedit menu bar.
The above text includes application names; system-wide menu names and items; application-specific menu names; and buttons and text found within a GUI interface, all presented in proportional bold and all distinguishable by context.
Mono-spaced Bold Italic or Proportional Bold Italic
Whether mono-spaced bold or proportional bold, the addition of italics indicates replaceable or variable text. Italics denotes text you do not input literally or displayed text that changes depending on circumstance. For example:
To connect to a remote machine using ssh, type ssh username@domain.name at a shell prompt. If the remote machine is example.com and your username on that machine is john, type ssh john@example.com.
The mount -o remount file-system command remounts the named file system. For example, to remount the /home file system, the command is mount -o remount /home.
To see the version of a currently installed package, use the rpm -q package command. It will return a result as follows: package-version-release.
Note the words in bold italics above: username, domain.name, file-system, package, version and release. Each word is a placeholder, either for text you enter when issuing a command or for text displayed by the system.
Aside from standard usage for presenting the title of a work, italics denotes the first use of a new and important term. For example:
Publican is a DocBook publishing system.

1.2. Pull-quote Conventions

Terminal output and source code listings are set off visually from the surrounding text.
Output sent to a terminal is set in mono-spaced roman and presented thus:
books        Desktop   documentation  drafts  mss    photos   stuff  svn
books_tests  Desktop1  downloads      images  notes  scripts  svgs
Source-code listings are also set in mono-spaced roman but add syntax highlighting as follows:
static int kvm_vm_ioctl_deassign_device(struct kvm *kvm,
                 struct kvm_assigned_pci_dev *assigned_dev)
{
         int r = 0;
         struct kvm_assigned_dev_kernel *match;

         mutex_lock(&kvm->lock);

         match = kvm_find_assigned_dev(&kvm->arch.assigned_dev_head,
                                       assigned_dev->assigned_dev_id);
         if (!match) {
                 printk(KERN_INFO "%s: device hasn't been assigned before, "
                   "so cannot be deassigned\n", __func__);
                 r = -EINVAL;
                 goto out;
         }

         kvm_deassign_device(kvm, match);

         kvm_free_assigned_device(kvm, match);

out:
         mutex_unlock(&kvm->lock);
         return r;
}

1.3. Notes and Warnings

Finally, we use three visual styles to draw attention to information that might otherwise be overlooked.

Note

Notes are tips, shortcuts or alternative approaches to the task at hand. Ignoring a note should have no negative consequences, but you might miss out on a trick that makes your life easier.

Important

Important boxes detail things that are easily missed: configuration changes that only apply to the current session, or services that need restarting before an update will apply. Ignoring a box labeled “Important” will not cause data loss but may cause irritation and frustration.

Warning

Warnings should not be ignored. Ignoring warnings will most likely cause data loss.

2. Getting Help and Giving Feedback

2.1. 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 a knowledgebase of technical support articles about Red Hat products.
  • submit a support case to Red Hat Global Support Services (GSS).
  • access other product documentation.
Red Hat also hosts a large number of electronic mailing lists for discussion of Red Hat software and technology. You can find a list of publicly available mailing lists at https://www.redhat.com/mailman/listinfo. Click on the name of any mailing list to subscribe to that list or to access the list archives.

2.2. We Need Feedback!

If you find a typographical error in this manual, or if you have thought of a way to make this manual better, we would love to hear from you! Please submit a report in Bugzilla: http://bugzilla.redhat.com/ against the product Red_Hat_Enterprise_Linux_Hardware_Certification.
When submitting a bug report, be sure to mention the manual's identifier: Policy_Guide
If you have a suggestion for improving the documentation, 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.

Chapter 1. Introduction

Welcome to the Red Hat Enterprise Linux Hardware Certification Policy Guide. 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 Enterprise Linux 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. An Red Hat Certified Engineer accreditation is preferred and suggested before participating.

1.2. Program Overview

The Red Hat Enterprise Linux Hardware Certification Program provides a formal means for you to work with Red Hat to establish official support for your hardware. Certified hardware is supported by Red Hat's Global Support Services (GSS) and is published in the Red Hat Hardware 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. Our 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.
  • We certify 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 not provided by Red Hat.
  • Certifications are currently available for Red Hat Enterprise Linux 5, Red Hat Enterprise Linux 6, and optionally Red Hat Enterprise MRG Realtime 2, and Red Hat OpenStack Compute 3.
  • Certifications are awarded against a specific major.minor release and architecture (e.g. Red Hat Enterprise Linux 5.4 for x86_64) and are not specific to variants (i.e. Red Hat Enterprise Linux Advanced Platform, Desktop or Server).

Chapter 2. The Certification Process

2.1. Process Overview

The following steps outline the certification process.
  1. Create an account with the Red Hat Customer Portal, Red Hat Bugzilla, and the Red Hat Hardware Program.
  2. Create a new certification in the Hardware Catalog.
  3. Review the test plan created for your hardware.
  4. Test your hardware until all criteria in the test plan are complete.
  5. Ship representative hardware to a Red Hat office.
  6. Attain support approval from Red Hat Global Support Services (GSS).
The certification is then published to the Red Hat Hardware Catalog located at https://hardware.redhat.com.

2.2. The Certification Process

2.2.1. Creating Accounts

Complete the procedure below to create an account with the 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.

Procedure 2.1. Creating Accounts

  1. Create an account with the Red Hat Hardware Program.
    1. Click the Enroll link and follow the steps.
      The account created during this step is also used on the Red Hat Customer Portal.
  2. Create a Red Hat Bugzilla account
    1. Select New Account in the menu and follow the instructions.
      The Red Hat Bugzilla account is also used on the Hardware Catalog.
  3. Obtain Red Hat Hardware Catalog permissions.
    1. File a support request (see Section 2.3, “Giving Feedback and Getting Help”) for create permissions; include your Red Hat Hardware Program and Bugzilla login names.
      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 create a test plan for your hardware.

Procedure 2.2. Create a Certification using the Hardware Catalog.

  1. Navigate to https://hardware.redhat.com/ click on the "Vendor Login" link, then log on to your Hardware Catalog account using your Red Hat Bugzilla login credentials.
  2. Click the Create create link from the Hardware Catalog menu.
    The Hardware Catalog Menu

    Figure 2.1. The Hardware Catalog Menu


  3. 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”. Where this is not possible official specification documents may be attached to the certification after the certification is created.

    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.
    The Certification Form - Certification Information

    Figure 2.2. The Certification Form - Certification Information


  4. Depending on the radio button selected, complete either the Hardware Product Data or Upload Certification Package section.
    The Certification Form - Hardware Product Data

    Figure 2.3. The Certification Form - Hardware Product Data


    Upload and provide a brief description of the test result package.
    The Certification Form - Upload Certification Package

    Figure 2.4. The Certification Form - Upload Certification Package


  5. Click Continue to submit the request.
  6. Record the Hardware Certification number displayed on the following screen.

2.2.3. Reviewing the Test Plan

An engineer from the Red Hat Enterprise Linux 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 defined 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

  1. Navigate to https://hardware.redhat.com/ and log on to your Hardware Catalog account.
  2. 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.
    The Hardware Catalog Search Bar

    Figure 2.5. The Hardware Catalog Search Bar


  3. Click on the Review link in the Sections list at the top of the page and scroll down to the Test Plan Progress subsection.
    Sections in the Hardware Catalog

    Figure 2.6. Sections in the Hardware Catalog


  4. 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.
The Test Plan Section

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

  1. Log on to your Hardware Catalog account and navigate to your certification.
  2. In the Test Plan State section, select the Change Test Plan to radio button and select Melted in the drop down box.
    The Test Plan State

    Figure 2.8. The Test Plan State


  3. Click the Save Changes button to submit.
  4. 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

  1. Log on to your account in the Hardware Catalog and navigate to the Dialog tab.
  2. In the Add Additional Comment section, enter the message in the text box.
    The Add Additional Comment Section

    Figure 2.9. The Add Additional Comment Section


  3. Select either the No response requested or the Request Information From radio button. The latter allows you to choose the intended message recipient.
  4. 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 Enterprise Linux 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

  1. Execute the hwcert utility on the hardware described in the test plan.
  2. Upload test result packages via your certification request.
    1. Navigate to your certification request and click on the Review section as is described in the procedure, Procedure 2.3, “Review the Test Plan”.
    2. Scroll down to the section, Upload Results Package or Specification 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.
      Uploading Test Result Packages

      Figure 2.10. Uploading Test Result Packages


    3. 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”.
  3. 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 Enterprise Linux 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 Component Leveraging section for more information.

      Important

      Comments and attachments identifying leveraged data are not reviewed. The procedure described above must be used.
  4. 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 product 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.

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

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 Enterprise Linux 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 Enterprise Linux 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 Enterprise Linux Hardware Certification Program, but is available for purchase separately.

Warning

The Red Hat Enterprise Linux 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

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.
Red Hat Enterprise Linux
Red Hat Enterprise Linux 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 5 for x86_64 for example) and not by variant (Red Hat Enterprise Linux for Desktop or Advanced Server). 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 5 or 6.

Important

Red Hat no longer certifies hardware for Red Hat Enterprise Linux versions 2.1, 3, or 4, on any architecture; nor Red Hat Enterprise Linux 5 for IA-64.
Red Hat OpenStack Compute (optional)
Red Hat Enterprise Linux OpenStack Platform delivers Red Hat OpenStack technology optimized for and integrated with Red Hat Enterprise Linux. Red Hat OpenStack consists of additional packages that expand Red Hat Enterprise Linux capabilities to quickly scale to tens of thousands of virtual machines without requiring a unique kernel or specialized hardware support. Because of this inheritance, additional testing beyond Red Hat Enterprise Linux certification is not required for Red Hat OpenStack Compute certification.
Partners have the option to automatically create a corresponding Red Hat OpenStack Compute certification when creating a new system certification request for Red Hat Enterprise Linux 6.x on the x86_64 platform. Partners may also create new Red Hat OpenStack Compute certification requests on existing Red Hat Enterprise Linux 6.x for x86_64 certification entires in the Hardware Catalog by going to the Advanced section of the Red Hat Enterprise Linux 6 certification and then filling out the fields under the Create New Layered Product Certification - RHOS heading. The base Red Hat Enterprise Linux 6 certification is required to be completed, include passing virtualization testing, and posted before the Red Hat Openstack certification will be processed. Red Hat OpenStack certifications are opt-out for individual systems by setting the Create Red Hat OpenStack Certification option to no during the Red Hat Enterprise Linux certification creation or by providing a comment in the OpenStack certification indicating that an Red Hat OpenStack certification is no longer desired.
Red Hat Enterprise MRG Realtime (optional)
Red Hat Enterprise MRG Realtime provides predictability for consistent low-latency system response times. MRG Realtime consists of additional packages that expand Red Hat Enterprise Linux, including a uniquely tuned kernel. These packages do not modify the user space portion of Red Hat Enterprise Linux. The hardware certification test suite contains additional MRG Realtime tests which may optionally be performed to achieve Red Hat Enterprise MRG Realtime certification after completing the Red Hat Enterprise Linux certification (see Table 4.1, “Requirements by Class”). The additional MRG Realtime packages will need to be installed and running to execute these tests.
Hardware Certification Partners may create new Red Hat Enterprise MRG Realtime certification requests on the Hardware Catalog by selecting an existing Red Hat Enterprise Linux 6.x i386 or x86_64 certification entry, going to the Advanced section, and then filling out the fields under the Create New Layered Product Certification - MRG heading. The base Red Hat Enterprise Linux certification is required to be completed and posted before the Red Hat Enterprise MRG Realtime results will be reviewed.

Important

Red Hat no longer certifies hardware for any Red Hat Enterprise MRG Realtime 1(.x) versions.
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, an i386 certification granted on Red Hat Enterprise Linux 5.1 is also valid for 5.2, 5.3 and so on. (typically without additional testing). 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 4 or Red Hat Enterprise Linux 5 for x86_64 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 and Red Hat OpenStack optional certifications.
Submission Window
New hardware certifications for a given major release of Red Hat Enterprse 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 release of Red Hat Enterprse Linux OpenStack Platform may typically be submitted until the 2nd 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, 5.10, etc.).
Original Certifications
Partner support of certified hardware is a fundamental part of Red Hat Enterprise Linux Hardware Certification. All requests and information about the hardware to be certified is required be submitted by the original hardware manufacturer to Red Hat. Hardware 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.
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 Catalog upon request by the partner. Unpublished certifications follow the same policies as published certifications but are not made available to the public 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 Knowledgebase Article or Solution.
Component Leveraging
In order to maximize the efficiency of the hardware certification testing process, Red Hat allows Hardware Certification Partners to reuse, or leverage, specific test cases for the same (or later minor) release and architecture of Red Hat Enterprise Linux to satisfy test plan requirements where components are reused between similar models. The partner is required to have a Red Hat Enterprise Linux quality assurance (QA) process that encompasses all hardware to be certified with leveraging. This QA process is in turn leveraged by Red Hat to offer this feature, as such partners cannot leverage testing of other partners except as described in Component Pass-Through Certifications. Additional requirements for leveraging are provided in Table 4.1, “Requirements by Class”.
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 system 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.
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 certification 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.
Component Pass-Through Certifications
Component vendors may utilize the pass-through process where the component vendor (a) has permission from the third party, (b) has the mechanics to ensure the third party does not alter the hardware, and (c) extends their responsibilities of support and representative hardware to include situations involving the third party hardware (refer to sections 1.2 and 1.3 of the Hardware Certification Agreement). Third party vendors may not extend their pass-through certification to another vendor. While both vendors are required to be members of the Hardware Certification program, only the original component vendor may request pass-through certifications. The original and pass-through certifications may be published or unpublished.
Third party system vendors may choose to leverage these component certifications in their system certifications for standard PCIe form factor Ethernet, Fibre Channel, Infiniband, iSCSI, SATA, SAS, RAID, CNA, and WLAN option cards. The regular leverage policies apply to the system certification leveraging the component pass-through certification, including the internal QE process encompasses all hardware to be certified with leveraging. Component pass-through certifications may also follow the leverage pool policies (see 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.
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 such as network or storage controllers requires re-certification. Refer to Section 4.1, “Test Plan Overview” for further information on test plan criteria. A new supplemental certification should be opened to process the hardware changes.
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

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 period of three months. At the end of this period the Hardware Catalog will automatically reject result packages created with the older versions and testing will need to be repeated with valid packages. The current valid package versions are displayed on the results package submission form.

Important

The test suite should not be modified for certification test runs. The test suite will perform a self check and and will fail the info test if modified.
Red Hat Enterprise Linux Versions
The latest minor release of Red Hat Enterprise Linux version is always recommended; however, any release that satisfies the full testing criteria may be used. Testing on the earliest fully-supported release will maximize the potential customer base. If multiple minor releases are used during testing, the newest minor release will be used as the posted release for the model. Depending on the features of a given model a minimum release may be required other than what is desired.
Red Hat Enterprise Linux should not be updated with errata packages except when recommended by the Red Hat Hardware Certification Review team or in accordance with the Drivers policies. Any testing performed with unnecessary errata installed may require retesting.

Note

Only Red Hat Enterprise Linux 5 Advanced Platform and Red Hat Enterprise Linux 6 for Servers are tested against the test suite. 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 and features. Technical assistance is not offered in the certification program when using these variants.
Red Hat Enterprise MRG Realtime Versions
The optional Red Hat Enterprise MRG Realtime test results are only accepted on the current minor release of MRG Realtime. Use of the latest MRG Realtime errata packages is encouraged. When a new MRG Realtime minor release is made available results on the previous minor will be accepted for a period of 30 days.
Unmodified Red Hat Enterprise Linux
The Red Hat Enterprise Linux Hardware Certification Program requires testing on a standard installation of Red Hat Enterprise Linux with-out any modifications. Changes to the default configuration presented by the installer and first boot utilities are allowed when the configuration change can be made using one of the standard system tools and when the default configuration does not create the potential for data loss. Required changes to the default configuration must be documented in a Red Hat Knowledgebase 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.
Kernel Variants
Red Hat Enterprise Linux 5 includes multiple kernel variations. Testing with each of the variants is typically not required. Refer to the following tables to determine which of the possible kernels require testing.

Table 3.1. Red Hat Enterprise Linux 5 Kernels

Architecture Features (flags) Kernel Package
i686
without PAE (pae)
kernel
with PAE (pae) without VT (vmx or svm)
kernel-xen [a]
with VT (vmx or svm)
kernel-xen & fully virtualized domU results [b]
x86_64
without VT (vmx or svm)
kernel-xen
with VT (vmx or svm)
kernel-xen & fully virtualized domU results [b]
with VT (vmx or svm) and > 32 Cores or 32GB of required memory testing.
kernel[c] & kernel-xen & fully virtualized domU results[b]
ppc64/s390
N/A
kernel
[a] CPU scaling in the virtualization kernel (-xen) requires Update 2 of Red Hat Enterprise Linux 5 starting with the 2.6.18-92 kernel.
[b] Fully virtualized guests should use the corresponding bare metal kernel.
[c] The regular kernel should be used in addition to kernel-xen to augment the CORE and/or MEMORY results as applicable.

Important

Limitations present in the virtualization-enabled kernel or hypervisor are addressed by testing the virtualization kernel/hypervisor to its limit followed by testing with a non-virtualized kernel at the higher limit.

Table 3.2. Red Hat Enterprise Linux 6 Kernels

Architecture Features Kernel Package
i686, x86_64, ppc64, s390x
All
kernel
x86_64
Realtime (optional)
kernel-rt

Kernel Boot Parameters
Additional kernel parameters may be utilized if they (a) are used to correct hardware configuration, (b) do not disable functionality, and (c) do not expose a potential for data loss when not in use. For example, if the kernel parameter noacpi is required to boot a system which does not install without that parameter, this would likely be acceptable. If, however, the system would install but corrupts data over time when noacpi is not specified, the certification would be suspended until the the situation is resolved.i Additional kernel parameters utilized during certification are documented in Red Hat Knowledgebase Solution associated with the certification listing.
Drivers
Red Hat may provide drivers as a Technology Preview, granting early access to upcoming product innovations. These drivers are not fully supported and cannot be used to achieve certification (see Technology Preview features support scope). Drivers are designated as technology preview in the release notes of the Red Hat Enterprise Linux product documentation (link). Starting with Red Hat Enterprise Linux 6.1, the /sbin/lsmod command will also mark technology preview modules with the letter "T" similar to the "U" for unsigned modules.
Red Hat recognizes that it is not possible for some drivers to be included within Red Hat Enterprise Linux. While use of additional drivers is discouraged, in certain cases such drivers may be used during the certification process. These cases include 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”), when the driver is included in an official Red Hat Enterprise Linux Driver Update Disk, and 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 .
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 [1] with any Red Hat provided driver. 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 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 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 Enterprise Linux Hardware Certification testing and listings.
SE Linux (Red Hat Enterprise Linux 5 and 6)
Certifications must be run with SE Linux enabled using the Targeted Policy and with Enforcing on. The test suite will check for these conditions.
Red Hat Enterprise Linux as a Host
Virtualization is a feature of Red Hat Enterprise Linux 5 and 6 and is required to be tested during certification. Xen is required to be tested on Red Hat Enterprise Linux 5 on PAE enabled i386 and x86_64 architecture certifications. KVM is required to be tested on Red Hat Enterprise Linux 6 for x86_64 architecture certifications but not required to be tested on Red Hat Enterprise Linux 5 certifications. See Table 4.1, “Requirements by Class” - System Virtualization for the specific list of required tests.
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

Production Level
BIOS/Firmware versions are required to be production-level (e.g. feature complete without major changes pending) during testing. BIOS/Firmware changes subsequent to testing are required to meet the Changes criteria. The tested or subsequent revision is required to be available to customers by the posting date of the certification.
Changes
BIOS/Firmware changes that enable or disable features necessitate re-certification. Re-certification is not required for BIOS changes to correct bugs and/or alter superficial items like splash screens. Vendor internal testing of these changes to verify they do not adversely affect the hardware, Red Hat Enterprise Linux, or the certification status is required, but the results of this testing is not required to be submitted to Red Hat.
Settings
Any required BIOS/Firmware configuration information must be provided in a comment in the certification request. Providing suggested and/or default configuration data is encouraged but not required. Vendor provided configuration information may be provided in the certification listing using an associated Red Hat Knowledgebase 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.
OS Loaded
Firmware that is loaded via supported mechanisms of the OS may be used where they follow the guidelines above and have a perma-link to the supported binary RPM package(s). OS Loaded firmware not included with the Red Hat product will be documented in a Red Hat Knowledgebase Solution associated to the certification listing.

3.4. Hardware Policies

Stand-Alone
A model must include all hardware and software to enable full functionality in a Red Hat Enterprise Linux only environment. For example, a system that requires a management console to boot and/or be configured, would not qualify for certification if the console was only accessible via Internet Explorer on another system.
Components and Peripherals
Components and peripherals to be listed independently are required be tested with Virtualization (XEN and/or KVM) as applicable to the class and architectures. Components listed in the hardware catalog carry a generic disclaimer informing customers that while the component has demonstrated compatibility with Red Hat Enterprise Linux, we cannot guarantee that it will work in their system and their system vendor should be consulted to ensure full compatibility.
Production Level
The Red Hat Enterprise Linux Hardware Certification Program requires testing with production level hardware. Pre-production hardware which has been upgraded to production level equivalent is also acceptable.
Changes
Certified models may not be altered such that a regression in the certification testing results or change in criteria occurs. Minor changes that do not add or alter features or functionality are expected to be tested by the vendor but are not required to be resubmitted. For example cable length or passive backplane port count changes. Vendors are expected to notify Red Hat of any significant changes including those which add features or functions. If re-certification is required, a new supplemental certification entry should be opened from the original certification. Any additional testing required should be performed using the same Red Hat Enterprise Linux version as the original submissions. Where a version mismatch occurs between the updated testing and the original submission, a Red Hat Knowledgebase article may be associated with the original certification for clarity. Supplemental certifications are processed in queue with other certifications, but are not published.
Configuration Limits
Models available in configurations beyond the Red Hat product limits may still be eligible for certification. Testing will need to be performed demonstrating the model within the limits by manual or automatic configuration, for example the kernel automatically ignores memory beyond the limit, or CPU's above the limit, etc. Manual configuration follow the standard configuration and kernel parameters policies. A Red Hat Knowledgebase 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: http://www.redhat.com/resourcelibrary/articles/articles-red-hat-enterprise-linux-6-technology-capabilities-and-limits.
Performance Minimums
In general, Red Hat Enterprise Linux Hardware Certification places the responsibility of performance testing on the hardware vendor; however, major performance issues that are deemed to have significant customer impact may delay certification until a resolution is determined.


[1] Providing hardware support already present in a Red Hat provided driver is considered a conflict.

Chapter 4. Creating the Test Plan

4.1. Test Plan Overview

This chapter describes the process followed by the Red Hat Enterprise Linux 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:
  1. Define the model by its specification (Section 4.2, “Models”)
  2. Determine the options (Section 4.3, “Options”)
  3. Remove unsupported operating system features and unintentional hardware (Section 4.4, “Non-OS Features and Unintentional Hardware”)
  4. Apply the minimum test set criteria (Section 4.5, “Minimum Test Set”)
  5. Add the install, boot, and kdump requirements (Section 4.6, “Installation, Boot, and Kdump Requirements”)
  6. Add additional policy requirements (Chapter 3, Hardware Certification Policies)
After performing the steps above, the items remaining determine the test plan for your hardware. The Hardware Catalog records the test plan under the Test Plan Progress (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 Enterprise Linux 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 Enterprise Linux Hardware Certification program certifies models, not specific configurations of models. Red Hat defines a model as inclusive of all Integrated Hardware and all Optional Hardware described by the Hardware Partner on the hardware specification. Integrated Hardware is hardware required to be present in all configurations of a model. Optional Hardware is hardware which is present in some configurations of a model. Additional Hardware may also appear on the model specification. Additional Hardware is hardware that can be purchased in addition to but is not included as part of any configuration of the model. Additional Hardware is not required to be tested but must be clearly identifiable as Additional Hardware and not confused with Integrated Hardware or Optional Hardware. A Red Hat Knowledgebase 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 Enterprise Linux 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 3000smodels. 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 Knowledgebase 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 [2] , and is clearly noted for use with another operating system [3] 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 Enterprise Linux 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 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 Knowledgebase Article to reflect the release required by the Optional Hardware.

4.4. Non-OS Features and Unintentional Hardware

Hardware features not supported by the OS are not required to be tested if the remaining hardware continues to be fully functional. For example, a type of storage not currently supported in Red Hat Enterprise Linux 5 would not require testing in a Red Hat Enterprise Linux 5 certification. If, however, the system only had that type of storage, it would not qualify for a Red Hat Enterprise Linux 5 certification. Continuing the example; if the storage could instead also present itself as SATA (a Red Hat Enterprise Linux 5 supported feature), the system could qualify for certification with passing SATA testing. A Red Hat Knowledgebase Article may be added to the certification listing for clarity.
Unintentional Hardware is defined as hardware features not intentionally present in the hardware, not present or otherwise discounted in the specification, and not supported on any OS by the hardware partner. Unintentional Hardware is not required to be tested if the remaining hardware continues to be fully functional including where the function provided is unique. It is encouraged that Unintentional Hardware be masked from end users where possible, i.e. disabling or removing features from the BIOS, not providing power, not including connectors, headers, etc. to minimize confusion. A Red Hat Knowledgebase Article may be added to add clarity. Changes to unintentional hardware are considered to be hardware changes and subject to the hardware changes policies and requirements.

4.5. Minimum Test Set

The Red Hat Enterprise Linux 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.

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 RHEL 5 and 6. 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 in RHEL 6 and must be tested to ensure this critical debug information can be captured. 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 RHEL 6.x certifications on the x86, x86_64, and ppc64 architectures.

Note

RHEL 6.0 and 6.1 certifications may optionally use RHEL 6.2 kdump results to satisfy the kdump testing criteria as the kdump requirement policy was established subsequent to these releases. A Red Hat Knowledgebase Article will be added to these certs noting that the minimum version for kdump functionality is RHEL 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.
SUSPEND results require the non -xen kernel in Red Hat Enterprise Linux 5.
None
Converged Adapters (X over Y, i.e. FCoE)
Applicable test for each function visible to the OS.
I,B,K[c]
The collective is considered a feature (eg. FCoE is not equal to Fibre Channel).
Follows the combined functional leverage requirements.
CD-ROM, DVD, Blu-ray
CDROM or DVD or BLURAY
The highest media type in order of BD-RW(highest), BD-R, DVD-RW[d], DVD-R[d], 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
NETWORK or *Ethernet
Each interface @ maximum connection speed.
I,B,K[c]
Nominal network connection speed is considered a feature. Optional 10/100MB/s capable 1Gb/s Ethernet card may substitute for optional 10/100Mb/s or 10Mb/s cards.
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[c]
Nominal connection speed is considered a feature. Remote attached storage devices may require additional testing. (see External Storage and Multipath HBAs)
Identical integrated chipsets, removable adapters, drives and arrays.
IDE/SCSI/SATA/SAS Drives, Arrays, and HBAs
STORAGE
Maximum storage capacity of local attach arrays if greater than OS limit.
I,B,K[c]
Disk drive sizes and controller attached SSDs 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[c]
Nominal connection speed is considered a feature. Remote attached storage devices may require additional testing. (see 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[e] [f]at adaptive or native color depths with available display + graphics controller combinations[g][h]
I[i]
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[c]
Nominal network connection speed is considered a feature. Software stack may be utilized even when a native driver is available.
Identical integrated chipsets and removable adapters.
Memory Cards/Readers[j], 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[c]
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
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[c]
Host RAID/Driver RAID/Fake RAID/etc. use the applicable regular controller policy. Remote attached storage devices may require additional testing. (see 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[k].
I,B
Buses without possible active devices do not require testing.
Identical integrated chipsets, removable adapters
System Processors
CORE[l] and CPUSCALING and PROFILER [FV_CORE and FV_MEMORY] [REALTIME[l] OR RTEVAL[l] and HWLATDETECT[l]]
Maximum number of processors, cores[m], and feature set[n]; 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.[o]
CPUSCALING results may be provided on bare-metal kernels in Red Hat Enterprise Linux 5 and are not required on 32-bit x86 certifications with greater than 32 cores.
PROFILER test runs may utilize timer mode. [p]
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 [q] to existing certifications.
System Memory
MEMORY
Lower of 1GB Per Logical CPU, system limit, or OS limit.[r]
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)
x86 and x86_64 with pae and vmx on Red Hat Enterprise Linux 5; x86_64 only on Red Hat Enterprise Linux 6.
None[s]
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
All pluggable ports at the stated connection version.[t]
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
NETWORK and WLAN or Wireless*
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] Required only for integrated hardware.
[d] "+" and "-" are considered equal for feature review.
[e] Compensation/Stretching does not qualify as native testing.
[f] A horizontal resolution of 1360 may be used on 1366 native panels.
[g] Optional graphics controllers excluded by other policies are not required to be tested. At least one display + controller combination is required for each display.
[h] Display and graphics controller combinations may be clarified in a Red Hat Knowledgebase Article entry to reduce confusion.
[i] Native resolutions not required during install
[j] Memory Card types are limited to MMC, SD, CompactFlash and including variants (eg. mini, micro, etc.).
[k] For example, testing a PCI NIC with the NETWORK test tests the PCI bus.
[l] The minimum installed memory is required to match the System Memory testing requirement.
[m] System or OS maximum, whichever is lower.
[n] Integrated non-usable GPUs are ignored during feature set comparison.
[o] Additional testing may be required where maximum system core count is greater than the currently listed OS Certified maximum.
[p] To force timer mode operation, include options oprofile timer=1 to /etc/modprobe.conf
[q] Processor upgrades are defined as field installable physical packages and may require field installable BIOS/firmware upgrades (Section 3.3, “BIOS/Firmware Policies” apply).
[r] Additional testing may be required where maximum system memory is greater than the currently listed OS Certified maximum.
[s] System Virtualization is leveragable in CPU upgrade leveraging where the existing certification already includes System Virtualization testing.
[t] USB 3.0 ports may be excluded in RHEL5 certifications when working USB 2.0 ports are available; a Red Hat Knowledgebase Article will be added to describe the port functionality.

4.8. Additional Manual Testing

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.


[2] 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.
[3] Notes must be in the positive tone (e.g. "for use with...") and not the negative (e.g. "not for use with...").