https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_Hardware_Certification/1/html-single/Test_Suite_User_Guide/index.html

Red Hat Enterprise Linux Hardware Certification

Test Suite User Guide

The Guide to Performing Red Hat Hardware Certification

Edition 2.0

Gary Case

Red Hat, Inc. Hardware Certification

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 Enterprise Linux Hardware Certification Test Suite User Guide explains the procedures necessary to certify hardware on Red Hat Enterprise software. It gives an overview of the entire certification process, then explains how to set up the certification environment, test the systems or components being certified, and submit the results to Red Hat for verification. Background information is also provided, including the test methodology and results evaluation.
1. The Red Hat Unified Certification Program
1.1. Introduction 1.2. Troubleshooting Issues and Submitting Feedback 1.3. Certification Process Summaries
1.3.1. Hardware Certification Process Summary
1.4. Before You Begin
2. Preparing to Test Hardware
2.1. Choosing the Type of Certification 2.2. Opening a Standard Certification Request for Previously Untested Hardware 2.3. What is a Hardware Specification Entry? 2.4. Opening Additional Standard Certification Requests for the Same Hardware 2.5. Opening a Supplemental Certification Request from a Hardware Specification Entry 2.6. Opening a Supplemental Certification Request When No Hardware Specification Entry Exists 2.7. Opening a System Pass-Through Certification Request from a Hardware Specification Entry 2.8. Opening a System Pass-Through Certification Request When No Hardware Specification Entry Exists 2.9. Opening a Component Pass-Through Certification Request from a Hardware Specification Entry 2.10. Opening a Component Pass-Through Certification Request When No Hardware Specification Entry Exists 2.11. How Red Hat Creates the Official Test Plan 2.12. Leveraging of Existing Test Results 2.13. Preparing the Test Environment 2.14. Preparing Kickstart Files
2.14.1. Preparing a Kickstart File to Install Red Hat Enterprise Linux 6 and redhat-certification 2.14.2. Preparing a Kickstart File to Install Red Hat Enterprise Linux 7 and redhat-certification
2.15. Configuring the System Under Test 2.16. Configuring the Local Test Server
2.16.1. Using Locally-Hosted Pre-Built Guest Files
3. Testing Hardware
3.1. Scheduling and Running Tests with the Red Hat Certification Tool
3.1.1. Adding a Product to the Test Server from the Red Hat Certification Catalog 3.1.2. Adding a Product to the Test Server's "Sandbox" section 3.1.3. Selecting and Running Tests
3.2. Certifying for Red Hat Enterprise Linux
3.2.1. Testing a Server 3.2.2. Testing a Desktop/Workstation 3.2.3. Testing a Laptop 3.2.4. Testing a Component
3.3. Layered Product Certifications
3.3.1. Certifying for Red Hat OpenStack Platform Compute 3.3.2. Certifying for Red Hat Storage Server 3.3.3. Certifying for Red Hat Enterprise Linux for Real Time
3.4. Submitting Results
3.4.1. Automatic Upload from the Test Server 3.4.2. Manual Submission
3.5. Monitoring Certification Progress 3.6. Completing Certifications
A. Appendixes
A.1. Hardware Test Procedures
A.1.1. 1GigEthernet A.1.2. 10GigEthernet A.1.3. 20GigEthernet A.1.4. 25GigEthernet A.1.5. 40GigEthernet A.1.6. 50GigEthernet A.1.7. 100GigEthernet A.1.8. audio A.1.9. battery A.1.10. bluray A.1.11. cdrom A.1.12. core A.1.13. cpuscaling A.1.14. dvd A.1.15. Ethernet A.1.16. expresscard A.1.17. fencing (Optional) A.1.18. fv_core A.1.19. fv_memory A.1.20. fv_network (Optional for SR-IOV) A.1.21. fv_storage (Optional) A.1.22. info A.1.23. kdump A.1.24. lid A.1.25. memory A.1.26. network A.1.27. pccard (Red Hat Enterprise Linux 6 only) A.1.28. profiler A.1.29. realtime A.1.30. reboot (Optional) A.1.31. storage A.1.32. suspend (Laptops only) A.1.33. tape A.1.34. USB2 A.1.35. USB3 A.1.36. video A.1.37. WirelessG A.1.38. WirelessN A.1.39. WirelessAC (Red Hat Enterprise Linux 7 only)
A.2. Manually Adding Tests
B. Revision History Index

⁠Chapter 1. The Red Hat Unified Certification Program

1.1. Introduction 1.2. Troubleshooting Issues and Submitting Feedback 1.3. Certification Process Summaries
1.3.1. Hardware Certification Process Summary
1.4. Before You Begin

⁠1.1. Introduction

The Red Hat Unified Certification Program is Red Hat's method of certifying hardware and software to be compatible with Red Hat Enterprise Linux, Red Hat OpenStack Platform, Red Hat Storage Server, Red Hat Enterprise Linux for Real Time, and other Red Hat software products. The program has three main elements: the test suite, which tests the hardware or software undergoing certification; the Red Hat Unified Certification Catalog, available at https://access.redhat.com/certifications, which displays certified hardware and software to the public; and a joint support relationship between Red Hat and the vendor whose hardware or software is undergoing certification.
This user guide covers all aspects of the hardware portion of the Red Hat Unified Certification process, from the initial request for certification to the final approval and posting of the certification. It is geared towards the engineer who has been tasked with certifying their company's products to run one or more of Red Hat's products. It assumes that you as the tester have a basic level of knowledge about the software that is being used for certification, and are familiar with concepts like operating system installation, software installation, and where applicable, hardware installation and removal.
The policies and other rules of the program are covered in the separate Red Hat Hardware Certification Policy Guide, which is available at the following link:
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux_Hardware_Certification/

⁠1.2. Troubleshooting Issues and Submitting Feedback

Partners who have a dedicated support resource that is an assigned Engineering Partner Manager, Engineering Account Manager or Technical Account Manager may open a support case using the same tool they use to request support for other Red Hat products.
Partners who do not have a dedicated support resource may open a support case using Red Hat Customer Portal under the following instances:
  • To report issues and get help with the certification process
  • To submit feedback and request enhancements in the certification toolset and documentation
  • To receive assistance on the Red Hat product on which your product or application is being certified. To receive Red Hat product assistance, it is mandatory to have the required product entitlements and subscriptions which are separate from certification-specific entitlements and subscriptions
To open a support case using Red Hat Customer Portal Interface, complete the following steps:
  1. Log in Red Hat Customer Portal using Red Hat account credentials which are also used to access other Red Hat assets like Red Hat Connect for Technology Partners and software subscriptions.
  2. Click Open a Support Case on Red Hat Customer Portal Home Page.
  3. Complete the Support Case Form with special attention to the following fields:
    • From the Product field, select the name of the Red Hat product on which your product/application is being certified, based on the following details:
      • For Red Hat OpenStack Platform Certification, select Red Hat OpenStack Platform
      • For Certified Cloud and Service Provider (CCSP) Certification, select Red Hat Enterprise Linux
      • For Red Hat Container Certification, select Red Hat Enterprise Linux
      • For Red Hat Hardware Certification, select Red Hat Enterprise Linux
    • From the Product Version field, select the version of the product
    • In the Problem Statement field, type a problem statement/issue or feedback using the following format: {Partner Certification} (The Issue/Problem or Feedback)
      Replace (The Issue/Problem or Feedback) with either the issue/problem faced in the certification process/Red Hat product or feedback on the certification toolset/documentation.
      For example: {Partner Certification} Error occurred while submitting certification test results using Red Hat Certification application

      Important

      It is mandatory to write the problem statement with the {Partner Certification} tag to ensure assignment of the case to the appropriate group(s).
Complete the remaining form using the details covered in this article.

Note

Support cases related to Certification use Severity 3 SLAs. For more details about initial and ongoing response times, visit the Production Support Service Level Agreement

⁠1.3. Certification Process Summaries

We begin with an outline of the basic certification procedure for each of the eligible items. We will discuss each step in greater detail as we move through the document.

⁠1.3.1. Hardware Certification Process Summary

Hardware certification covers the testing of servers, desktops/workstations, laptops, and individual components to run Red Hat Enterprise Linux, Red Hat OpenStack Platform Compute, Red Hat Storage Server, and Red Hat Enterprise Linux for Real Time.
⁠
  1. The partner establishes a certification relationship with Red Hat.
  2. The partner creates a request for the certification of a specific system or hardware component on Red Hat's internal certification website ( https://hardware.redhat.com).
  3. Red Hat's certification review team creates an official test plan inside the certification request to track the testing of all relevant components.
  4. The partner runs the tests specified in the official test plan and submits results packages to Red Hat for analysis.
  5. The review team analyzes the test results and marks them as completed when they receive passing results. Any failures require retesting.
  6. The partner provides Red Hat with a representative hardware sample that covers the items that are being certified.
  7. The system or component is marked as certified when all tests have passing results, and the entry is made visible to the public on the external Red Hat Hardware Certification website at https://access.redhat.com/certifications if the partner requested a published certification.
You can refer to Section 1.2, “Troubleshooting Issues and Submitting Feedback” if you need help at any time.

⁠1.4. Before You Begin

Red Hat requires a relationship agreement that is specific to the type of certification being performed before we can accept certification requests. This relationship may be documented in a section or subsection of an OEM or other partnership agreement, or it can be established by an independent certification agreement. The creation of an OEM or other partnership agreement is not covered here, as that is something handled by other groups. Talk with your assigned Red Hat representative if you want to know more about partnerships beyond hardware certification. If you would like to establish an independent hardware certification agreement, you may do so via the following steps:
⁠
  1. Purchase Membership in the Red Hat Certification 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. Please provide the following information:
    1. Text indicating that you wish to purchase membership in the Red Hat Hardware Certification Program
    2. Contact information for the person who will be placing the order
    3. Your company's legal name
    4. Billing address (please do not include credit card information)
    We will have a Red Hat sales person contact you to complete the purchasing process, which includes the creation of an account on the Red Hat Customer Portal ( https://access.redhat.com)
  2. Create a Red Hat Customer Portal Account and Login
    The certification test suite uses 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.

    Note

    If you already have a Customer Portal login skip this step. If you do not have a login but your company has logins on the Portal, please ask your company's organization administrator to create a login for you under the company's account.
    To create a Red Hat Customer Portal account, complete the following steps.
    1. Navigate to Red Hat Customer Portal.
    2. Select Register in the menu and follow the instructions. Make sure that you create a company account and not a personal account. The account created during this step is also used to sign in to the Red Hat Hardware Catalog when working with certification requests.

      Note

      A Red Hat Customer Portal organization administrator in your organization will have the permissions to create an SSO account for your organization. If you are not familiar with the Red Hat Customer Portal organization administrator for your organization, you may contact your engineering account manager or engineering partner manager for assistance.
  3. Obtain required Red Hat Certification Catalog permissions
    1. File a support request to have certification creation permissions added to your Red Hat Customer Portal login. If you have an assigned technical account manager (TAM) or engineering partner manager (EPM), file a request through Red Hat Bugzilla at http://bugzilla.redhat.com. If you do not have a TAM, file a request through Red Hat's Customer Portal at https://access.redhat.com. Include your Red Hat Customer Portal account user name in the request. After this request has been approved and you log in to the hardware catalog, the Create link will appear in the hardware catalog menu. This allows you to create a new certification request.

      Note

      It is mandatory to obtain Red Hat Certification permissions on your Red Hat Customer Portal account before it can be used for certification purposes.

⁠Chapter 2. Preparing to Test Hardware

2.1. Choosing the Type of Certification 2.2. Opening a Standard Certification Request for Previously Untested Hardware 2.3. What is a Hardware Specification Entry? 2.4. Opening Additional Standard Certification Requests for the Same Hardware 2.5. Opening a Supplemental Certification Request from a Hardware Specification Entry 2.6. Opening a Supplemental Certification Request When No Hardware Specification Entry Exists 2.7. Opening a System Pass-Through Certification Request from a Hardware Specification Entry 2.8. Opening a System Pass-Through Certification Request When No Hardware Specification Entry Exists 2.9. Opening a Component Pass-Through Certification Request from a Hardware Specification Entry 2.10. Opening a Component Pass-Through Certification Request When No Hardware Specification Entry Exists 2.11. How Red Hat Creates the Official Test Plan 2.12. Leveraging of Existing Test Results 2.13. Preparing the Test Environment 2.14. Preparing Kickstart Files
2.14.1. Preparing a Kickstart File to Install Red Hat Enterprise Linux 6 and redhat-certification 2.14.2. Preparing a Kickstart File to Install Red Hat Enterprise Linux 7 and redhat-certification
2.15. Configuring the System Under Test 2.16. Configuring the Local Test Server
2.16.1. Using Locally-Hosted Pre-Built Guest Files

⁠2.1. Choosing the Type of Certification

There are several different types of hardware certifications that exist within the Red Hat Hardware Certification Program:
  • Standard Certification - This type of certification is the most common one, where a previously untested system or component is tested and proven to be compatible with Red Hat Enterprise software products. A successfully completed certification request can result in two different types of catalog entries. In a published certification, the device is published on the hardware catalog https://access.redhat.com/certifications. In an unpublished certification, the device is kept private and does not appear publicly on the hardware catalog. All certifications are in the unpublished state when they are opened and remain in the unpublished state unless the decision is made to publish them.
  • Supplemental Certification - This type of certification covers the testing of changes that have been made to already certified equipment, such as a processor family upgrade in an existing certified server. It remains unpublished when completed.
  • System Pass-Through Certification - This type of certification is performed when a system is being resold under a different vendor, make, or model name. It is also used when a vendor sells a series of systems whose configurations are subsets of a larger, superset system. It can be published or remain unpublished when completed.
  • Component Pass-Through Certification - This type of certification is performed when a component is being resold under a different vendor, make, or model name. It is also used when a vendor sells a series of components whose configurations are subsets of a larger, superset component. It can be published or remain unpublished when completed.
We will go through the procedure for opening a standard certification first, then explain the differences between standard and other certification types in the sections that follow.

⁠2.2. Opening a Standard Certification Request for Previously Untested Hardware

In a standard certification, systems or components are tested following the steps in Section 1.3.1, “Hardware Certification Process Summary”, resulting in a published certification that is viewable by any member of the general public who visits the hardware catalog. The option also exists for a unpublished certification, which is typically used in the case of models or components that are not available to the general public. All the steps are identical in published and unpublished certifications until the last step is reached, when the certification reviewer chooses to either publish a certification and make it visible to the public, or leave it unpublished and make it visible to only the original partner and Red Hat.

Important

Published and unpublished certifications are covered by the same Policy Guide rules. Unpublished certifications cannot be used to work around problems that render a system uncertifiable, such as non-functional integrated hardware or storage controllers that all require proprietary drivers for functionality. See the policy guide for more information.
An example of completed, published certifications for the hypothetical "Mycompany Ultraserver X12" server can be seen in the figure below.
⁠
Public View of Published Certifications

Figure 2.1. Public View of Published Certifications

The certification processes for all the different types of certifications are managed through the partner Red Hat Hardware Catalog, located at https://hardware.redhat.com. We will go through the standard certification process in this example.

Note

The rhcert tool does not open new certification requests at this time. All new certification requests for use with the rhcert tool must be opened using the web interface of the Hardware Catalog. Follow the steps below to open a new request.
To begin, you must log in to the catalog website located at https://hardware.redhat.com using the Red Hat Customer Portal SSO credentials referenced in Section 1.4, “Before You Begin”.
To log in to the catalog website ( https://hardware.redhat.com) using Red Hat Customer Portal SSO account, click the Account button at the top right of the catalog website. Click the Create link in the menu bar after logging in to start the creation process. The page that loads asks you to choose the product you will be certifying with, either Red Hat Enterprise Linux or Red Hat OpenStack Platform. Choose "Red Hat Enterprise Linux" and continue to the next page.
⁠
Choose Product

Figure 2.2. Choose Product

The new certification creation page that loads next contains a number of fields for you to fill out:
⁠
Create New Entry Fields

Figure 2.3. Create New Entry Fields

  • Reporter - This field is automatically filled in with your username.
  • Entry Type - This field lets you choose what kind of entry to create. Choose Create Both to create a hardware certification request and a hardware specification entry for all previously untested hardware. For an explanation of hardware specification entries and how they relate to certification entries, please see Section 2.3, “What is a Hardware Specification Entry?”.
  • Product Data Source - The catalog can read data from a results package to fill out some of the fields on this page. Until you are famliar with the certification process and are comfortable choosing hardware to be tested before receiving an official test plan, we recommend using the Provide Manually option and skipping down to the Hardware Details section below. If you are familiar with the certification process, you can choose the Acquire from Package option here and provide a results package in the dialog box shown below. The catalog will pull the vendor, make, model, version, platfom, and other information from the results package and fill it in for you.
If you chose Acquire from Package as your product data source, you will see these fields:
⁠
Upload Certification Package Fields

Figure 2.4. Upload Certification Package Fields

  • File - This is the results file you wish to upload to the catalog.
  • Description - Enter a brief description of the results file here. We recommend something that will help you differentiate it from other results files submitted to this or other certification requests.
If you chose Provide Manually as your product data source, you will see these fields:
⁠
Hardware Details Fields

Figure 2.5. Hardware Details Fields

  • Vendor - This dropdown box holds the names of all the companies with previously certified systems. For our example we have used "Mycompany" as a hypothetical vendor. If your vendor name does not appear here, select Unlisted Vendor and the review team will add your company's name to the list.
  • Make - This dropdown box holds the names of all the families of computers that have already been submitted for the vendor chosen above. It is the "Ultraserver" in the hypothetical "Mycompany Ultraserver X16". If a new make is needed, use the next field.
  • Add New Make - Add a new system make here if it is not already in the Make dropdown box.
  • Model - This is the model of computer being tested. It is the "X16" in "Mycompany Ultraserver X16".
  • Category - This is the type of item you are certifying. The selection you make has no effect on the number or type of tests that are run, it simply tells us how to list it in the catalog. As the hypothetical "Mycompany Ultraserver X16" system is a server, the proper selection for this field is Server.
  • Product URL - This optional field allows you to enter a different URL for the home of your product. For example, if you provide us with a link to a PDF document with system specs in the Specification URL section, you can use this field to link to the HTML page that describes all your system's or component's features.
  • Support URL - This optional field allows you to enter a link to a support section on your website that handles questions about this system or component.
  • Specification URL - This field is provided for you to enter the specifications URL for your product. The review team will use the information here to build the official test plan that must be completed in order to certify the system. We discuss the official test plan in greater detail in Section 2.11, “How Red Hat Creates the Official Test Plan”. If the URL cannot be included (the system is unreleased and has no public URL, for example), we allow you to attach a document that contains the specs instead. Use the Upload Specification section, discussed below, to upload your document. This information is also used to populate the hardware specification entry, which is discussed in Section 2.3, “What is a Hardware Specification Entry?”.
  • Specification Status - The radio button (Production/Preproduction) allow you to indicate whether the specs link is for a real shipping system or if it is preproduction only. If preproduction is selected, our review team will need to see final production specs before the certification can be completed.
⁠
Certification Details Fields

Figure 2.6. Certification Details Fields

  • Product - This is the software you are certifying your hardware on. The only option at the moment is "Red Hat Enterprise Linux", but other products may be added in the future.
  • Version - The major version number of Red Hat software product you are certifying with. For Red Hat Enterprise Linux, this will be 6, 7, etc. The update release, if any, will be set using data from test results packages.
  • Platform - The architecture you are certifying against. If you will be certifying multiple architectures, select any of the architectures you will be certifying with from this box. The others will be added automatically using data from test results packages.
⁠
Upload Specification Fields

Figure 2.7. Upload Specification Fields

The Upload Specification section allows you to attach a specification document for your product if a web-based version is not available. The review team will use the information here to build the official test plan that must be completed in order to certify the system. We discuss the official test plan in greater detail in Section 2.11, “How Red Hat Creates the Official Test Plan”. It is mandatory to attach the specification document for your product at this stage especially if you are unable to provide a specification URL. This information is also used to populate the hardware specification entry, which is discussed in Section 2.3, “What is a Hardware Specification Entry?”.
⁠
Policy Guide Confirmation

Figure 2.8. Policy Guide Confirmation

The Policy Guide confirmation section confirms that you have read the Policy Guide, which is the official document that contains the requirements for certification. It was used to prepare this guide and it is the document that the review team uses when they build the official test plan for submitted hardware. The link will take you to the document if you want to read it. Click the Continue button when you are ready to move to the next step.
⁠
Certification Summary

Figure 2.9. Certification Summary

The screen you are taken to after clicking the Continue button shows a summary of the information you have provided. If this is correct, proceed to the next section. Otherwise, go back and correct any problems.
⁠
Red Hat Storage Server Fields

Figure 2.10. Red Hat Storage Server Fields

If you wish to create a Red Hat Storage Server certification with your Red Hat Enterprise Linux 6 Intel 64 and AMD64 certification, select the Yes option here. If you are interested in the program (there is no additional charge or additional testing required), please speak with your Red Hat Support representative for more information.
⁠
Hardware Sample Shipment Information Fields

Figure 2.11. Hardware Sample Shipment Information Fields

This section of the document provides an area for you to enter sample hardware shipment information. Red Hat requires a representative hardware sample for each unique model of hardware that we certify. If the information is not provided at this time, it will need to be provided before the certification can be published. This same section is available in the certification entry after it has been submitted so the information can be provided at any time.
⁠
Additional Comments Field and Submission Button

Figure 2.12. Additional Comments Field and Submission Button

If there is an further information you wish to tell us about the certification you are submitting you may enter it in the Additional Comment box. The box may also be left blank. Once you are satisfied that all the information is correct, click the Yes, Submit button to create the certification request.
At this point, the certification is open and ready for analysis by the review team. Move ahead to Section 2.11, “How Red Hat Creates the Official Test Plan” if you are performing a standard certification, or continue reading to learn about the other types of certifications.

⁠2.3. What is a Hardware Specification Entry?

Note

It is only necessary to read this section if you are curious about the purpose of a hardware specification entry. One will be automatically created for you each time a new certification is opened.
In November 2013, we introduced an update to the Red Hat Hardware Catalog that enabled the separation of system/component specification review from the creation of the official test plan. With this separation, we can shorten the certification process whenever the same hardware model is certified on multiple versions of Red Hat Enterprise Linux or on multiple Red Hat software products. We call the new feature that enables this a "hardware specification entry".
A hardware specification entry is a separate hardware catalog entry that contains a list of all the testable components that make up a system or component, the category each component falls under, and the features the component provides. Hardware specification entries are never closed, and they are never visible to the general public on the hardware catalog.
Hardware specification entries are automatically opened with each new certification request when following the directions in Section 2.2, “Opening a Standard Certification Request for Previously Untested Hardware” under the "Create New Entry Fields" heading. They can also be opened independently of any certification requests by following the same directions under "Create New Entry Fields" but selecting Hardware Specification from the dropdown box instead of Both. There will be no Certification Details box to fill in when this option is selected.
After the hardware specification entry is created, the review team will analyze the specifications URL or document that is associated with it, and populate the specification entry with a list of testable components. This list is then used to expedite the creation of a succession of official test plans in related certifications.
An excerpt from an example hardware specification entry can be seen below:
⁠
Example Hardware Specification Entry

Figure 2.13. Example Hardware Specification Entry

In the example you can see the component description, the type of option, whether or not it is part of a supplemental certification, and the compnent features that require testing. If you feel that there are problems with any of the components in the hardware specification entry, talk to your Red Hat support contact to resolve the issue or add a comment to the hardware specification entry.

⁠2.4. Opening Additional Standard Certification Requests for the Same Hardware

To certify the same hardware on multiple versions of Red Hat Enterprise Linux, you create an initial certification on one version, then use that certification's hardware specification entry to open additional certification requests for other versions of Red Hat Enterprise Linux.
If you are working with a system or component that has no hardware specification entry, follow the steps in Section 2.2, “Opening a Standard Certification Request for Previously Untested Hardware” to create the new certification request and associated hardware specification entry. Once this second certification for the hardware is opened, you will use its specification entry to create any further certification requests for the same hardware (request numbers 3, 4, 5, etc.), following the procedure below.
To create a new certification from the hardware specification entry, open the specification entry for your hardware, select the Certifications tab, and scroll down to the Create New Original Certification section. If you do not know the specification entry for your hardware, it can be found under the Advanced tab on its certification.
⁠
Create New Original Certification Fields

Figure 2.14. Create New Original Certification Fields

  • Product - This is the software you are certifying your hardware on. The only option at the moment is "Red Hat Enterprise Linux", but other products may be added in the future.
  • Category - This is the type of item you are certifying.
  • Version - The major version number of Red Hat software product you are certifying with. For Red Hat Enterprise Linux, this will be 6, 7, etc. The update release, if any, will be set using data from test results packages.
  • Platform - The architecture you are certifying against. If you will be certifying multiple architectures, select any of the architectures you will be certifying with from this box. The others will be added automatically using data from test results packages.
  • Create Red Hat OpenStack Certification - Automatically create a Red Hat OpenStack Platform certification entry for this new certification request.
Click the Create Original Certification button when finished. The catalog will take you to the new certification request. You can see a link to the hardware specification entry in the Advanced section of the new certification. If you view the hardware specification entry again, you will find that the new certification request has been added to its Certifications section.
At this point, the additional certification request is open and ready for analysis by the review team. Move ahead to Section 2.11, “How Red Hat Creates the Official Test Plan” if you are performing a standard certification, or continue reading to learn about the other types of certifications.

⁠2.5. Opening a Supplemental Certification Request from a Hardware Specification Entry

Certified systems often have component changes during their life cycles as new components become available. Any change to a certified system's specs that would require a retest due to the rules of the Policy Guide require the vendor to submit a special certification request called a supplemental certification. Supplemental certifications cover testing of the changed components and allow us to confirm that they work with Red Hat Enterprise Linux. There are two major differences between regular and supplemental certifications:
  • Supplemental certifications only require the tests necessary to confirm the functionality of the new component(s). This means that most supplemental certifications contain fewer tests than the original full system certification.
  • Supplemental certifications are never published when they are completed. The original certification entry for the system remains the only entry viewable by the public (if it was published).
Processor upgrades are the most common type of supplemental certification, so we can use them in an example of the supplemental certification process. Let's say you are updating your company's workstation system with two new ten-core, 64-bit processors from Acme. Your original certification for this system used an earlier generation processor. We know from the Policy Guide's hardware class requirements section that a change in the processor generation requires retesting, so a supplemental cert is in order. This is the procedure that you would follow to submit the supplemental cert for the upgraded processor:

Important

Testing in supplemental certifications should occur on the same major version and update release of Red Hat Enterprise Linux that was used for the original cert, whenever possible. If a newer update release of Red Hat Enterprise Linux is used, a knowledgebase article is attached to the original certification indicating that support for the new components requires the new update release.
  1. To begin, open the hardware specification entry for the system. If you do not know the ID for the entry, you can find it the Advanced section of any associated hardware certification requests.
  2. Click the Certifications tab and find the Create New Original Certification section.
    ⁠
    Create New Original Certification Fields

    Figure 2.15. Create New Original Certification Fields

  3. Set all the options to match the existing certification, and set the Create Red Hat OpenStack Platform Certification option to No. You do not need a separate supplemental certification for Red Hat OpenStack Platform.
  4. Click the Create Original Certification button and the new certification will be created.
  5. When the new certification loads, click the Dialog tab and find the Add A Comment text box. Add a comment stating that this is a supplemental certification for new hardware, describe the new hardware that will be tested, and provide a link to the original certification. Set the comment to Need additional information from: Reviewer and click the Save Changes button when finished.
At this point, the supplemental certification request is open and ready for analysis by the review team. Move ahead to Section 2.11, “How Red Hat Creates the Official Test Plan” if you are performing a supplemental certification, or continue reading to learn about the other types of certifications.

⁠2.6. Opening a Supplemental Certification Request When No Hardware Specification Entry Exists

As mentioned in the previous section, a supplemental certification is created when new hardware is added to an existing certified system. Supplemental certifications are begun from a new certification if no hardware specification entry was created for the existing certified system. Follow these steps to create the supplemental certification:

Important

Testing in supplemental certifications should occur on the same major version and update release of Red Hat Enterprise Linux that was used for the original cert, whenever possible. If a newer update release of Red Hat Enterprise Linux is used, a knowledgebase article is attached to the original certification indicating that support for the new components requires the new update release.
  1. Open a new certification entry on the hardware catalog using the procedures described in Section 2.2, “Opening a Standard Certification Request for Previously Untested Hardware”.
  2. Use the same vendor, make, model, and specs URL as the original certification.
  3. Use the same product, version, and platform as the original certification.
  4. After creating the new certification, click the Dialog tab and find the Add A Comment text box. Add a comment stating that this is a supplemental certification for new hardware, describe the new hardware that will be tested, and provide a link to the original certification. Set the comment to Need additional information from: Reviewer and click the Save Changes button when finished.
At this point, the supplemental certification request is open and ready for analysis by the review team. Move ahead to Section 2.11, “How Red Hat Creates the Official Test Plan” if you are performing a supplemental certification, or continue reading to learn about the other types of certifications.

⁠2.7. Opening a System Pass-Through Certification Request from a Hardware Specification Entry

System pass-through certifications essentially create copies of certified systems, listing them under a different vendor name, a different make, or a different model. They are used in several different scenarios:
  1. A vendor sells their systems to partners who rebrand and resell them to the public. The reseller makes no more than minor (see note below) changes to the system, packages it and sells it under their own name.
  2. Two or more systems are being certified by the same vendor, with one system being a superset of all the others. The superset of the two or more systems can be certified, and pass-through used to create entries for each of the systems that are subsets of the main system without additional testing.
Please talk with your Red Hat Support contact to determine if pass-through certification will work for your specific system(s). Note that a completed certification must exist before a pass-through request may be opened.

Note

Minor changes as described here are things such as new splash screens or the addition of further optional hardware components. Major changes are things like differences in integrated hardware or BIOS feature additions, which would make a system or component ineligible for the pass-through program. Your Red Hat Support contact can help you determine if your items are eligible for pass-through.
To begin, open the hardware specification entry for the system. If you do not know the ID for the entry, you can find it the Advanced section of any associated hardware certification requests. When the entry is open, click the Pass-Through menu and find the Create New Pass-Through System box.
⁠
Create New Pass-Through System Fields

Figure 2.16. Create New Pass-Through System Fields

Fill out the information there as follows:
  • Vendor - The name of the company selling the newly created pass-through system. This could be a reseller in the case of a rebranded system, or it could be the original company if the pass-through cert is being used to handle a series of systems which are a subset of the parent and are being sold by the original company.
  • Make - The make assigned to the pass-through system. For our example, we are using the Mycompany Ultraserver X16 as a superset of a new model, the X15, that is also made by Mycompany. In this case, the make would stay "Ultraserver"
  • Model - The model name for the pass-through system. The new pass-through system is the Mycompany Ultraserver X15, so the model here is "X15".
  • Category - The type of item you are certifying. The X15 is another server, so the category should be set to "Server".
  • Product Home Page URL - This optional field allows you to enter a different URL for the home of the pass-through product.
  • Support Home Page URL - This optional field allows you to enter a link to the support section on the pass-through system vendor's website that handles questions about the pass-through system or component.
  • Specification URL - The vendor's specs URL for the rebranded or subset system. We must have this in order to analyze any differences between the parent and the pass-through system.
  • Specification Status - The radio buttons (Production/Preproduction) allow you to indicate whether the specs link is for a real shipping system or if it is preproduction only. If preproduction is selected, our review team will need to see final production specs before the certification can be completed.
Check the checkbox after you have read the pass-through section of the Policy Guide (a link to the guide is displayed here) and click the Create Pass Through System button to create a new hardware specification entry with the pass-through hardware's vendor, make and model information.
Now that the new hardware specification entry has been created, we need to create the certification request that can be associated with it. This is done from the original certification request, not the hardware specification entry that was just created. Here are the steps to follow:
  • Click on the link in the Original Specification field under the Summary section of the new specification entry you just created.
  • When the original specification entry loads, click the Certifications tab and click the link to the original certification. It will be in the Certifications section on the page.
  • In the original certification, click the Advanced tab and find the Create new Pass-Through Certification section. The image below shows this section.
  • Use the drop-down box to select the pass-through hardware specification entry you created in the first half of this section.
  • Check the checkbox after you have read the pass-through section of the Policy Guide, and then click the Create Clone from Hardware Entry button to create the certification request.
⁠
Create New Pass-Through Certification Fields

Figure 2.17. Create New Pass-Through Certification Fields

The review team will analyze the pass-through certification request's specs URL and notify you if any differences between it and the original system's specs are found. If major differences are found, such as new features or hardware, they will either reject the request with an explanation, or request supplemental certification (see Section 2.5, “Opening a Supplemental Certification Request from a Hardware Specification Entry” for more information on supplemental certifications) of the additional hardware to fill in any gaps. The supplemental certification items will be added to the pass-through certification request's test plan and will be handled within the pass-through certification request. When any supplemental items are completed with passing results, the pass-through certification will be approved.

⁠2.8. Opening a System Pass-Through Certification Request When No Hardware Specification Entry Exists

As mentioned in the previous section, system pass-through certifications essentially create copies of certified systems, listing them under a different vendor name, a different make, or a different model. A completed system certification must exist before the pass-through request may be opened.
If no hardware specification entry exists, system pass-through certifications are begun from the original system certification entry. Scroll to the top of the original certification, click on the Advanced menu, and find the Create New Pass-Through Certification box.
⁠
Create New Pass-Through Certification Fields

Figure 2.18. Create New Pass-Through Certification Fields

Fill out the information there as follows:
  • Vendor - The name of the company selling the newly created pass-through system. This could be a reseller in the case of a rebranded system, or it could be the original company if the pass-through certification is being used to handle a series of systems which are a subset of the parent and are being sold by the original company.
  • Make - The make assigned to the pass-through system. For our example, we are using the Mycompany Ultraserver X16 as a superset of a new model X15 that is also made by Mycompany. In this case, the make would stay "Ultraserver"
  • Model - The model name for the pass-through system. The new pass-through system is the Mycompany Ultraserver X15, so the model here is "X15".
  • URL - The vendor's specs URL for the rebranded or subset system. We must have this in order to analyze any differences between the parent and the clone.
Check the checkbox after you have read the pass-through section of the Policy Guide, and then click the Create Clone button to create the certification request. The review team will analyze the pass-through certification request's specs URL and notify you if any differences between it and the original system's specs are found. If major differences are found, such as new features or hardware, they will either reject the request with an explanation, or request supplemental certification (see Section 2.5, “Opening a Supplemental Certification Request from a Hardware Specification Entry” for more information on supplemental certifications) of the additional hardware to fill in any gaps. The supplemental certification items will be added to the pass-through certification request's test plan and will be handled within the pass-through certification request. When any supplemental items are completed with passing results, the pass-through certification will be approved.

⁠2.9. Opening a Component Pass-Through Certification Request from a Hardware Specification Entry

Component pass-through certifications essentially create copies of certified components, listing them under a different vendor name, a different make, or a different model. They are used in several different scenarios:
  1. A system vendor wishes to include a component in one or more of their systems that has already been certified by the component vendor. The system vendor wants to avoid retesting the card as the work has already been done by the component vendor. The system vendor will sell the card under the original name.
  2. A component vendor sells their components to partners who rebrand and resell them to the public. The reseller makes no more than minor (see note below) changes to the component, packages it and sells it under their own reseller name.
  3. Two or more components are being certified by the same vendor, with one component being a superset of all the others. The superset of the two or more components can be certified, and pass-through used to create entries for each of the components that are subsets of the main component without additional testing.
Please talk with your Red Hat Support contact to determine if pass-through certification will work for your specific component(s). Note that component vendors may utilize the pass-through process only for standard PCIe form-factor network and storage option cards at this time. Other form factors, like mezzanine cards, and component types, like video cards, may be added in the future. Also, please note that a component pass-through request may only be opened after the original component has undergone standard certification. The creation of a standard certification request is covered in Section 2.2, “Opening a Standard Certification Request for Previously Untested Hardware”.

Note

Minor changes as described here are things such as new splash screens or the addition of further optional hardware components. Major changes are things like differences in integrated hardware or BIOS feature additions, which would make a system or component ineligible for the pass-through program. Your Red Hat Support contact can help you determine if your items are eligible for pass-through.
To begin, open the hardware specification entry for the component. If you do not know the ID for the entry, you can find it in the Advanced section of any associated hardware certification requests. When the hardware specification entry is open, click the Pass-Through menu and find the Create New Pass-Through Component box.
⁠
Create New Pass-Through Component Fields

Figure 2.19. Create New Pass-Through Component Fields

Fill out the information there as follows:
  • Vendor - The name of the company selling the component for which you are creating this pass-through certification request. This could be a reseller in the case of a rebranded component, or it could be the original company if the pass-through cert is being used to handle a series of components which are a subset of the parent and are being sold by the original company. In this example, we will be rebranding the "Mycompany Supercard NIC1000" network card as the "Othercompany Ultracard C165", so the vendor listed here should be "Othercompany".
  • Make - The make assigned to the pass-through component. The new pass-through component is the Othercompany Ultracard C165, so the make here is "Ultracard".
  • Model - The model name for the pass-through component. The new pass-through component is the Othercompany Ultracard C165, so the model here is "C165".
  • Category - The type of item you are certifying. The C165 is another component, so the category should stay "Component/Peripheral".
  • Product Home Page URL - This optional field allows you to enter a different URL for the home of the pass-through product.
  • Support Home Page URL - This optional field allows you to enter a link to the support section on the pass-through component vendor's website that handles questions about the pass-through component.
  • Specification URL - The vendor's specs URL for the rebranded or subset component. We must have this in order to analyze any differences between the original component and the pass-through copy.
  • Production / Preproduction - This radio button allows you to indicate whether the specs link is for a real shipping component or if it is preproduction only. If preproduction is selected, our review team will need to see final production specs before the certification can be completed.
Check the checkbox after you have read the pass-through policy guide (a link to the guide is displayed on the pass-through page) and click the Create Pass Through Component to create a new hardware specification entry with the pass-through hardware's vendor, make and model information.
The review team will analyze the pass-through certification request's specs URL and notify you if any differences between it and the original component's specs are found. If differences are found, they will request an explanation to determine if the components are eligible for pass-through.
Now that the new hardware specification entry has been created, we need to create the certification request that can be associated with it. This is done from the original certification request, not the hardware specification entry that was just created. Here are the steps to follow:
  • Click on the link in the Original Specification field under the Summary section of the new specification entry you just created.
  • When the original specification entry loads, click the Certifications tab and click the link to the original certification. It will be in the Certifications section on the page.
  • In the original certification, click the Advanced tab and find the Create New Pass-Through Certification section. The image below shows this section.
  • Use the drop-down box to select the pass-through hardware specification entry you created in the first half of this section.
  • Click the checkbox after you have read the certification policy document, and then click the Create Clone from Hardware Entry button to create the certification request.
⁠
Create New Pass-Through Certification Fields

Figure 2.20. Create New Pass-Through Certification Fields

⁠2.10. Opening a Component Pass-Through Certification Request When No Hardware Specification Entry Exists

As mentioned in the previous section, component pass-through certifications essentially create copies of certified components, listing them under a different vendor name, a different make, or a different model.
Please talk with your Red Hat Support contact to determine if pass-through certification will work for your specific component(s). Note that component vendors may utilize the pass-through process only for standard PCIe form-factor network and storage option cards at this time. Other form factors, like mezzanine cards, and component types, like video cards, may be added in the future. Also, please note that a component pass-through request may only be opened after the original component has undergone standard certification. The creation of a standard certification request is covered in Section 2.2, “Opening a Standard Certification Request for Previously Untested Hardware”.
Component pass-through certifications are begun from the original component certification entry when no hardware specification entry exists. Scroll to the top of the original cert, click on the Advanced menu, and find the Create New Pass-Through Certification box.
Fill out the information there as follows:
  • Vendor - The name of the company selling the pass-through component.
    • If the component is being sold through a reseller and is being rebranded, use the the reseller's name here. For example, the "Mycompany Supercard NIC1000" is being rebranded as the "Othercompany Ultracard C165" and sold by Othercompany. This is the example we are showing in the graphic above.
    • If the component is being sold through a reseller and is retaining the original name, you should still use the reseller's name here. For example, the "Mycompany Supercard NIC1000" is being included in a server built by Othercompany, but the name is staying "Mycompany Supercard NIC1000". This is to avoid conflicts with the original certification entry and to let us know the name of the reseller for which this pass-through cert is being created.
    • Use the original company's name if this pass-through is handling a series of components that are a subset of the parent and being sold by the original company.
  • Make - The make assigned to the pass-through component. For the example component "Mycompany Supercard NIC1000", the original make is "Supercard". Since the make is changing from the original certification entry, we will use the new "Ultracard" make here.
  • Model - The model name for the pass-through component. For the example component "Mycompany Supercard NIC1000", the original model is "NIC1000". Since the model is changing from the original certification entry, we will use the new "C165" model here.
  • URL - The reseller's specs URL for the rebranded or subset component. We must have this in order to review any differences that may be present between the parent and the pass-through copy.
Check the checkbox after you have read the pass-through section of the Policy Guide (guide available at link) and click the Create Clone button to create the new cert. The review team will analyze the pass-through certification request's specs URL and notify you if any differences between it and the original component's specs are found. If none are found, they will approve the pass-through cert without additional testing. If differences are found, they will either reject the request with an explanation if the components have major differences, or request supplemental certification (see Section 2.5, “Opening a Supplemental Certification Request from a Hardware Specification Entry”) of the additional hardware to fill in any gaps.

⁠2.11. How Red Hat Creates the Official Test Plan

The next step in the process is the creation of the official test plan, which is the list of hardware that must be tested in order for a system to achieve certification. Our review team reads through the specifications URL, specs document, or list of specs you provide to us to determine which hardware should be considered part of the system model. They do this by categorizing the listed hardware into three different groups:
  • Integrated - Hardware that is part of the motherboard or is always present in the system. Integrated hardware must be tested as part of the certification process, so it will appear on the official test plan.
  • Optional - Hardware that can be ordered along with the model and is considered to be part of it, based on the intended function of the model and on how the hardware is presented in the specs URL. Examples of optional hardware can include NICs, video cards, FC cards, etc. Optional hardware must be tested as part of the certification process, so it will appear on the official test plan. Note, optional hardware was formerly known as "Config to Order" or "CTO" hardware.
  • Additional - Hardware that can be ordered along with the model but is distinct from it, based on the intended function of the model and how the hardware is presented in the specs URL. An example would be a digital camera or a printer on a standard desktop system. Testing is not required for additional hardware, so it does not appear on the official test plan. Note, additional hardware was formerly known as "Aftermarket" or "AM" hardware.
These three designations are usually clear, but there can be confusion between the optional and additional classifications. Our review team looks at several aspects of the hardware to help make their decision. One attribute they check is the intended purpose of the system. For example, if a submitted system is a standard desktop model, a printer would be considered "additional" because printing is not a clear part of the system's core function. If, however, the computer is a desktop model that is sold as a check printing solution, the printer would be classified "optional" and testing would be required as the purpose of the machine is to print checks.
The team also observes the presentation of hardware in the specs / ordering URL. Hardware must be organized in such a way that it is clear to Red Hat and to customers that the hardware is optional or that it is additional. If all the available parts for a specific system are listed the same way on the same page, we would consider all the items to be optional items and require them to be tested. An example would be:
⁠
Integrated and Optional Components

Figure 2.21. Integrated and Optional Components

If one or more of the options were set aside in a separate "Also Available", "Optional Hardware" or "Sold Separately" section, these designations would indicate to us that the hardware is considered to be an accessory rather than part of the model, so we would classify it as "additional" and not require testing. Here is an example of an additional hardware section from an IBM xREF specs page:
⁠
Additional Components

Figure 2.22. Additional Components

The labeling of the section does not have to match our examples, but it should be clear to everyone that this hardware is separate from the model. Please keep in mind that you cannot claim "additional" status for hardware just to exempt it from testing. It must clearly be "extra" to the system (not required to perform the intended task of the system) and it must be presented in a way that clearly indicates its additional status.
Another status that affects testing requirements is unique functionality. If a piece of optional hardware does not provide a unique function, it can be exempted from testing. For example, in the previous section we talked about a list of network cards that was considered optional. If one of those cards did not have a driver in Red Hat Enterprise Linux, as long as there is another card in the list that provides exactly the same functionality and has a Red Hat-provided driver, that card does not need to be tested. In this situation we ask for vendors to clearly label cards with the operating systems that they do support, rather than listing them with those that are unsupported.
Whether or not the hardware is of a Red Hat Enterprise Linux supported class also affects its inclusion in the test plan. There are only a few types of hardware, like Firewire controllers, that fall into this "unsupported class of hardware" category. Firewire is not a supported type of hardware in Red Hat Enterprise Linux so it would not be required to be tested.
After the hardware has been categorized, the integrated and optional hardware is put into the test plan. An excerpt from a newly created test plan can be seen below:
⁠
Example Test Plan

Figure 2.23. Example Test Plan

You can see that this portion of the plan is for 64-bit Red Hat Enterprise Linux and that each line contains the following information:
  • Test name and any descriptive information for the hardware that is covered by the test.
  • "Confirmed" checkbox that is checked by the review team when the test is marked as passing.
  • A drop-down box that identifies which run of the test contains the passing result that should be used for certification purposes. The box contains a dashed line when no passing results file has been selected by the review team. This could be because no passing result has been achieved on the tests that have been submitted, the review team has not yet processed the the results package that contains the passing results, or no results have yet been submitted for this item.
    The dropdown box also contains a selection for leveraging of other test results, which is discussed in the section entitled Section 2.12, “Leveraging of Existing Test Results”.

⁠2.12. Leveraging of Existing Test Results

Leveraging is the reuse of passing test results from hardware in a certified system to cover testing of identical hardware in a new certification request. It can only be used for certain optional items, and these items must be identical. You cannot leverage test results for a new model component with the test results from an old model, no matter how similar they are; the items must be an exact match. Furthermore, leveraging can only be used on tests that your company or its agent has performed.
If you are looking for a way to use tests performed by another vendor, like the vendor of a network card you include in your systems, please see Section 2.9, “Opening a Component Pass-Through Certification Request from a Hardware Specification Entry”.
Hardware that is eligible for leveraging consists of:
  • Audio cards (non-integrated)
  • Optical drives (CD/DVD/Blu-Ray)
  • Storage controllers (non-integrated)
  • Storage devices (Hard drives, SATA/SAS SSD drives, PCIe SSD block storage devices)
  • Network cards (non-integrated)
  • Video cards (non-integrated)
  • Tape drives (non-integrated)
There are two types of leveraging:
  • System Leveraging: This refers to reuse of the successful test results from a certified system for testing of an identical system. If you would like to use leveraging to cover the testing of specific systems, enter the previous test ID in the leverage section of the new test plan. For more information, refer Section 3.5, “Monitoring Certification Progress”.
  • Component Leveraging: This refers to reuse of the successful test results from a certified component for testing of an identical component. If you would like to use leveraging to cover the testing of specific components, enter the previous certification request ID in the leverage section of the new test plan. For more information, refer Section 3.5, “Monitoring Certification Progress”.
Now you know what you need to test, but you will need to set up your test environment before you can begin. We will talk about that in the next section.

⁠2.13. Preparing the Test Environment

Before you can begin running the tests listed in the official test plan, you will need to set up a test environment. The following list provides an overview of all the packages needed. Details about obtaining the packages and configuring the test environment are covered in the subsequent steps.
  1. Red Hat Enterprise Linux Server ISO files in the versions and architectures that you will be certifying on
  2. Optional: The Red Hat Enterprise Linux for Real Time ISO for Red Hat Enterprise Linux 7, Intel 64 and AMD64 if you wish to certify for Red Hat Enterprise Linux Real Time
  3. Systems in need of certification, which we refer to as "systems under test" or SUTs. A SUT can also hold a component that is being certified individually as part of a component certification.
  4. An independent system running Red Hat Enterprise Linux 7 that will function as a test server for the network and kdump tests, as well as provide web-based control (web UI) for executing certification tests. This machine is referred to as the "local test server" or LTS.

    Note

    The Certification Test Suite requires the LTS to run on Red Hat Enterprise Linux 7.x. Please do not attempt to use a Red Hat Enterprise Linux 6 system as the local test server. Red Hat Certification web UI is not available for Red Hat Enterprise Linux 6. It is recommended to setup a LTS on an independent Red Hat Enterprise Linux 7.x system before running the tests. The LTS may be used to run Red Hat Certification web UI and can also act as an endpoint for network and kdump tests before we can begin testing the SUT.
  5. The certification test suite packages:

    • Note

      The redhat-certification and the python-django packages provide Red Hat Certification web UI for testing a system under test (SUT). python-django-bash-completion is automatically installed when python-django is installed.
    • redhat-certification (Available for RHEL 7 only)
    • redhat-certification-backend
    • redhat-certification-hardware
    The dependencies for the certification test suite packages in the architectures you will be certifying for:
    • dt (RHEL 6 and 7, all arches)
    • lmbench (RHEL 6 and 7, all arches)
    • stress (RHEL 6 and 7, all arches)
    • python-django (Required to access Red Hat Certification web UI which is only available for Red Hat Enterprise Linux 7)
    • python-django-bash-completion (Required to access Red Hat Certification web UI which is only available for Red Hat Enterprise Linux 7)
  6. The kernel-debuginfo and kernel-debuginfo-common packages required by your specific version and architecture of Red Hat Enterprise Linux:

    Red Hat Enterprise Linux 6 - 32-bit

    • kernel-debuginfo
    • kernel-debuginfo-common-i686

    Red Hat Enterprise Linux 6 - 64-bit

    • kernel-debuginfo
    • kernel-debuginfo-common-x86_64

    Red Hat Enterprise Linux 7 - 64-bit

    • kernel-debuginfo
    • kernel-debuginfo-common-x86_64
  7. A web server that will host the following items:
    1. Red Hat Enterprise Linux install trees
    2. Red Hat Enterprise Linux kickstart files
    3. redhat-certification test suite and dependencies yum repositories
    4. kernel-debuginfo yum repositories
    5. Optional Real Time yum repositories (install tree)
  8. Additional support equipment for certain tests (see Section A.1, “Hardware Test Procedures” for more information) including:
    1. Appropriate optical media for any Blu-Ray/DVD/CD drive tests
    2. A USB device with the appropriate interface type (USB 2 or USB 3) to test the function of any free USB ports
    3. Speakers (if none are built in) and a microphone (if none is built in) or patch cable to test the function of any sound cards
    4. Expresscards with both USB and PCIe interfaces (this can be one card with both interface types or two cards that do one interface each) for any Expresscard slots
    5. A PC card (formerly called PCMCIA card) to test the function of any PC card slots
    6. Blank tape for any tape drives
We will cover items one through six in this section.
The Red Hat Enterprise Linux Server ISO(s), rhcert packages and all their dependencies, and the kernel debuginfo packages can be downloaded from the Red Hat Customer Portal ( https://access.redhat.com). Log in to the portal using your username and password, then follow the steps below to get all the ISO files and RPM packages you need.
⁠
  1. Download the Red Hat Enterprise Linux Server DVD ISO file: After logging in to the portal, follow the shortcut links below to download the appropriate binary server DVD ISOs. Store these files in a unique, web-accessible location on your web server (see step six below for more details).

    ⁠Red Hat Enterprise Linux ISO Download Links

    Change the "Version" drop-down box to select a different major version / update release of Red Hat Enterprise Linux.
  2. Optionally, download the Red Hat Enterprise Linux for Real Time ISO file. Store these files in a unique, web-accessible location on your web server (see step six below for more details):
    1. After logging in to the portal, follow the shortcut link below to download the appropriate Real Time packages for Red Hat Enterprise Linux 7.

      ⁠Red Hat Enterprise Linux for Real Time Download Link

  3. Download the packages required for certification and their dependencies. Store these files in a unique, web-accessible location on your web server (see step six below for more details).

    ⁠Red Hat Enterprise Linux 6 redhat-certification Package Download Links

    Follow the link on the line above, choose the appropriate architecture directory, and obtain the following packages. Store these files in a unique, web-accessible location on your web server (see step six below for more details).

    Note

    redhat-certification, python-django and python-django-bash-completion which provide Red Hat Certification web UI are not available for Red Hat Enterprise Linux 6. It is recommended to setup a LTS on an independent Red Hat Enterprise Linux 7.x system if certifying for Red Hat Enterprise Linux 6. This LTS may be used to run Red Hat Certification web UI and also serves as an endpoint for network and kdump tests before we begin testing the SUT. Information about setting up a LTS is covered in the subsequent topics.
    • redhat-certification-backend
    • redhat-certification-hardware
    • dt
    • lmbench
    • stress

    ⁠Red Hat Enterprise Linux 7 redhat-certification Package Download Links

    Follow the link on the line above, choose the appropriate architecture directory on your web server and obtain the following packages. Store these files in a unique, web-accessible location on your web server (see step six below for more details).
    • redhat-certification
    • redhat-certification-backend
    • redhat-certification-hardware
    • dt
    • lmbench
    • stress
    • python-django
    • python-django-bash-completion

    Note

    Packages for the aarch64 architecture are available at https://access.redhat.com/downloads/content/282/ver=/rhel---7/7/aarch64/packages.
  4. Download the debuginfo packages for the version and architectures of Red Hat Enterprise Linux you are certifying. Store these files in a unique, web-accessible location on your web server (see step six below for more details):
    1. If you are certifying on Red Hat Enterprise Linux 6, download the debuginfo packages for Red Hat Enterprise Linux 6. This process will need to be performed once per architecture:
      First, find the kernel file(s) on your DVD ISO or install tree. There will only be one kernel file included in each architecture (its name starts with "kernel-"). For example, on Red Hat Enterprise Linux 6.6, Intel 64 and AMD64 architecture, the name of the kernel RPM file is "kernel-2.6.32-504.el6.x86_64.rpm".
      Next, click the Downloads link at the top of the customer portal's main page ( https://access.redhat.com). When the next page loads, click the Red Hat Enterprise Linux link. This will take you to the downloads page. Click the Packages tab, change the Version dropdown box at the top of the page to the correct major version (" 6"), and enter kernel in the filter box.
      You will be presented with a list of search results. Scroll down until you find kernel under the heading of Red Hat Enterprise Linux 6 Server (RPMs) and click it. Make sure the heading does not indicate that the packages are for a beta build. You may need to move off the first page of search results to find the listing for kernel under the proper heading.
      When the kernel page loads, change the Version and Architecture dropdown boxes to match the version and arch of the kernel you identified back in the first step. Finally, click the Show source and debug packages link to see the packages. These are the files you need, sorted by version and architecture:

      Red Hat Enterprise Linux 6 - 32-bit

      • kernel-debuginfo-$VERSION
      • kernel-debuginfo-common-i686-$VERSION

      Red Hat Enterprise Linux 6 - 64-bit

      • kernel-debuginfo-$VERSION
      • kernel-debuginfo-common-x86_64-$VERSION
      Click the names of the appropriate packages to download them. After retrieving the packages for your first architecture, you will need to change the architecture dropdown box and repeat this step for any additional architectures on Red Hat Enterprise Linux 6.
    2. If you are certifying on Red Hat Enterprise Linux 7, download its debuginfo packages. This process will need to be performed once per architecture:
      First, find the kernel file(s) on your DVD ISO or install tree. There will only be one kernel file included in each architecture (its name starts with "kernel-"). For example, on Red Hat Enterprise Linux 7.1, Intel 64 and AMD64 architecture, the name of the kernel RPM file is "kernel-3.10.0-229.el7.x86_64.rpm".
      Next, click the Downloads link at the top of the customer portal's main page ( https://access.redhat.com). When the next page loads, click the Red Hat Enterprise Linux link. This will take you to the downloads page. Click the Packages tab, change the Version dropdown box at the top of the page to the correct major version (" 7"), and enter kernel in the filter box.
      You will be presented with a list of search results. Scroll down until you find kernel under the heading of Red Hat Enterprise Linux 7 Server (RPMs) and click it. Make sure the heading does not indicate that the packages are for a beta build. You may need to move off the first page of search results to find the listing for kernel under the proper heading.
      When the kernel page loads, change the Version and Architecture dropdown boxes to match the version and arch of the kernel you identified back in the first step. Finally, click the Show source and debug packages link to see the packages. These are the files you need, sorted by version and architecture:

      Red Hat Enterprise Linux 7 - 64-bit

      • kernel-debuginfo-$VERSION
      • kernel-debuginfo-common-x86_64-$VERSION
      Click the names of the appropriate packages to download them. After retrieving the packages for your first architecture, you will need to change the architecture dropdown box and repeat this step for any additional architectures on Red Hat Enterprise Linux 7.
  5. Set up a web server to host the Red Hat Enterprise Linux install trees, kickstart files and the rhcert files. This does not need to be a dedicated machine, it can be any web server with sufficient disk space to hold the Red Hat Enterprise Linux install trees that you will be certifying (approximately 3.5 GB per architecture) with as well as the kickstart files and rhcert / debuginfo repositories (about 100 MB). It should not be the same machine as the network and kdump test server due to network capacity requirements (a system serving Red Hat Enterprise Linux bits during an install will not have sufficient bandwidth to function as the network test server).
    1. To set up the Red Hat Enterprise Linux install tree, copy the entire contents of the Red Hat Enterprise Linux ISO to a web-accessible directory on your web server. Be sure to use a naming scheme for your directories that takes architectures into account if you will be certifying multiple architectures. You can either loopback-mount the ISO file you downloaded ( mount -o loop filename.iso /directory/to/mount/iso/file) and copy the files from there, or you can use a burned DVD and copy the files from that.
    2. Copy the optional Red Hat Enterprise Linux for Real Time files from the ISO you downloaded into a unique, web-accessible directory on your web server, using the same mount or burned disc options described above.
    3. Next, copy the kickstart files to their location on the web server. You should use a directory naming scheme to allow for multiple versions and architectures of Red Hat Enterprise Linux. You can read more about creating and editing kickstart files in Section 2.14.1, “Preparing a Kickstart File to Install Red Hat Enterprise Linux 6 and redhat-certification” and Section 2.14.2, “Preparing a Kickstart File to Install Red Hat Enterprise Linux 7 and redhat-certification” of the guide.
    4. Copy redhat-certification, redhat-certification-backend, redhat-certification-hardware and the dependencies, python-django, python-django-bash-completion, dt, lmbench, and stress to a dedicated directory on the web server. Each architecture will need its own repository, so copy the files into directories named for the file architecture and major version of Red Hat Enterprise Linux. For example, "rhcert-rhel6-x86" could be used to hold the files that will be used to certify Red Hat Enterprise Linux 6, x86 architecture, and "rhcert-rhel7-x86_64" could be used to hold the files that will be used to certify Red Hat Enterprise Linux 7, x86_64 architecture.

      Note

      redhat-certification, python-django and python-django-bash-completion packages which provide Red Hat Certification web UI are not available for RHEL 6.
      Use the command createrepo -p . inside each of those directories to build a yum repository from the files. Do not forget the period at the end of the command as that indicates where the repo metadata files are to be stored (the current directory).
    5. Finally, copy the debuginfo packages to their location on the web server. Use the same createrepo -p . command described above to create a yum repository out of the files in the debuginfo directory.
Here is one way you could lay out all the directories on your web server to serve all the necessary files to handle 32-bit and x86_64 64-bit Red Hat Enterprise Linux certification.In this example, we are setting up an environment to certify Red Hat Enterprise Linux 6.6 and 6.7, 32-bit and 64-bit (x86_64); Red Hat Enterprise Linux 7.1, 64-bit (x86_64); Red Hat Enterprise Linux 7.2, 64-bit (x86_64); and Red Hat Enterprise Linux for Real Time 7.1:

Red Hat Enterprise Linux 6

  • /var/www/html/rhel6/6.6/x86 and /x86_64 - The Red Hat Enterprise Linux 6.6 install trees copied from the ISO or other location
  • /var/www/html/rhel6/6.7/x86 and /x86_64 - The Red Hat Enterprise Linux 6.7 install trees copied from the ISO or other location
  • /var/www/html/rhel6/ks - Individual kickstart files capable of installing the update release(s) of Red Hat Enterprise Linux 6 on which you will certify your systems. You can have multiple files here, one for each update release and architecture of Red Hat Enterprise Linux 6.
  • /var/www/html/rhel6/rhcert-x86 - Yum repository containing the redhat-certification packages and their dependencies. These files can be used by all update releases of Red Hat Enterprise Linux 6 with arch i386/i686
  • /var/www/html/rhel6/rhcert-x86_64 - Yum repository containing the redhat-certification packages and their dependencies. These files can be used by all update releases of Red Hat Enterprise Linux 6 with arch x86_64
  • /var/www/html/rhel6/rhel6.6-x86-debuginfo - Yum repository containing debuginfo packages for the Red Hat Enterprise Linux 6.6 32-bit kernel
  • /var/www/html/rhel6/rhel6.6-x86_64-debuginfo - Yum repository containing debuginfo packages for the Red Hat Enterprise Linux 6.6 x86_64 kernel
  • /var/www/html/rhel6/rhel6.7-x86-debuginfo - Yum repository containing debuginfo packages for the Red Hat Enterprise Linux 6.7 32-bit kernel
  • /var/www/html/rhel6/rhel6.7-x86_64-debuginfo - Yum repository containing debuginfo packages for the Red Hat Enterprise Linux 6.7 x86_64 kernel

Red Hat Enterprise Linux 7

  • /var/www/html/rhel7/7.1/x86_64 - The Red Hat Enterprise Linux 7.1 install trees copied from the ISO or other location
  • /var/www/html/rhel7/7.2/x86_64 - The Red Hat Enterprise Linux 7.2 install trees copied from the ISO or other location
  • /var/www/html/rhel7/ks - Individual kickstart files capable of installing the update release(s) of Red Hat Enterprise Linux 7 on which you will certify your systems. You can have multiple files here, one for each update release and architecture of Red Hat Enterprise Linux 7.
  • /var/www/html/rhel7/rhcert-x86_64 - Yum repository containing the redhat-certification packages and their dependencies. These files can be used by all update releases of Red Hat Enterprise Linux 7 with arch x86_64
  • /var/www/html/rhel7/rhel7.1-x86_64-debuginfo - Yum repository containing debuginfo packages for the Red Hat Enterprise Linux 7.1 x86_64 kernel
  • /var/www/html/rhel7/rhel7.2-x86_64-debuginfo - Yum repository containing debuginfo packages for the Red Hat Enterprise Linux 7.2 x86_64 kernel
  • /var/www/html/realtime/7.1 - Yum repository containing optional Real Time 7.1 packages
In a later section, we will perform an automated install of Red Hat Enterprise Linux and rhcert on the network test server using the web server and kickstart files we created in this section.

⁠2.14. Preparing Kickstart Files

The simplest way to install an LTS or a SUT ready to undergo testing is to use a kickstart file. The two sections below contain information on the use of kickstart files to install systems based on either Red Hat Enterprise Linux 6 or 7.
You can learn more about Red Hat Enterprise Linux 6 kickstart files in Chapter 32 of the Red Hat Enterprise Linux 6 Installation Guide entitled Kickstart Installations.
You can learn more about Red Hat Enterprise Linux 7 kickstart files in Chapter 23 of the Red Hat Enterprise Linux 7 Installation Guide entitled Kickstart Installations.

⁠2.14.1. Preparing a Kickstart File to Install Red Hat Enterprise Linux 6 and redhat-certification

We have prepared example kickstart files that install a Red Hat Enterprise Linux 6 hardware certification environment on a SUT and made them available here on our FTP server:
The files of interest are rhel6-x86_64-rhcert.ks (Red Hat Enterprise Linux 6, x86_64 architecture) and rhel6-i386-rhcert.ks (Red Hat Enterprise Linux 6, i386 architecture), which install a Red Hat Enterprise Linux 6 system that is ready to undergo certification. These files can be duplicated, renamed, and edited to enable you to install different update releases of Red Hat Enterprise Linux 6 (rhel6.6-i386-rhcert.ks, rhel6.6-x86_64-rhcert.ks, rhel6.7-x86_64-rhcert.ks, and so on) in your test environment.

Important

The example kickstart files will delete all data on all attached drives by default. Do not use them without modification if you wish to keep any data that is on the SUT you are installing.
To use a kickstart file to install your Red Hat Enterprise Linux 6 systems under test, follow the directions in the Installation Guide referenced above to prepare a kickstart server, then customize the example files to match your environment and copy them to your server. The kickstart files we provide install Red Hat Enterprise Linux 6 with these options:
  1. Install the OS in the English language (rhcert only works with English)
  2. Choose a US keyboard
  3. Install a new instance of Red Hat Enterprise Linux Server (don't upgrade an existing installation)
  4. Create a custom partition layout that meets the requirements of certification:
    1. Delete any existing partitions
    2. Create a 500MB " /boot" partition of type ext4. If you have multiple drives in the system, place this on the first drive
    3. Create an appropriately sized swap partition of type swap. This should also be on the first drive. NOTE: The installer automatically sizes the partition based on the amount of installed RAM and whether or not the system needs to be able to hibernate (laptops). Please see the Red Hat Knowledgebase article at https://access.redhat.com/site/solutions/15244 for more information on appropriate swap file sizing.
    4. Create a " /" (root) partition of type ext4 that uses the rest of the first drive. Choose the "Fill to maximum allowable size" option to use all the available space
    5. Ensure that any other drives in the system are blank (no partitions)
  5. Use the GRUB boot loader on the first drive (usually /dev/sda, this is the default setting)
  6. Set all network devices to DHCP addresses, including those that don't come up at boot time.
  7. Use the time zone of your choice (you can change this to whatever you like in the kickstart file)
  8. Use a root password of redhat by default (you can change this to whatever you like in the kickstart file)
  9. Create a non-root user named "certuser" with a password of "redhat" that can be used to log in to the GUI.
  10. Install the necessary packages to run rhcert (see the kickstart files for details).

    Note

    redhat-certification, python-django and python-django-bash-completion packages which provide Red Hat Certification web UI are not available for Red Hat Enterprise Linux 6. It is recommended to setup a RHEL 7.x local test server later if certifying for RHEL 6. The local test server may be used to run Red Hat Certification web UI and can also act as an endpoint for as an endpoint for network and kdump tests before we can begin testing the SUT. Information about configuring a local test server is covered in the subsequent topics.
  11. Disable the firewall
  12. Start the rhcertd service automatically at boot time
  13. Optionally pull the pre-built guest files down from the Red Hat FTP server at install time and store them locally for use by systems under test (see Section 2.16.1, “Using Locally-Hosted Pre-Built Guest Files” for more information)
We explain how to connect the necessary hardware to the SUT and install it using the kickstart file in Section 2.15, “Configuring the System Under Test”.

⁠2.14.2. Preparing a Kickstart File to Install Red Hat Enterprise Linux 7 and redhat-certification

We have prepared example kickstart files that install a Red Hat Enterprise Linux 7 hardware certification environment on a SUT or LTS and made them available here on our FTP server. We recommend using the example kickstart file to install a RHEL 7.x local test server especially if certifying for Red Hat Enterprise Linux 6. The RHEL 7.x local test server may be used to run Red Hat Certification web UI and can also act as an endpoint for network and kdump tests before we can begin testing the SUT. Information about configuring a local test server is covered in the subsequent topics.
The file of interest is rhel7-x86_64-rhcert.ks, which will install a Red Hat Enterprise Linux 7 system that is ready to undergo certification as a SUT or act as an LTS. These files can be duplicated, renamed, and edited to enable you to install different update releases of Red Hat Enterprise Linux 7 (rhel7.0-x86_64-rhcert.ks, rhel7.1-x86_64-rhcert.ks, rhel7.2-x86_64-rhcert.ks, and so on) in your test environment.

Important

The example kickstart files will delete all data on all attached drives by default. Do not use them without modification if you wish to keep any data that is on the SUT or LTS you are installing.
To use a kickstart file to install your Red Hat Enterprise Linux 7 systems, follow the directions in the Installation Guide referenced above to prepare a kickstart server, customize the example files to match your environment and copy them to your server. The kickstart files we provide install Red Hat Enterprise Linux 7 with these options:
  1. Install the OS in the English language (rhcert only works with English)
  2. Choose a US keyboard
  3. Install a new instance of Red Hat Enterprise Linux Server (don't upgrade an existing installation)
  4. Create a custom partition layout that meets the requirements of certification:
    1. Delete any existing partitions
    2. Create a 200MB " /boot/efi" partition if UEFI mode is detected
    3. Create a 500MB " /boot" partition of type xfs. If you have multiple drives in the system, place this on the first drive
    4. Create an appropriately sized swap partition of type swap. This should also be on the first drive. NOTE: The installer automatically sizes the partition based on the amount of installed RAM and whether or not the system needs to be able to hibernate (laptops). Please see the Red Hat Knowledgebase article at https://access.redhat.com/site/solutions/15244 for more information on appropriate swap file sizing.
    5. Create a " /" (root) partition of type xfs that uses the rest of the first drive. Choose the "Fill to maximum allowable size" option to use all the available space
    6. Ensure that any other drives in the system are blank (no partitions)
  5. Use the GRUB boot loader on the first drive (usually /dev/sda, this is the default setting)
  6. Use the time zone of your choice (you can change this to whatever you like in the kickstart file)
  7. Use a root password of redhat by default (you can change this to whatever you like in the kickstart file)
  8. Create a non-root user named "certuser" with a password of "redhat" that can be used to log in to the GUI.
  9. Install the necessary packages to run rhcert (see the kickstart files for details)
  10. Disable the firewall
  11. Prevent the firstboot and help screens from appearing
  12. Start the rhcertd service automatically at boot time
  13. Optionally install the Red Hat Enterprise Linux for Real Time packages
  14. Optionally pull the pre-built guest files down from the Red Hat FTP server at install time and store them locally. We recommend doing this on your LTS to save time when testing virtualization capabilities of your SUTs (see Section 2.16.1, “Using Locally-Hosted Pre-Built Guest Files” for more information).
We explain how to connect the necessary hardware to the SUT and install it using the kickstart file in Section 2.15, “Configuring the System Under Test”.

⁠2.15. Configuring the System Under Test

Everything listed in the official test plan must be tested. Depending on the options available, this may require you to install and remove various pieces of hardware to run the same test multiple times. A system with multiple video card options is an example of this scenario, where multiple devices of the same class must be tested one at a time. In other cases you may be able to install multiple devices of the same kind at the same time and run the tests in the same test run. An example of this would be a system with enough drive bays and slots to hold two different SATA controllers and their associated drives. The order in which you install and test the components listed in the official test plan is up to you, we just need to receive passing results on all tests before we can post the system as certified.
We have created network and storage diagrams to help you connect your SUT to the hwcert test server and any required storage devices:
⁠

Figure 2.24. Connecting a Server

This example server offers two identical 1Gb Ethernet LOM interfaces (LAN-on-motherboard) and one 10Gb Ethernet network card that is classified as optional. All three of these cards offer FibreChannel over Ethernet (FCoE) and iSCSI support via hardware drivers. It has an optional Infiniband card that is listed in the specifications document as supporting both storage and network modes, and it also has an optional FibreChannel card that is advertised for use with external storage.
Note that none of the switches shown in this diagram are mandatory. Interfaces may be directly connected to the appropriate storage device or network device as required, but we recommend using switches where convenient as it simplifies device connections.
The Ethernet functionality of both 1Gb NICs needs to be tested as they are classified as integrated hardware. The 10Gb NIC also needs to be tested as it is classified as optional and is the only device offered that provides 10Gb connectivity.
FibreChannel over Ethernet (FCoE) storage testing is required on all three Ethernet NICs as they all support hardware-based FCoE. If the system's FCoE support was software-only, no testing would be required. Note that the same FCoE storage device can be used for both the 1GbE and 10GbE testing, provided it can connect at both speeds. The same storage device can also be used for FCoE and native FC testing if it supports both connection types.
Both storage and network testing are required for the Infiniband interface on this system, because the specifications document claims support for both storage and network connections.
Native FibreChannel (FC) storage testing is required as the system's specifications document claims support for external FC storage devices. If the FC HBA were intended for use with internal storage, that would be tested instead. If the HBA could connect to internal and external storage, only one would need to be tested. The same storage device can be used for FCoE and native FC testing if it supports both connection types.
iSCSI storage testing is required on all three Ethernet NICs as they all support hardware-based iSCSI. If the system's iSCSI support was software-only, testing would also be required. The same iSCSI storage device can be used for both the 1GbE and 10GbE testing, provided it can connect at both speeds.
10Gb Ethernet was much more expensive than 1GbE at the time this diagram was created, so we have shown the use of a dedicated 10Gb Ethernet switch in this example. You could eliminate the 1Gb Ethernet devices inside the dotted-line box and connect all Ethernet devices through the 10Gb switch if:
  1. You have sufficient ports on the 10GbE switch to handle all Ethernet connections
  2. The 10GbE switch is capable of connecting at both 1Gb and 10Gb speeds
⁠

Figure 2.25. Connecting a Workstation

This example workstation has two identical 1Gb Ethernet LOM interfaces (LAN-on-motherboard) and no optional network devices. Both 1GbE cards must be connected and tested as they are classified as integrated hardware.
There can be multiple network devices between the SUT and the test server, so long as the speed of each connection is equal to or greater than the native speed of the interface(s) on the SUT. This rule applies when testing any kind of network device.
Best results will be obtained with the fewest number of devices between the systems, as this allows you to better control the amount of non-test traffic on the network. Too much extra traffic can lead to slower than expected test results, ultimately leading to a failed test. We recommend connecting the test server and the SUT to the same switch whenever possible for this reason. Direct connections between wired devices are also allowed, but using a switch will generally save you time and effort.
⁠

Figure 2.26. Connecting a Laptop

This example laptop system has 802.11n wireless Ethernet and a 1Gb Ethernet LOM interface (LAN-on-motherboard). There are no other available network options for this system. Both devices must be connected and tested as they are classified as integrated hardware.
A wireless router can take the place of a separate wireless access point and Ethernet switch for testing wireless devices. You may also use the wired Ethernet switch component of a wireless router when testing wired Ethernet devices. When selecting your network equipment, remember that the speed of all wired and wireless network connections throughout the test environment must be greater than or equal to the native speeds of the SUT.
A switch is not mandatory for wired network testing (direct connections can be made if you desire) but an intermediate network device like a wireless router or wireless access point is required for wireless testing as we do not support testing in Ad-Hoc mode.
Once you are comfortable with the hardware configuration of your system under test (SUT), install the system by booting Red Hat Enterprise Linux using your preferred installation media (PXE/DVD/CD/USB key, etc.). When the boot menu appears, edit the configuration and add the appropriate kickstart file to the vmlinuz line of the boot entry using the ks= option. Here are examples from Red Hat Enterprise Linux 7.2 EFI boot and BIOS boot, and also Red Hat Enterprise Linux 6.7 BIOS boot (these examples are each on a single line; they may wrap due to length). Remember, the only thing you're adding here is the ks= option. The rest of the line is there already: 
linuxefi /images/pxeboot/vmlinuz inst.stage2=hd:LABEL=RHEL-7.2\x20x86_64 ks=http://myserver.mydomain.com/rhel7/ks/rhel7.2-x86_64-rhcert.ks

vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=RHEL-7.1\x20x86_64 ks=http://myserver.mydomain.com/rhel7/ks/rhel7.1-x86_64-rhcert.ks

vmlinuz initrd=initrd.img ks=http://myserver.mydomain.com/rhel6/ks/rhel6.8-x86_64-rhcert.ks
Replace the example shown here with your own path and kickstart file for Red Hat Enterprise Linux 7.x EFI or BIOS boot, or Red Hat Enterprise Linux 6.x BIOS boot.
The installation will complete unattended and you will be left with a fully configured Red Hat Enterprise Linux system that is ready to be certified. We will explain the actual process of certification in the next section.
If you opted to not use the kickstart file and decided to install files manually, two more steps must be performed to enable communication between the SUT and the test server:
  1. Activate the test server with the command rhcertd start.
    To make this setting persist across reboots, run the command chkconfig rhcertd on.
  2. Disable the firewall with the command systemctl stop firewalld in Red Hat Enterprise Linux 7, or service iptables stop in Red Hat Enterprise Linux 6.
    To make this setting persist across reboots, run the command systemctl disable firewalld in Red Hat Enterprise Linux 7, or chkconfig iptables off in Red Hat Enterprise Linux 6.

⁠2.16. Configuring the Local Test Server

We will need a Red Hat Enterprise Linux 7-based local test server (LTS) that provides a web interface for managing certifications and also acts as an endpoint for network and kdump tests before we can begin testing the SUT. The web interface and endpoint functions may be performed by the same system, or the web interface can run on one system, and the network and kdump test function may be performed by another. For simplicity, we will be using one system to handle all these functions in these directions.
The system that functions as the LTS should be dedicated to the task. The machine does not need especially fast processors or large amounts of RAM, but its network connections must be at least as fast as those on the SUT. It is recommended to locate the system as few hops away from the test systems on your network as possible; connecting it to the same network switch as the test systems is ideal. This is to ensure that network congestion between the SUT and LTS does not cause network test failures. The server's processor architecture does not need to match that of the SUT, so you can use any available machine that meets the network speed criteria.

Note

The LTS stores test results from the SUTs in preparation for upload to the Red Hat Hardware Catalog. Please see the section entitled Section 3.4, “Submitting Results” for more information on submitting results from the local test server.
Once you are comfortable with the hardware configuration of your LTS, install the system by booting Red Hat Enterprise Linux 7.x using your preferred installation media (PXE/DVD/CD/USB key, etc.). When the boot menu appears, edit the configuration and point the system at the kickstart file you set up in section Section 2.14.2, “Preparing a Kickstart File to Install Red Hat Enterprise Linux 7 and redhat-certification” by adding it to the vmlinuz line of the boot entry. Here are examples from Red Hat Enterprise Linux 7.2 EFI boot and BIOS boot (these examples are each on a single line; they may wrap due to length): 
linuxefi /images/pxeboot/vmlinuz inst.stage2=hd:LABEL=RHEL-7.2\x20x86_64 ks=http://myserver.mydomain.com/rhel7/ks/rhel7.2-x86_64-rhcert.ks

vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=RHEL-7.1\x20x86_64 ks=http://myserver.mydomain.com/rhel7/ks/rhel7.1-x86_64-rhcert.ks
Replace the example shown here with your own path and kickstart file for the Red Hat Enterprise Linux 7-based system.
The installation will complete unattended and you will be left with a fully configured Red Hat Enterprise Linux 7 system that is ready to be used as a local test server.
If you opted to not use the kickstart file and decided to install files manually, two more steps must be performed to turn the system you just installed into a local test server:
  1. Activate the test server service with the command rhcertd start.
    To make this setting persist across reboots, run the command chkconfig rhcertd on.
  2. Disable the firewall with the command systemctl stop firewalld.
    To make this setting persist across reboots, run the command systemctl disable firewalld.
The local test server is now ready to perform the network and kdump tests and provide a web interface (Red Hat Certification web UI) for controlling certification activites.

⁠2.16.1. Using Locally-Hosted Pre-Built Guest Files

The pre-built, full-virt guest images contain everything you need in order to run the fv_* tests on Red Hat Enterprise Linux 6 or 7 so you do not have to manually install a guest as part of the test procedure. The preconfigured images contain a Red Hat Enterprise Linux guest with access to the test suite as well as the logic necessary to pass test results from the guest out to the base system so that all test results can be delivered in a single results package.

Note

If you use our example kickstart files and uncomment the pre-built guest file sections when installing your local test server (LTS), all the work described in this section will be done for you at install time.
The test suite will look locally on the SUT for the guest images whenever an fv_* test is launched. If they can't be found there, it will attempt to download them from the LTS. If they can't be found there either, it will retrieve the images from the partners.redhat.com FTP site. Storing guest files on your LTS is useful as local retrieval is much faster than pulling hundreds of megabytes worth of data from the Red Hat FTP servers every time you need to certify a system.
The files can be found here:
If you did not use our kickstart files to install your local test server, this is how you use the above information to configure your LTS to host the FV guest images for Red Hat Enterprise Linux 7 and/or 6:
  1. Set up a test server as explained in Section 2.16, “Configuring the Local Test Server”.
  2. If you wish to certify for Red Hat Enterprise Linux 7
    1. Create a directory on the LTS called /var/www/rhcert/store/transfer/fv-images/RHEL7
    2. Copy these files from the Red Hat Enterprise Linux 7 FTP site above into the local directory:
      1. hwcertData.img.tar.bz2 (Results transfer package from guest to host)
      2. hwcert-x86_64.xml.tar.bz2 (Full-virt guest configuration file for x86_64)
      3. hwcert-x86_64.img.tar.bz2 (Full-virt KVM guest image for x86_64)
  3. If you wish to certify for Red Hat Enterprise Linux 6
    1. Create a directory on the LTS called /var/www/rhcert/store/transfer/fv-images/RHEL6
    2. Copy these files from the Red Hat Enterprise Linux 6 FTP site above into the local directory:
      1. hwcertData.img.tar.bz2 (Results transfer package from guest to host)
      2. hwcert-x86_64.xml.tar.bz2 (Full-virt guest configuration file for x86_64)
      3. hwcert-x86_64.img.tar.bz2 (Full-virt KVM guest image for x86_64)

⁠Chapter 3. Testing Hardware

3.1. Scheduling and Running Tests with the Red Hat Certification Tool
3.1.1. Adding a Product to the Test Server from the Red Hat Certification Catalog 3.1.2. Adding a Product to the Test Server's "Sandbox" section 3.1.3. Selecting and Running Tests
3.2. Certifying for Red Hat Enterprise Linux
3.2.1. Testing a Server 3.2.2. Testing a Desktop/Workstation 3.2.3. Testing a Laptop 3.2.4. Testing a Component
3.3. Layered Product Certifications
3.3.1. Certifying for Red Hat OpenStack Platform Compute 3.3.2. Certifying for Red Hat Storage Server 3.3.3. Certifying for Red Hat Enterprise Linux for Real Time
3.4. Submitting Results
3.4.1. Automatic Upload from the Test Server 3.4.2. Manual Submission
3.5. Monitoring Certification Progress 3.6. Completing Certifications

⁠3.1. Scheduling and Running Tests with the Red Hat Certification Tool

The Red Hat Certification tool moves the majority of functionality from the system under test (SUT) to a web interface on the local test server (LTS). To use the web interface to schedule testing of systems or components, follow these steps:

⁠3.1.1. Adding a Product to the Test Server from the Red Hat Certification Catalog

Our preferred method for adding a certification to the LTS is to use the certification request you created on the Red Hat Certification Catalog as the source of information. This gives you the benefit of simplified product creation and results uploading, and it also enables automatic modification of the local test plan to include only those items required to complete certification. If for some reason you cannot link to the Catalog or you are creating "scratch" test runs never intended for submission, see the next section for the method you should use to create product entries. To begin, open a web browser and go to the hostname or IP address of the LTS. Follow these steps once the page loads:
  1. We first need to log in to the site using the Red Hat Customer Portal SSO credentials discussed in Section 1.4, “Before You Begin”. Click the login button at the top of the page.
  2. Enter your Customer Portal username and password in the appropriate fields and then click the Log In to log in to the site. After logging in successfully you will see your Customer Portal username in the top right-hand corner of the window.
  3. Click the Download Products button under the Products section of the page.
  4. In the Add Products section, select the Hardware radio button on the Program line and click the Next button.
  5. Click the checkbox next to the system(s) you will be testing and then click the Add Selected Products button to add them to the local test server. The catalog will automatically provide the LTS with all the certifications that are associated with the products you selected and you will be returned to the homepage of the LTS when complete.
  6. The product and certification(s) are ready, and now we need to add a system to the certification. Click on the hostname of your server in the upper right-hand corner of the page. Enter the hostname or the IP address of the SUT in the Register a System text box that appears. Click Add to add the system. After a brief pause, the SUT will appear under the Registered Systems heading at the top of the page. Should the command appear to complete without the system appearing in the list of registered systems, click the refresh button in your browser.
  7. Return to the home page of the LTS by clicking the Red Hat Certification graphic at the upper left-hand corner of the page. Go back to the product we are certifying by clicking the product name, click the appropriate Red Hat software listed in the Certification column, then click the "Testing" menu item on the left-hand side of the screen. Click the + System button that appears. You will see the SUT that you just registered, plus any other systems registered earlier. Click the radio button next to the proper SUT and click the Test button to associate it with the certification. You are now ready to begin testing.

⁠3.1.2. Adding a Product to the Test Server's "Sandbox" section

An alternative method for adding a certification to the LTS is to do it locally in the "sandbox" section. The use of the sandbox area does not require network access to the Catalog, so it's the ideal method for any "scratch" certifications not intended to be uploaded or for when your test server is unable to reach the Catalog due to network security or other reasons. To begin, open a web browser and go to the hostname or IP address of the LTS. Follow these steps once the page loads:
  1. Click the Create Local Product button at the bottom of the page
  2. In the Add Local Product section, select the Hardware radio button on the Program line. Click Next to continue.
  3. Enter the vendor, make, and name information for your system or component in the fields provided. In our hypothetical example, "Mycompany" would be the vendor, "Ultraserver" would be the make, and "X16" would be the name of the system. Click Add Product to continue.
  4. Now we need to add a certification to the product. Click on the name of the product you just created. When the next page loads, click the + Sandbox button. Choose the Red Hat product you wish to certify on from the Certification dropdown box and click the Next button. For this example, we'll select Red Hat Enterprise Linux 7.2.
  5. The product and certification are ready, and now we need to add a system to the certification. Click on the hostname of your server in the upper right-hand corner of the page. Enter the hostname or the IP address of the SUT in the Register a System text box that appears. Click Add to add the system. After a brief pause, the SUT will appear under the Registered Systems heading at the top of the page. Should the command appear to complete without the system appearing in the list of registered systems, click the refresh button in your browser.
  6. Return to the home page of the LTS by clicking the Red Hat Certification graphic at the upper left-hand corner of the page. Go back to the product we are certifying by clicking the product name, click the appropriate Red Hat software listed in the Certification column, then click the + System button. You will see the SUT that you just registered, plus any other systems registered earlier. Click the radio button next to the proper SUT and click the Test button to associate it with the certification. You are now ready to begin testing.

⁠3.1.3. Selecting and Running Tests

Browse to the list of available tests for your product to get started. Open a web browser and go to the hostname or IP address of your test server. Click the correct product name, the name of the Red Hat software you are certifying on, and then click the Continue Testing button to get to the list of tests. On this page, you can see all the available tests and results for all the tests that have been run as part of the current results file. The example below shows a freshly registered system with no results available to display:
⁠
Blank Test Results Page

Figure 3.1. Blank Test Results Page

Choose the tests you wish to run by clicking the checkbox on the same line as the test, and then click the Run Selected button to begin the test. The previous certification page will appear, and you can follow the test status by watching the Log field. The Status field will report a finished status when this test run completes.
Some tests have an interactive label next to the checkbox. These tests require user interaction in order to be completed and cannot run unattended. If you select one or more interactive tests, after clicking the Run Selected button you will be presented with instructions on how to complete the test(s).
The results page will show PASS results for passing tests and FAIL for those that fail. You can see passing test results in the in-progress certification example below. The profiler and storage test results have been expanded to show more detailed test results.
⁠
In-Progress Test Results Page

Figure 3.2. In-Progress Test Results Page

⁠3.2. Certifying for Red Hat Enterprise Linux

In this section, we will describe the tests that are required to certify systems and components for use with Red Hat Enterprise Linux. They will be introduced in the context of certifying a server, a desktop/workstation, a laptop, and a component.

⁠3.2.1. Testing a Server

Most of the hardware found on server systems can be found on other types of computers, but servers tend to have larger amounts of common components like disks, RAM, and CPUs. We may also see a tape drive, something that is generally found only on servers. We will begin walking through all the hardware certification tests, starting with the items that are most commonly associated with servers. You can find detailed information on all the tests in Section A.1, “Hardware Test Procedures” if you want to learn more. Remember, even though we are only covering a few tests in this example, you will need to submit results for everything listed in the official test plan, regardless of what type of computer you are testing.

⁠RAM

System RAM is tested with the memory test. It does not cover things like USB flash memory, SSD drives, proprietary flash caches or any other type of memory device, just the RAM as used by the kernel's virtual memory (VM) subsystem. The Policy Guide explains how much memory should be used when performing the memory test.

⁠Virtualized Guest Tests

On all virt-capable architectures of Red Hat Enterprise Linux 6 and Red Hat Enterprise Linux 7, test plans generated on virt-capable machines will include a number of tests beginning with "fv_":
  • fv_core - Tests a pre-built Red Hat Enterprise Linux guest's vCPU
  • fv_memory - Tests a pre-built Red Hat Enterprise Linux guest's memory
  • fv_network - Tests a pre-built Red Hat Enterprise Linux guest's network connection (optional, for SR-IOV-capable devices only)
  • fv_storage - Tests a pre-built Red Hat Enterprise Linux 5 guest's storage device (optional, for SR-IOV-capable devices only)
These are special tests that are designed to run on fully-virtualized (FV) KVM guests. The actual test portion of the scripts is identical to that of our regular core, memory, network and storage tests, but the fv_ scripts have additional code in them that downloads a pre-built FV guest from Red Hat (if it is not already present on the SUT or your network test server), launches it, and then runs the tests in the guest. Please see the appropriate section in the server explanation (this section) and Section 3.2.2, “Testing a Desktop/Workstation” for information on the tests that are run by these scripts.

⁠CPU

The CPU is obviously used in all testing, but there are a few tests in rhcert dedicated to analyzing specific attributes of the CPU itself. These are the core, cpuscaling and profiler tests. We will go through them in that order.
The core test examines the system's CPUs and ensures that they are capable of functioning properly under heavy loads. The cpuscaling test exercises the CPUs at varying frequencies to make sure that they can increase and decrease clock speed as required by the compute load. The profiler test examines the CPUs' ability to run the oprofile monitoring tool. It is a low-overhead performance monitoring tool that is used to uncover performance related issues and is extensively used by large shops with large Red Hat Enterprise Linux deployments. The Policy Guide tells you how to choose the proper CPUs for testing, in the event that the system ships with multiple CPU options.

⁠fencing

The optional fencing test is designed to test the ability of a system to be powered cycled remotely, either by the system's baseboard management controller (BMC) or an external fencing device like an APC or WTI power device. Fencing is a process that most commonly occurs when a system is a member of a cluster. If the system is determined by the other members of the cluster to be operating incorrectly it can be fenced, or forcibly rebooted, to attempt to restore it to a normal working state.

⁠Info

The info test is different from the other tests in the certification test suite. It is not testing a specific component or testing a particular system function, its job is to gather information about the operating system and data on all the installed hardware any time a test is executed. We use the data in the info test to confirm that only approved kernel modules are being used and that the hardware being tested matches the hardware listed in the official test plan. It us also useful to us when helping to debug failed tests. info automatically runs any time the test suite is executed and it is a required part of all results packages.

⁠kdump

The kdump test performs two tests to ensure that the system can capture a vmcore when a system crash occurs. The vmcore file generated by kdump is an important part of the crash debugging process performed by our support team, so it is important to ensure that a system can create one in the event of a crash. It will save the file locally and also to an NFS server (the kdump/ network server) to test the most common methods of core file access. The tests are always run last by rhcert because of the reboots that occur.

⁠Tape Drive

The tape test covers testing of tape drive devices. It can test robotic tape libraries as well, but testing of the robot itself is outside its scope. The test is a simple rewind, write and compare.

⁠3.2.2. Testing a Desktop/Workstation

Desktop and workstation systems have a few items, like audio cards, that are not typically found in servers, but the rest of the hardware is virtually identical. The most common differences are less RAM, fewer disk options, fewer processors and a more robust video card. Full details on all the test procedures can be found in Section A.1, “Hardware Test Procedures”. Remember, even though we are only covering a few tests in this example, you will need to submit results for everything listed in the official test plan, regardless of what type of computer you are testing.

⁠USB Ports

Virtually every modern computer contains USB2 and/or USB3 ports. We use a simple plug/unplug action in the USB2 and USB3 tests to make sure that the system recognizes when hardware is plugged into and removed from every available port on the system. We know that you are probably using one or two USB ports for a keyboard/mouse/KVM during the test, so we allow you to specify the number of ports that are available at the start of the test. Just make sure to subtract any that are in use when you are asked for the number. You will need to test each port with the appropriate kind of USB device (USB2 devices for USB2 ports, and USB3 devices for USB3 ports).

⁠Blu-Ray, DVD, and CD Drives

The bluray, dvd, and cd tests test the rewrite, write and read capabilities of the three different types of optical media. The rules of hardware certification require only one of these tests per set of drives that is offered with a controller. You run a test on any drive that has the most advanced feature set of all the drives available for each controller. See Section A.1.10, “bluray” for more information on how to choose the proper drive and the proper test.

⁠Sound Cards

The audio test covers both integrated and removable sound cards as well as sound delivered by HDMI or DisplayPort connections. It tests these devices with a simultaneous playback and record when a microphone is available, or just playback when there is no microphone (HDMI and DisplayPort). For such a simple test, it can take a fair amount of configuration testing to achieve a passing result. We recommend reading the detailed directions in Section A.1.8, “audio” to learn how to set everything up for a successful test.

⁠Network Cards

The 1GigEthernet test tests gigabit Ethernet devices it detects with a variety of throughput and ping tests. You need to have the network server running before you start the test and specify it by IP or DNS name when prompted. In addition to the test for gigabit Ethernet cards, there are also tests for 10 gigabit Ethernet ( 10GigEthernet) and 100 megabit Ethernet ( 100MegEthernet) that will be planned automatically if those devices are detected. If you are testing a wireless network card, see Section A.1.26, “network” for configuration requirements for those cards.

⁠Video Cards

The video test covers all video hardware, integrated or add-in, and involves hardware detection, X11 configuration file creation and a basic X11 server performance test. We recommend that you connect your monitor directly to the system (avoid using a KVM) if you encounter trouble with monitor detection during the test.

⁠IDE, SATA, SAS, SCSI, SSD, PCIe SSD Block Devices and Media Cards

The storage test performs a variety of read and write tests on all kinds of storage devices. The same test script is run regardless of drive type. The number of storage runs and the devices required to be tested during each run is dictated by our "test all code paths" requirement, which requires testing of all the different storage drivers that can be used by the storage options available with a system. We recommend reading Section A.1.31, “storage” for more information.

⁠3.2.3. Testing a Laptop

Laptop systems have a few devices that generally are not found in other systems. These include built-in screens, PC Card sockets, ExpressCard sockets, batteries and wireless network cards. Full details on all the test procedures can be found in Section A.1, “Hardware Test Procedures”. Remember, even though we are only covering a few tests in this example, you will need to submit results for everything listed in the official test plan, regardless of what type of computer you are testing.

⁠Built-in Battery

Two of the rhcert tests are targeted at systems with a built-in power source. They are the suspend test and the battery test. The suspend test tests entering and leaving S3 suspend (suspend to RAM) and S4 hibernate (suspend to disk) states. It enters these states with the pm-suspend command and then prompts you to manually trigger sleep and hibernate using the keyboard if those keys are present. Note: This test will be scheduled once per run on laptop systems. This is to ensure that all hardware is available and functional after resuming.
Battery tests whether the integrated battery is usable as the system's primary power source and also confirms that it can be charged via the AC adapter. The test is only run for systems with built-in batteries that are designed to power the entire system. It is not designed to test UPS-style backup batteries or batteries on storage controllers. You will be prompted to unplug and plug in the AC-adapter during the test.

⁠Built-in Screen

The lid test is used on systems with an integrated screen to ensure that the backlight automatically turns off whenever the lid (screen) is closed. It is a manual test that relies on the tester to confirm that the screen's backlight really turns off when the lid is closed.

⁠ExpressCard Slots

ExpressCards are a novel form factor that combines USB and PCI Express interfaces. The expresscard test ensures that any ExpressCard slots in the system can communicate through both interfaces. You will be prompted to insert and remove the card(s) during the test.

⁠PC Card Slots

PC Cards (originally known as PCMCIA cards) are an older-style card interface that is generally only found on laptops. The pccard test ensures that we can count any PC Card sockets that are present in the system, that we can turn them on and off and that we can probe them for information about the card(s) they contain. You will need to insert a card in your socket(s) before starting any runs of rhcert that contain a pccard test.

⁠Wireless Network Adapter

The WirelessN test tests any 802.11n wireless Ethernet devices with a variety of throughput and ping tests. Wireless devices are generally only found on laptops, but they are required to be tested wherever they are found. We also have a test called WirelessAC that is planned if any 802.11ac devices are present, and a test called WirelessG that is planned if any 802.11g devices are present. There is a section in Section A.1.26, “network” that explains exactly how to set up a wireless card to be tested.

⁠3.2.4. Testing a Component

Component certifications are generally performed on the same type of system (server/desktop/laptop) for which the component is intended, like a server for a high-end SSD drive or a desktop for a value-line video card. The test system needs to fully support all the features of the component, so make sure that your test system has the necessary capacity to handle the component(s). The test procedure for an individual component is exactly the same as it is if the component were part of a system certification. Full details on all the test procedures can be found in Section A.1, “Hardware Test Procedures”.

⁠Performing Multiple Component Certifications

When performing component certifications, you might use a single system to test two or more components without reinstalling the OS. A persistent certification ID would result in you uploading the results files for all your devices to the same certification entry if you use the automatic upload features of the test server. This is not what you want to do if you want individual component certs. In this situation, you should create multiple certification entries in the hardware catalog, one for each of the components being certified, and associate each with a separate certification entry on the test server.

⁠3.3. Layered Product Certifications

Layered product certifications build upon a completed Red Hat Enterprise Linux certification and list a system as certified for additional Red Hat software products. At this time, we offer layered product certifications for Red Hat OpenStack Platform Compute, Red Hat Storage Server, and Red Hat Enterprise Linux for Real Time.

⁠3.3.1. Certifying for Red Hat OpenStack Platform Compute

A certification entry for Red Hat OpenStack Platform Compute is automatically created for every Red Hat Enterprise Linux 6 and 7, x86_64 server certification request. This is done automatically as no additional tests beyond those normally required for Red Hat Enterprise Linux certification are needed to achieve Red Hat OpenStack Platform Compute certification. Your system will be marked certified for both Red Hat Enterprise Linux and Red Hat OpenStack Platform Compute on successful completion of the Red Hat Enterprise Linux certification, assuming no issues are present that would cause problems running the OpenStack Platform Compute node. If you have any questions about this, please contact your Red Hat Support representative.

⁠3.3.2. Certifying for Red Hat Storage Server

A certification entry for Red Hat Storage Server is automatically created for every Red Hat Enterprise Linux 6, x86_64 server certification request. No additional testing beyond the normal Red Hat Enterprise Linux certification tests are required to receive this certification, but a specification review will be performed by the review team before the certification can be granted. More information on the specification requirements for Red Hat Storage Server can be found at the Red Hat Knowledgebase article entitled Red Hat Storage Server 2.1 Compatible Physical, Virtual Server and Client OS Platforms.

⁠3.3.3. Certifying for Red Hat Enterprise Linux for Real Time

Red Hat Enterprise Linux for Real Time is used for time-critical workloads that need to execute in a defined, predictable way. Any server that is certified to run Red Hat Enterprise Linux 7, AMD64 and Intel 64 architecture, is eligible to be certified for Real Time. If you are interested in certifying a system to run Real Time, confirm that it is already certified for Red Hat Enterprise Linux 7, AMD64 and Intel 64 architecture, then talk to your Red Hat Support representative to learn more about Real Time. Follow these directions when you are ready to begin certification:

Important

Red Hat Enterprise Linux for Real Time certification must occur on the most current GA release of both Red Hat Enterprise Linux 7 and and the Real Time product. Unlike the MRG Realtime product for Red Hat Enterprise Linux 6, the Real Time product's version is linked to the version of Red Hat Enterprise Linux on which it should be run. For example, if Red Hat Enterprise Linux 7.1 is the most current update release of Red Hat Enterprise Linux 7, the most current version of Real Time would also be 7.1. In this case, you would install Red Hat Enterprise Linux 7.1, then install the Real Time 7.1 files in preparation for certification.
Follow these steps to create a hardware catalog entry for a Real Time certification:
  1. Log in to the hardware catalog at http://hardware.redhat.com.
  2. Search for the system that you wish to certify for Real Time and click its Red Hat Enterprise Linux 7 listing to view the full certification information. If you already know the direct URL for the certification, load that in your browser instead of searching. Note that the initial Red Hat Enterprise Linux 7 certification request for the system must be complete before you can submit a request for Real Time certification.
  3. Click the Advanced link near the top of the certification entry.
  4. ⁠
    Create Real Time Certification Fields

    Figure 3.3. Create Real Time Certification Fields

    Under Create New Layered Product Certification - RHEL Real Time, choose the appropriate Real Time version in the dropdown box and then click Create RHEL Real Time to create the request.
  5. You will automatically be taken to the new Real Time certification request.
Now the Real Time certification request can proceed like a Red Hat Enterprise Linux request, with the manual or automatic submission of results files, completion of the test plan items, discussion with the review team, etc. Read on to learn what to do next.
  1. Follow the optional Real Time section in Section 2.13, “Preparing the Test Environment” to get all the necessary Real Time packages installed on your NFS or HTTP server.
  2. Configure the hardware on your server, being sure to follow the System Processors and System Memory guidelines in section 4.7 of the Hardware Certification Policy Guide located here: https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Hardware_Certification/1/html-single/Policy_Guide/index.html.
  3. Perform a fresh install of the most current update release of Red Hat Enterprise Linux 7, AMD64 and Intel 64 architecture, and the rhcert packages on your test system, including the Real Time kernel and its dependencies:
    • kernel-rt
    • rt-setup
    • rtctl
    • rteval
    • rteval-common
    • rteval-loads
    • rt-tests
    • rt-check
    If you use a kickstart file based on the rhel7-x86_64-client.ks Red Hat Enterprise Linux 7, x86_64 kickstart file referenced in Section 2.14.2, “Preparing a Kickstart File to Install Red Hat Enterprise Linux 7 and redhat-certification”, uncomment and configure the Real Time sections (the yum repos and the packages) to have these packages installed for you from your NFS or HTTP server.
  4. Boot into the kernel-rt kernel.
  5. Follow the steps described in Section 3.1, “Scheduling and Running Tests with the Red Hat Certification Tool” to register the SUT with the test server, create a new certification on the test server, and get to the list of available tests.
  6. Run the necessary realtime test (plus the always-required info test). Please note that this test takes several hours to run, possibly as long as 12 hours.
Note that you may need to enlist the help of your company's BIOS engineers to tune the system in order to meet the strict latency requirements of Real Time. Any BIOS or other tuning parameters (disable hyperthreading, shut off hardware monitoring, etc.) required to pass Real Time certification would need to be posted on a public web page that can be linked to by a Red Hat Knowledgebase article. That knowledgebase article would be associated with your Real Time certification entry, ensuring that any customer wanting to run your certified Real Time system would know exactly what tuning to perform in order to get the highest levels of performance on the Real Time kernel.

⁠3.4. Submitting Results

The test server's web interface prepares results files for submission, either by automatic upload to the hardware catalog or by the creation of a results XML file that you can manually upload through the hardware catalog web interface.

⁠3.4.1. Automatic Upload from the Test Server

As mentioned earlier, results can be uploaded directly to a certification entry on the hardware catalog from the web interface of the local test server. If you chose products from the catalog on the test server's Add Products screen when initially creating the certification, this option is available to you.
To upload a results file to the catalog, click the product whose certification results you want to upload, click the Red Hat software package on which you are certifying, then find the results file you wish to upload in the list of results. You can click the date under the Results heading to see what was tested in a particular file. After you find the correct results file, select submit from the action... dropdown box next to the proper file, specify your username and password if they are not already present, and click the Submit button to upload that results package to the Catalog.
You do not need to follow the directions in the following "Manual Submission" section if you just submitted your results file using the automatic process.

⁠3.4.2. Manual Submission

You will need to upload test results to the Certification Catalog manually if you added products to the test server without associating them with a catalog entry.
To obtain the results file, open a web browser and go to the webpage for the test server. Click on the product whose certification results you want to upload, then click on the Red Hat software package on which the system is being certified. Browse the available results files by clicking on the Results or Last Run hyperlinks. When you find the results file you wish to upload, click the back arrow to return to the list of results, then click the Action... dropdown box next to the desired results file. Choose download and you will be prompted to save the results file to your local system.
Now you can upload the results file to the hardware catalog. Each certification request can have as few as one or as many as dozens of results packages attached to it, depending on the system's complexity. We want all certification results for a particular system that are run on the same version of Red Hat Enterprise Linux attached to the same ticket. This means that 32-bit and 64-bit results packages go on the same request, as do re-runs to correct for failed or missing tests, but tests for different versions of Red Hat Enterprise Linux would need to go in different certification requests. There is a size limitation of 16MB for each results file. If you have a results package greater than 16MB in size, please contact your Red Hat Support representative for further assistance.
You attach results packages by going to the appropriate certification entry on the hardware catalog, clicking the Review tab, and filling out the requested information:
⁠
Upload Results Package or Other Document Fields

Figure 3.4. Upload Results Package or Other Document Fields

  • File - The location of the results package. If you are uploading from the SUT, the file will be in the /var/hwcert/store directory.
  • Description - A brief description of the package. It is useful to put things here like the model of the SATA controller being tested if you are submitting tests from several different controllers on this system.
  • Comment - This is a field for you to use when you need to provide more information than just the one line in the Description.
  • Attachment Type - Tell us whether you are uploading a results package or some other kind of file.

    Note

    It is recommended to attach the product specification document while filling the hardware details during certification creation.
When you have provided the requested information, click the Select File button and the results file will be submitted. The review team will analyze the results and give credit for each item on the official test plan that has been satisfied by this results file.

⁠3.5. Monitoring Certification Progress

After you submit your results, the review team will analyze their contents and award credit for each passing test that is part of the plan. The review team checks the Confirmed box as they verify each passing test. This allows you to see at a glance which tests are outstanding and which have been verified as passing. If any problems are found, the review team will update your cert request with a question for you, which will automatically be emailed to the person who submitted the cert.
Here is an example of an in-progress test plan where the network and I/O tests are complete, but the storage and video tests have not yet been confirmed:
⁠
In-Progress Test Plan

Figure 3.5. In-Progress Test Plan

When the review team determines that a test has passing results, they use the dropdown box under each test plan entry to select the specific run of the test that contains the passing result. The test ID, which is the number in brackets at the beginning of each line, allows us to track the exact run of the test that was used to pass this particular test plan entry. When the review team selects a test run for a plan entry, several other pieces of information also appear on the line. These can be seen in the picture above:
  • Results - The logfiles from the specific test that was run on this device
  • Hardware - Information on the hardware that was tested, taken from the udev database
  • INFO line Results - The results of the INFO test that was run at the same time as the test that is being used to satisfy this test plan item
  • INFO line Hardware - The hardware information from the info test that was run at the same time as the test that is being used to satisfy this test plan item. It will have information about every piece of hardware detected in the system, rather than just information on the piece of hardware tested in this run. This is also taken from the udev database.
If you filled the leverage section in the test plan to leverage the existing test results (see Section 2.12, “Leveraging of Existing Test Results”) for testing of specific systems (System Leveraging) or components (Component Leveraging), the test plan appears as below.
The following screenshot shows an example of System Leveraging (previous test ID 306029) for an identical system.
The following screenshot shows an example of Component Leveraging (previous certification ID 1117200) for an identical component.

⁠3.6. Completing Certifications

A certification is complete once all the items on the official test plan have been reviewed and found to have passing results. At this point the certification can be closed and published, or closed and left unpublished. Supplemental certifications always remain unpublished, and system or component certs can also be closed and left unpublished if the vendor does not want to publicly advertise the certification status or the existence of the system/component (most certifications are closed and published).
The lengthy discussions and the system information that is seen by you and the review team will not be visible to the general public in a published cert. All that customers can see when viewing published certs is basic information about the system. Here is an example of completed, published certifications for the hypothetical "Mycompany Ultraserver X12" server:
⁠
Public View of Published Certifications

Figure 3.6. Public View of Published Certifications

⁠Appendix A. Appendixes

⁠A.1. Hardware Test Procedures

In this section we give more detailed information about each of the tests for hardware certification. Each test section uses the following format:
What the test covers: This section lists the types of hardware that this particular test is run on.
What the test does: This section explains what the test scripts do. Remember, all the tests are python scripts and can be viewed in the directory /usr/lib/python2.7/site-packages/rhcert/suites/hwcert/tests if you want to know exactly what commands we are executing in the tests.
Preparing for the test: This section talks about the steps necessary to prepare for the test. For example, it talks about having a USB device on hand for the USB test and blank discs on hand for rewritable optical drive tests.
Executing the test: This section identifies whether the test is interactive or non-interactive and explains what command is necessary to run the test.
Run Time: This section explains how long a run of this test will take. Timing information for the info test is mentioned in each section as it is a required test for every run of the test suite.

⁠A.1.1. 1GigEthernet

What the test covers: The 1GigEthernet test is run on all wired Ethernet connections with a maximum connection speed of 1 gigabit/sec. Connection speed is determined by parsing the "Speed" line in the output of ethtool.
What the test does: This test adds link speed detection to the existing network test. In addition to passing all the existing network test items, this test must detect a throughput of 1Gb/s (with a margin for overhead) in order to pass. Please see Section A.1.26, “network” for information on the rest of the test functionality.

⁠A.1.2. 10GigEthernet

What the test covers: The 10GigEthernet test is run on all wired Ethernet connections with a maximum connection speed of 10 gigabits/sec. Connection speed is determined by parsing the "Speed" line in the output of ethtool.
What the test does: This test adds link speed detection to the existing network test. In addition to passing all the existing network test items, this test must detect a throughput of 10Gb/s (with a margin for overhead) in order to pass. Please see Section A.1.26, “network” for information on the rest of the test functionality.

⁠A.1.3. 20GigEthernet

What the test covers: The 20GigEthernet test is run on all wired Ethernet connections with a maximum connection speed of 20 gigabits/sec. Connection speed is determined by parsing the "Speed" line in the output of ethtool.
What the test does: This test adds link speed detection to the existing network test. In addition to passing all the existing network test items, this test must detect a throughput of 20Gb/s (with a margin for overhead) in order to pass. Please see Section A.1.26, “network” for information on the rest of the test functionality.

⁠A.1.4. 25GigEthernet

What the test covers: The 25GigEthernet test is run on all wired Ethernet connections with a maximum connection speed of 25 gigabits/sec. Connection speed is determined by parsing the "Speed" line in the output of ethtool.
What the test does: This test adds link speed detection to the existing network test. In addition to passing all the existing network test items, this test must detect a throughput of 25Gb/s (with a margin for overhead) in order to pass. Please see Section A.1.26, “network” for information on the rest of the test functionality.

⁠A.1.5. 40GigEthernet

What the test covers: The 40GigEthernet test is run on all wired Ethernet connections with a maximum connection speed of 40 gigabits/sec. Connection speed is determined by parsing the "Speed" line in the output of ethtool.
What the test does: This test adds link speed detection to the existing network test. In addition to passing all the existing network test items, this test must detect a throughput of 40Gb/s (with a margin for overhead) in order to pass. Please see Section A.1.26, “network” for information on the rest of the test functionality.

⁠A.1.6. 50GigEthernet

What the test covers: The 50GigEthernet test is run on all wired Ethernet connections with a maximum connection speed of 50 gigabits/sec. Connection speed is determined by parsing the "Speed" line in the output of ethtool.
What the test does: This test adds link speed detection to the existing network test. In addition to passing all the existing network test items, this test must detect a throughput of 50Gb/s (with a margin for overhead) in order to pass. Please see Section A.1.26, “network” for information on the rest of the test functionality.

⁠A.1.7. 100GigEthernet

What the test covers: The 100GigEthernet test is run on all wired Ethernet connections with a maximum connection speed of 100 gigabits/sec. Connection speed is determined by parsing the "Speed" line in the output of ethtool.
What the test does: This test adds link speed detection to the existing network test. In addition to passing all the existing network test items, this test must detect a throughput of 100Gb/s (with a margin for overhead) in order to pass. Please see Section A.1.26, “network” for information on the rest of the test functionality.

Note

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.

⁠A.1.8. audio

What the test covers: Removable sound cards and integrated sound devices are tested with the audio test. The test is scheduled when the hardware detection routines find the following strings in the udev database: 
E: SUBSYSTEM=sound
E: SOUND_INITIALIZED=1
You can see these strings and the strings that trigger the scheduling of the other tests in this guide in the output of the command udevadm info --export-db.
What the test does: The test plays a prerecorded sound (guitar chords or a recorded voice) while simultaneously recording it to a file, then it plays back the recording and asks if you could hear the sound.
Preparing for the test: Before you begin your test run, you should ensure that the audio test is scheduled and that the system can play and record sound. Contact your support contact at Red Hat for further assistance if the test does not appear on a system with installed audio devices. If the test is correctly scheduled, continue on to learn how to manually test the playback and record functions of your sound device.
With built-in speakers present or speakers/headphones plugged into the headphone/line-out jack, playback can be confirmed before testing in these ways:
  1. In Red Hat Enterprise Linux 6, right-click on the volume icon at the top of the GUI window and choose Sound Preferences. With the tool open, click on the Hardware tab, select the sound card you wish to test, and adjust the output volume to an appropriate level. Next, click the Test Speakers button. In the window that appears, click the test buttons to generate sounds. Close the test window and exit the sound settings when finished.
  2. In Red Hat Enterprise Linux 7, right-click on the volume icon at the top of the GUI window and choose Sound SettingsWith the tool open, click on the Output tab, select the sound card you wish to test, and adjust the output volume to an appropriate level. Next, click the Test Speakers button. In the window that appears, click the test buttons to generate sounds. Close the test window and exit the sound settings when finished.
If no sound can be heard, ensure that the speakers are plugged in to the correct port. You can use any line-out or headphone jack (we have no requirement for which port you must use). Make sure sound is not muted and try adjusting the volume on the speakers and in the operating system itself.
If the audio device has record capabilities, these should also be tested before attempting to run the test. Plug a microphone into one of the Line-in or Mic jacks on the system, or you can use the built-in microphone if you are testing a laptop. Again, we don't require you to use a specific input jack; as long as one works, the test will pass.
  1. In Red Hat Enterprise Linux 6, right-click on the volume icon at the top of the GUI window and choose Sound Preferences. With the tool open, click the Input tab, select the appropriate input, and adjust the input volume to 100%. Tap the mic or blow on it, and watch the Input level graphic. If you see it moving, the microphone is set up properly. If it does not move, try another input selection and/or microphone port to plug the microphone into.
  2. In Red Hat Enterprise Linux 7, right-click on the volume icon at the top of the GUI window and choose Sound Settings. With the tool open, click the Input tab, select the appropriate input, and adjust the input volume to 100%. Tap the mic or blow on it, and watch the Input level graphic. If you see it moving, the microphone is set up properly. If it does not move, try another input selection and/or microphone port to plug the microphone into.
Contact your support person if you are unable to either hear sound or see the input level display move, as this will lead to a failure of the audio test. If you are able to successfully play sounds and see movement on the input level display when making sounds near the microphone, continue to the next section to learn how to run the test.
Executing the test: The audio test is interactive. Before you execute a test run that includes an audio test, connect the microphone you used for your manual test and place it in front of the speakers, or ensure that the built-in microphone is free of obstructions. Alternatively, you can connect the line-out jack directly to the mic/line-in jack with a patch cable if you are testing in a noisy environment. Click the Run Interactive button to begin testing and follow the steps below:
  1. The system will play sounds and ask if you heard them. Answer y or n as appropriate. If you decide to use a direct connection between output and input rather than speakers and a microphone, you will need to choose y for the answer regardless, as your speakers will be bypassed by the patch cable.
  2. The system will next play back the file it recorded. If you heard the sound, answer y when prompted. Otherwise, answer n.
Run time: The audio test takes less than 1 minute for simultaneous playback and record, then the playback of the recorded sound. The required info test will add about a minute to the overall run time.

⁠A.1.9. battery

What the test covers: The battery test is only valid for systems that can be powered by a built-in battery use an AC adapter. It does not test external batteries like those found in a UPS, additional internal batteries like the BIOS battery or battery-backed cache, or any other kind of battery that is not providing primary, internal power to the system. The test is scheduled when the hardware detection routines find the following string in the udev database: 
POWER_SUPPLY_TYPE=Battery
What the test does: The test does all its work based on the status of the AC adapter. Testing begins with the AC adapter attached to the system. The test scripts verify the status of the AC adapter and that the battery is present. Then the tester is asked to unplug the adapter, which will cause the battery to begin discharging. The test scripts verify this.
Preparing for the test: The battery test requires that the system be connected via an AC adapter when the test is launched. Ensure that it is connected before proceeding.
Executing the test: The battery test is interactive. When you click the Run Interactive button, it will display the current status of the battery (capacity and charging status) and ask for the AC adapter to be unplugged until the battery discharges for 10 mWh. The test will automatically end at that point and the tester should plug the AC adapter back in.
Run time: The time of the battery test varies depending on the discharge and recharge speeds of the battery. It takes about 3 minutes on a 2012-era laptop that emphasizes portability and long battery life over screen size and computing power. Because this test is run on laptops, a suspend test must accompany the required info test for each run. The suspend test will add approximately 6 minutes to each test run, and info will add another minute.

⁠A.1.10. bluray

What the test covers: All supported optical drives, regardless of formats and features, use the same test methodology, so we are covering all of them in a single section. There are three certification tests for optical media:
  • bluray - Tests BD-ROM , BD-R and BD-RE media
  • dvd - Tests DVD-ROM, DVD-R, DVD+R, DVD-RW, and DVD+RW media
  • cdrom - Tests CD-ROM, CD-R and CD-RW media
Any other disc formats or features like dual-layer (DL) discs, -RAM discs or HD-DVD discs are not tested by the rhcert suite, and can be ignored. The rhcert application determines which of the optical drive tests to schedule, if any, and what type of media to request based on udev information. Here's an example of the udev database on a desktop computer, showing the supported media of the system's CD-RW, DVD+/-RW, BD-RE drive: 
E: ID_CDROM=1
E: ID_CDROM_CD=1
E: ID_CDROM_CD_R=1
E: ID_CDROM_CD_RW=1
E: ID_CDROM_DVD=1
E: ID_CDROM_DVD_R=1
E: ID_CDROM_DVD_RW=1
E: ID_CDROM_DVD_RAM=1
E: ID_CDROM_DVD_PLUS_R=1
E: ID_CDROM_DVD_PLUS_RW=1
E: ID_CDROM_DVD_PLUS_R_DL=1
E: ID_CDROM_BD=1
E: ID_CDROM_BD_R=1
E: ID_CDROM_BD_RE=1
The scripts look for ID_CDROM=1 before scheduling any of the three optical media tests. If it finds this value, it analyzes the properties to determine which of the three tests to schedule. You can see the drive's ID_CDROM properties in the udev output above. These tell the rhcert application that the drive is capable of writing to many different disc formats including CD, DVD and Blu-Ray (BD). From that information we know that the bluray, cdrom and dvd tests will be scheduled, and the test harness decides which feature of the format to test. The following tables explain how the rhcert application makes that determination:
The test suite always attempts to schedule the most advanced media tests first in accordance with the rules in the Policy Guide, which requires testing read, write and erase functionality when all are present. Discs that support rewrite functions include:
  • BD-RE (tested as part of the 'bluray' test)
  • Either DVD-RW or DVD+RW (tested as part of the 'dvd' test)
  • CD-RW (tested as part of the 'cdrom' test)
Only formats supported by the drive are scheduled for testing. If your drive(s) support DVD-RW and DVD+RW, you can use either format of disc during the test. You do not have to test both.
If the drive is not capable of rewrite operations but it does have write-once capabilities for a disc format, the test suite schedules a write-once media test. Discs that support write-once functionality include:
  • BD-R (tested as part of the 'bluray' test)
  • Either DVD-R or DVD+R (tested as part of the 'dvd' test)
  • CD-R (tested as part of the 'cdrom' test)
Only formats supported by the drive are scheduled for testing. If your drive(s) support DVD-R and DVD+R, you can use either format of disc during the test. You do not have to test both.
If the drive is not capable of rewrite or write-once operations but it does have read-only support for a disc format, the test suite schedules a read-only media test. Discs that are read-only include:
  • BD-ROM (tested as part of the 'bluray' test)
  • DVD-ROM (tested as part of the 'dvd' test)
  • CD-ROM (tested as part of the 'cdrom' test)
Only formats supported by the drive are scheduled for testing.
Using the udev data from our example laptop BD/DVD/CD drive from above, we can use this list of discs and tests to determine what types of media are needed. The drive supports all types of Blu-Ray media and since rewritable discs take precedence over write-once or read-only, a BD-RE disc will be needed for the bluray test.
The policy guide was updated at the launch of Red Hat Enterprise Linux 6.3 to reduce the number of optical drive tests that must be performed. Now each controller will only need one test instead of multiple tests of different disc formats. For the example drive shown above, you would run a Blu-Ray rewritable disc test and nothing else. The other tests (CDROM and DVD) are still planned by the rhcert tool, but you do not have to run them. How do you know what drive and which disc type to test? Here is a handy table that explains how it works:
⁠

Table A.1. Blank Table of Optical Drive Features

 Rewrite or WriteRead Only
 BD-REDVD+/-RWCD-RWBD-RDVD+/-RCD-RBD-ROMDVD-ROMCD-ROM
Drive 1         
Drive 2         
Drive 3         
...         
Drive X         
Fill out the table with all the drives you have available to you on your controller. Place an "X" in the column that corresponds with the disc format that each drive supports. When you have finished, choose the drive that has an "X" in the column furthest to the left for your certification testing and be prepared to test that kind of media in the drive. If two or more drives have an "X" in the same leftmost column, you can use either drive for your tests.
Here's an example.
  • Drive 1 - A Blu-Ray drive that supports rewriting
  • Drive 2 - A CD-ROM drive that supports rewriting
  • Drive 3 - A DVD drive that supports rewriting
  • Drive 4 - A CD-ROM drive that supports read functions only
  • Drive 5 - A Blu-Ray drive that supports writing, but not rewriting
⁠

Table A.2. Sample Table of Optical Drive Features

 Rewrite or WriteRead Only
 BD-REDVD+/-RWCD-RWBD-RDVD+/-RCD-RBD-ROMDVD-ROMCD-ROM
Drive 1XXXXXXXXX
Drive 2    XX  X
Drive 3  XXXX XX
Drive 4        X
Drive 5 XXXXXXXX
For the series of drives in the example chart above, you would choose to do your test with Drive 1, and you would only need to run the bluray test with a BD-RE disc. This is because Drive 1 is the drive with an "X" in the furthest column to the left, and that column corresponds with BD-RE media. No other testing would be required.
What the test does: For read-only drives, it reads data from the disc and copies it to the hard drive. The original data on the disc is then compared to the copy on the hard drive. If all file checksums match, the test passes. Writable media adds a write procedure to the test. A blank writable disc is inserted in the system and data is written to it from the hard drive. The data on the disc is then compared to the data on the hard drive. If the file checksums match, the test passes. Rewritable media adds a disc blank to the procedure, followed by a write of data from the hard drive and a comparison of the written data to the original. If the blank is successful and the checksums of the newly written files on the disc match those on the hard drive, the test passes. The test also includes disc ejects between each phase (blank, write, compare). The tester will need to insert the disc back into the drive if the drive is not capable of closing the tray by itself, or if it is a slot loading drive.
Executing the test: The bluray test is interactive. To begin testing, install the proper drive as determined by the table you created and click the Run Interactive button next to the test name. Follow the directions on screen and choose the proper disc format when prompted (the one corresponding with the leftmost column in the table that has an "X" in it), then insert the correct disc when asked. As the test enters the various phases (blank, write, compare, where applicable), the on-screen display will explain what is happening.
Run time: The run time for all optical drive testing is dependent on the speed of the media and drive. For a 4x DVD-RW disc, the DVD test takes about 10 minutes to write and verify ~1.7GB of data.

⁠A.1.11. cdrom

CD drives of all kinds are tested using the same procedures as Blu-Ray drives. Please see Section A.1.10, “bluray” for more information.

⁠A.1.12. core

What the test covers: The core test examines the system's CPUs and ensures that they are capable of functioning properly under load.
What the test does: The core test is actually composed of two separate routines. The first test is designed to detect clock jitter. Jitter is a condition that occurs when the system clocks are out of sync with each other. The system clocks are not the same as the CPU clock speed, which is just another way to refer to the speed at which the CPUs are operating. The jitter test uses the getimeofday() function to obtain the time as observed by each logical CPU and then analyzes the returned values. If all the CPU clocks are within .2 nanoseconds of each other, the test passes. The tolerances for the jitter test are very tight. In order to get good results it's important that the rhcert tests are the only loads running on a system at the time the test is executed. Any other compute loads that are present could interfere with the timing and cause the test to fail. The jitter test also checks to see which clock source the kernel is using. It will print a warning in the logs if an Intel processor is not using TSC, but this will not affect the PASS/FAIL status of the test.
The second routine run in the core test is a CPU load test. It's the test provided by the required stress package. The stress program, which is available for use outside the rhcert suite if you are looking for a way to stress test a system, launches several simultaneous activities on the system and then monitors for any failures. Specifically it instructs each logical CPU to calculate square roots, it puts the system under memory pressure by using malloc() and free() routines to reserve and free memory respectively, and it forces writes to disk by calling sync(). These activities continue for 10 minutes, and if no failures occur within that time period, the test passes. Please see the stress manpage if you are interested in using it outside of hardware certification testing.
Preparing for the test: The only preparation for the core test is to install a CPU that meets the requirements that are stated in the Policy Guide.
Executing the test: The core test is non-interactive. Check the checkbox next to the test and click the Run Selected button to perform the test.
Run time, bare-metal: The core test itself takes about 12 minutes to run on a bare-metal system. The jitter portion of the test takes a minute or two and the stress portion runs for exactly 10 minutes. The required info test will add about a minute to the overall run time.
Run time, full-virt guest: The fv_core test takes slightly longer than the bare-metal version, about 14 minutes, to run in a KVM guest. The added time is due to guest startup/shutdown activities and the required info test that runs in the guest. The required info test on the bare-metal system will add about a minute to the overall run time.

Note

A note about FV testing times: The first time you run any full-virt test, the test tool will need to acquire the FV guest files. If these files are located on the local test server and you are using 1GbE or faster networking, that will take only a minute or two to transfer the ~300MB of guest files. If the files are retrieved from the Red Hat FTP server, which happens automatically if the guest files are not installed and not found on the local test server, the first runtime will depend on the speed of the FTP transfer. Once the guest files are available on the SUT they will be used for all subsequent runs of fv_* tests.

⁠A.1.13. cpuscaling

What the test covers: The cpuscaling test examines a CPU's ability to increase and decrease its clock speed according to the compute demands placed on it.
What the test does: The test exercises the CPUs at varying frequencies using different scaling governors (the set of instructions that tell the CPU when to change to higher or lower clock speeds and how fast to do so) and measures the difference in the time that it takes to complete a standardized workload. The test is scheduled when the hardware detection routines find the following directories in /sys containing more than one cpu frequency: 
/sys/devices/system/cpu/cpuX/cpufreq
The cpuscaling test is planned once per package, rather than being listed once per logical CPU. When the test is run, it will determine topology via /sys/devices/system/cpu/cpuX/topology/physical_package_id, and run the test in parallel for all the logical CPUs in a particular package.
The test procedure for each CPU package is as follows:
The test uses the values found in the sysfs filesystem to determine the maximum and minimum CPU frequencies. You can see these values for any system with this command: 
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
There will always be at least two frequencies displayed here, a maximum and a minimum, but some processors are capable of finer CPU speed control and will show more than two values in the file. Any additional CPU speeds between the max and min are not specifically used during the test, though they may be used as the CPU transitions between max and min frequencies. The test procedure is as follows:
  1. The test records the maximum and minimum processor speeds from the file /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies.
  2. The userspace governor is selected and maximum frequency is chosen.
  3. Maximum speed is confirmed by reading all processors' /sys/devices/system/cpu/cpuX/cpufreq/scaling_cur_freq value. If this value does not match the selected frequency, the test will report a failure.
  4. Every processor in the package is given the simultaneous task of calculating pi to 2x10^12 digits. The value for the pi calculation was chosen because it takes a meaningful amount of time to complete (about 30 seconds).
  5. The amount of time it took to calculate pi is recorded for each CPU, and an average is calculated for the package.
  6. The userspace governor is selected and the minimum speed is set.
  7. Minimum speed is confirmed by sysfs data, with a failure occurring if any CPU is not at the requested speed.
  8. The same pi calculation is performed by every processor in the package and the results recorded.
  9. The ondemand governor is chosen, which throttles the CPU between minimum and maximum speeds depending on workload.
  10. Minimum speed is confirmed by sysfs data, with a failure occurring if any CPU is not at the requested speed.
  11. The same pi calculation is performed by every processor in the package and the results recorded.
  12. The performance governor is chosen, which forces the CPU to maximum speed at all times.
  13. Maximum speed is confirmed by sysfs data, with a failure occurring if any CPU is not at the requested speed.
  14. The same pi calculation is performed by every processor processor and the results recorded.
Now the analysis is performed on the three subsections. In steps one through eight we obtain the pi calculation times at maximum and minimum CPU speeds. The difference in the time it takes to calculate pi at the two speeds should be proportional to the difference in CPU speed. For example, if a hypothetical test system had a max frequency of 2GHz and a min of 1GHz and it took the system 30 seconds to run the pi calculation at max speed, we would expect the system to take 60 seconds at min speed to calculate pi. We know that for various reasons perfect results will not be obtained, so we allow for a 10% margin of error (faster or slower than expected) on the results. In our hypothetical example, this means that the minimum speed run could take between 54 and 66 seconds and still be considered a passing test (90% of 60 = 54 and 110% of 60 = 66).
In steps nine through eleven, we test the pi calculation time using the ondemand governor. This confirms that the system can quickly increase the CPU speed to the maximum when work is being done. We take the calculation time obtained in step eleven and compare it to the maximum speed calculation time we obtained back in step five. A passing test has those two values differing by no more than 10%.
In steps twelve through fourteen, we test the pi calculation using the performance governor. This confirms that the system can hold the CPU at maximum frequency at all times. We take the pi calculation time obtained in step 14 and compare it to the maximum speed calculation time we obtained back in step five. Again, a passing test has those two values differing by no more than 10%.
An additional portion of the cpuscaling test runs when an Intel processor with the TurboBoost feature is detected by the presence of the ida CPU flag in /proc/cpuinfo. This test chooses one of the CPUs in each package, omitting CPU0 for housekeeping purposes, and measures the performance using the ondemand governor at maximum speed. It expects a result of at least 5% faster performance than the previous test, when all the cores in the package were being tested in parallel.
Preparing for the test: To prepare for the test, ensure that CPU frequency scaling is enabled in the BIOS and ensure that a CPU is installed that meets the requirements explained in the Policy Guide.
Executing the test: The cpuscaling test is non-interactive. Check the checkbox next to the test and click the Run Selected button to perform the test.
Run time: The cpuscaling test takes about 42 minutes for a 2013-era, single CPU, 6-core/12-thread 3.3GHz Intel-based workstation running Red Hat Enterprise Linux 6.4, AMD64 and Intel 64. Systems with higher core counts and more populated sockets will take longer. The required info test will add about a minute to the overall run time.

⁠A.1.14. dvd

DVD drives of all kinds are tested using the same procedures as Blu-Ray drives. Please see Section A.1.10, “bluray” for more information.

⁠A.1.15. Ethernet

What the test covers: The Ethernet test only appears when the speed of a network device is not recognized by the test suite. This may be due to an unplugged cable or some other fault is preventing the proper detection of the connection speed. Please exit the test suite, check your connection, and run the test suite again when the device is properly connected. If the problem persists, contact your Red Hat support representative for assistance.
The example below shows a system with two gigabit Ethernet devices, eth0 and eth1. Device eth0 is properly connected, but eth1 is not plugged in.
The output of the ethtool command shows the expected gigabit Ethernet speed of 1000Mb/s for eth0: 
# ethtool eth0
Settings for eth0:
	Supported ports: [ TP ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Supported pause frame use: No
	Supports auto-negotiation: Yes
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Advertised pause frame use: No
	Advertised auto-negotiation: Yes
	Speed: 1000Mb/s
	Duplex: Full
	Port: Twisted Pair
	PHYAD: 2
	Transceiver: internal
	Auto-negotiation: on
	MDI-X: on
	Supports Wake-on: pumbg
	Wake-on: g
	Current message level: 0x00000007 (7)
			       drv probe link
	Link detected: yes
But on eth1 the ethtool command shows an unknown speed, which would cause the Ethernet test to be planned. 
# ethtool eth1
Settings for eth1:
	Supported ports: [ TP ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Supported pause frame use: No
	Supports auto-negotiation: Yes
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Advertised pause frame use: No
	Advertised auto-negotiation: Yes
	Speed: Unknown!
	Duplex: Unknown! (255)
	Port: Twisted Pair
	PHYAD: 1
	Transceiver: internal
	Auto-negotiation: on
	MDI-X: Unknown
	Supports Wake-on: pumbg
	Wake-on: g
	Current message level: 0x00000007 (7)
			       drv probe link
	Link detected: no

⁠A.1.16. expresscard

What the test covers: The expresscard test looks for devices with both types of ExpressCard interfaces, USB and PCI Express (PCIe), and confirms that the system can communicate through both. ExpressCard slot detection is not as straightforward as detecting other devices in the system. ExpressCard was specifically designed to not require any kind of dedicated bridge device. It's merely a novel form factor interface that combines PCIe and USB. Because of this, there is no specific "ExpressCard slot" entry that we can see in the output of udev. We decided to schedule the test on systems that contain a battery, USB and PCIe interfaces, as we have seen no devices other than ExpressCard-containing laptops with this combination of hardware.
What the test does: The test first takes a snapshot of all the devices on the USB and PCIe buses using the lsusb and lspci commands. It then asks the tester how many ExpressCard slots are present in the system. The tester is asked to insert a card in one of the slots. The system scans the USB and PCIe buses and compares the results to the original lsusb and lspci output to detect any new devices. If a USB device is detected, the system asks you to remove the card and insert a card with a PCIe interface into the same slot. If a PCIe-based card is detected, the system asks you to remove it and insert a USB-based card into the same slot. If a card is inserted with both interfaces (a docking station card, for example), it fulfills both testing requirements for the slot at once. This procedure is repeated for all slots in the system.
Preparing for the test: You will need ExpressCard cards with USB and PCIe buses. This can be two separate cards or one card with both interfaces. Remove all ExpressCard cards before running the test.
Executing the test: The expresscard test is interactive. Click the Run Interactive button next to the test name to begin. It will prompt you to remove all ExpressCards, then ask for permission to load the PCI Express hotplug module (pciehp) if it is not loaded. PCIe hotplug capabilities are needed in order to add or remove PCIe-based ExpressCard cards while the system is running. Next the test will ask you for the number of ExpressCard slots in the system, followed by prompts to insert and remove cards with both types of interfaces (USB and PCIe) in any order.

⁠A.1.17. fencing (Optional)

What the test covers: The fencing test covers integrated power control through a baseboard management controller (BMC) or other on-board management system (DRAC, iLO, ILOM etc.) capable of issuing a power cycle command. It is not required for certification at this time.
What the test does: The network and kdump server reboots the SUT via the SUT's fencing device.
Preparing for the test: The test must be manually added to the test plan on the SUT, as the certification tool has no way to know if the system has a BMC. To add the test, run the command rhcert-cli plan --add --test=fencing and answer y to the question of whether or not to add a test without a specific device. The clustering packages that contain the fencing scripts must be installed on the network / kdump test server as it is the computer that executes the fencing command. SELinux must also be disabled on the server in order for the test to proceed. Use the command setenforce 0 on the server to disable SELinux temporarily, or edit /etc/selinux/config, set the SELINUX parameter to disabled and restart the network test server to make the change permanent.
Executing the test: The fencing test is interactive. Click the Run Interactive button next to the test name to begin. The first thing the test will ask for is the fence agent type (ilo, ipmilan, drac, etc.), followed by the fence device hostname or IP, the username and password. It will then send the fence agent commands to the network/kdump server and the server will execute them on the BMC. The SUT will wait 60 seconds for the reboot to occur. If it does, when it comes back up it queries the test server to determine how long it took to reboot. If the reboot does not occur (the 60 second timeout period on the SUT ends with nothing occurring), the test will fail.

⁠A.1.18. fv_core

The fv_core test is a wrapper that launches the FV guest and runs a core test on it. Please see Section A.1.12, “core” for information on the test methodology and run times.

⁠A.1.19. fv_memory

The fv_memory test is a wrapper that launches the FV guest and runs a memory test on it. Please see Section A.1.25, “memory” for information on the test methodology and run times.

⁠A.1.20. fv_network (Optional for SR-IOV)

The fv_network test is a wrapper that launches the FV guest and runs a network test on it. It is useful for verifying the function of one or more network devices that support SR-IOV.
What the test covers: The test covers virtual function network devices on SR-IOV capable systems. Systems without SR-IOV may run the test too, but it will only verify the function of the standard virtual network hardware.
What the test does: Please see Section A.1.26, “network” for information on the test methodology and run times.
Preparing for the test: Assign a virtual function (VF) from a NIC to the guest. Directions on how to configure VFs can be found in the Using SR-IOV section of the Virtualization Deployment and Administration Guide.
Executing the test: The fv_network test is non-interactive. After properly assigning a VF to the guest, check the checkbox next to the test and click the Run Selected button to perform the test.

⁠A.1.21. fv_storage (Optional)

The fv_storage test is a wrapper that launches the FV guest and runs a storage test on it. It is not required for certification at this time.

⁠A.1.22. info

What the test does: The info test is a part of all results packages. It's run automatically along with any other test that is being performed and is a required part of every results package. If you attempt to submit a package that contains no info test, the package will be rejected. The test performs several different tasks. If any of these tasks fail, the info test fails:
  1. Confirm that /proc/sys/kernel/tainted is zero, indicating a non-tainted kernel.
  2. Confirm that package verification with rpm -V shows that no files have been modified.
  3. Confirm that rpm -qa kernel shows that the buildhost of the kernel package is a redhat.com machine.
  4. Record the boot parameters from /proc/cmdline for later analysis by our review team.
  5. Confirm that rpm -V redhat-certification shows that no modifications have been made to any of the certification test suite files.
  6. Confirm that all the modules shown by lsmod show up in a listing of the kernel files with the command rpm -ql kernel.
  7. Confirm that all modules are on the kABI whitelist.
  8. Confirm that the module vendor and buildhost are appropriate Red Hat entries.
  9. Confirm that the kernel is the GA kernel of the Red Hat minor release. The verification is attempted with data from the redhat-certification-informatino package. Internet verification (direct routing/dns resolution have to work, or environment variable 'ftp_proxy=http://proxy.domain:80' has to be set) is attempted if the kernel is not present in the redhat-certification-information package.
After performing those tasks, the system gathers a sosreport and the output of dmidecode. These are used by our review team to help them in their analysis of the test results.
Run time: The info test takes around 1 minute on a 2013-era, single CPU, 3.3GHz, 6-core/12-thread Intel workstation with 8 GB of RAM running Red Hat Enterprise Linux 6.4, AMD64 and Intel 64 that was installed using the kickstart files in this guide. The time will vary depending on the speed of the machine and the quantity of RPM files that are installed.

⁠A.1.23. kdump

What the test covers: The kdump test verifies the ability of a system to capture a vmcore after a crash using the kdump utility. There are two entries in the local test plan, one for local core file storage and one for the remote copying of a vmcore via NFS to the test server.
What the test does: The test will crash the system and write a vmcore to /var/crash. It will crash the system a second time and write a vmcore to the /var/www/hwcert/export directory on the network / kdump server system. After each of the two actions occurs, the test server program will confirm that the system only did the things it was scheduled to do, e.g. it checks that only two reboots occurred when each panic was triggered.
Preparing for the test: Ensure that the system is connected to thte network before running the test. All parameters will be automatically set by the test server.
Executing the test: The kdump test is interactive and is run via the Run Interactive button in the list of tests. The system will ask you to click the Yes or No button to trigger the crash when the kdump test is run. The discs will sync and the vmcore file will be saved. You will see a series of messages including "Waiting for response", "Waiting for connection", and finally, "ready" as the test server waits for completion of the task. After the core is saved, the system under test will reboot and the rhcert application will be ready for the next test. The rhcert server will verify the vmcore file is present and valid. It will then repeat the crash, this time exporting the vmcore file to the test server, when you click the button next to the NFS version of tes test.
Run time: The kdump test run time is highly variable. It is dependent on the amount of RAM in the SUT, the speed of the disks in both the SUT and the test server, the speed of the network connection to the test server, and the time it takes to reboot the SUT. For a 2013-era workstation with 8GB of RAM, a 7200 RPM 6Gb/s SATA drive, a gigabit Ethernet connection to the test server and a 1.5 minute reboot time, a local kdump test can complete in about 4 minutes, including the reboot. The same 2013-era workstation can complete a NFS kdump test in about 5 minutes to a similarly equipped network test server. The required info test will add about a minute to the overall run time.

⁠A.1.24. lid

What the test covers: The lid test is only valid for systems that have integrated displays and therefore have a lid that can be opened and closed. The lid is detected by searching the udev database for a device with "lid" in its name: 
E: NAME="Lid Switch"
What the test does: The test ensures that the system can determine when its lid is closed and when it is open via parameters in udev, and that it can turn off the display's backlight when the lid is closed.
Preparing for the test: To prepare for the test, ensure that the power management settings do not put the system to sleep or into hibernation when the lid is closed. In Red Hat Enterprise Linux 6, right-click on the battery icon in the panel and choose Preferences. On the AC Power tab, select Blank screen as the action that occurs when the lid is closed. In Red Hat Enterprise Linux 7, use the Tweak Tool to disable suspend or hibernate on lid close. Make sure the lid is open before you start the test run.
Executing the test: The lid test is interactive. Click the Run Interactive button next to the test name to begin. You will be asked if you are ready to begin the test, so answer Yes to continue. Close the lid when prompted, watching to see if the backlight turns off. You may have to look through the small space between the keyboard and lid when the laptop is closed to verify that the backlight has turned off. Answer Yes if the backlight turns off or No if the backlight does not turn off.
Run time: The lid test takes about 30 seconds to perform, essentially the time it takes to close the lid just enough to have the backlight turn off. Because this test is run on laptops, a suspend test must accompany the required info test for each run. The suspend test will add approximately 6 minutes to each test run, and info will add another minute.

⁠A.1.25. memory

What the memory test covers: The memory test is used to test system RAM. It does not test USB flash memory, SSD storage devices or any other type of RAM-based hardware, it only tests main memory.
What the test does: The test uses the file /proc/meminfo to determine how much memory is installed in the system. Once it knows how much is installed, it checks to see if the system architecture is 32-bit or 64-bit. Then it determines if swap space is available or if there is no swap partition. The test runs either once or twice with slightly different settings depending on whether or not the system has a swap file:
  1. If swap is available, allocate more RAM to the memory test than is actually installed in the system. This forces the use of swap space during the run.
  2. Regardless of swap presence, allocate as much RAM as possible to the memory test while staying below the limit that would force out of memory (OOM) kills. This version of the test always runs.
In both iterations of the memory test, malloc() is used to allocate RAM, the RAM is dirtied with a write of an arbitrary hex string (0xDEADBEEF), and a test is performed to ensure that 0xDEADBEEF is actually stored in RAM at the expected addresses. The test calls free() to release RAM when testing is complete. Multiple threads or multiple processes will be used to allocate the RAM depending on whether the process size is greater than or less than the amount of memory to be tested.
Preparing for the test: Install the correct amount of RAM in the system in accordance with the rules in the Policy Guide.
Executing the test: The memory test is non-interactive. Check the checkbox next to the test and click the Run Selected button to perform the test.
Run time, bare-metal: The memory test takes about 16 minutes to run on a 2013-era, single CPU, 6-core/12-thread 3.3GHz Intel-based workstation with 8GB of RAM running Red Hat Enterprise Linux 6.4, AMD64 and Intel 64. The test will take longer on systems with more RAM. The required info test will add about a minute to the overall run time.
Run time, full-virt guest: The fv_memory test takes slightly longer than the bare-metal version, about 18 minutes, to run in a guest. The added time is due to guest startup/shutdown activities and the required info test that runs in the guest. The required info test on the bare-metal system will add about a minute to the overall run time. The fv_memory test run times will not vary as widely from machine to machine as the bare-metal memory tests, as the amount of RAM assigned to our pre-built guest is always the same. There will be variations caused by the speed of the underlying real system, but the amount of RAM in use during the test won't change from machine to machine.

Note

A note about FV testing times: The first time you run any full-virt test, the system under test will need to acquire the FV guest files. If these files are located on the local test server and you are using 1GbE or faster networking, that will take only a minute or two to transfer the ~300MB of guest files. If the files are retrieved from the Red Hat FTP server, which happens automatically if the guest files are not installed or not found on the local test server, the first runtime will depend on the speed of the FTP transfer. Once the guest files are installed, they will be used for all subsequent runs of fv_* tests.

⁠A.1.26. network

What the test covers: The network test is used to test devices whose function is transferring data over a network. This includes wired Ethernet cards, wireless Ethernet cards, virtual network devices on systems that support SR-IOV, and InfiniBand cards if IB is being used as a network protocol. The test will appear as network for non-Ethernet devices, or as different names for Ethernet or Wi-Fi devices:

Note

If a device's PCI class code is 60A00 or C0600 or if the device driver is split into modules such as mlx4_core, mlx5_core or mlx5_ib, the suite will plan Infiniband tests.
  • 1GigEthernet - The network test with added speed detection for 1 gigabit Ethernet connections.
  • 10GigEthernet - The network test with added speed detection for 10 gigabit Ethernet connections.
  • 20GigEthernet - The network test with added speed detection for 20 gigabit Ethernet connections.
  • 25GigEthernet - The network test with added speed detection for 25 gigabit Ethernet connections.
  • 40GigEthernet - The network test with added speed detection for 40 gigabit Ethernet connections.
  • 50GigEthernet - The network test with added speed detection for 50 gigabit Ethernet connections.
  • 100GigEthernet - The network test with added speed detection for 100 gigabit Ethernet connections.

    Note

    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.

    Note

    If you see a test named Ethernet in your local test plan, that is an indication that the test suite did not recognize the speed for that device. Please check the connection before attempting to test that particular device. See Section A.1.15, “Ethernet” for more information.
  • WirelessG - The network test with added speed detection for 802.11g wireless Ethernet connections.
  • WirelessN - The network test with added speed detection for 802.11n wireless Ethernet connections.
  • WirelessAC - The network test with added speed detection for 802.11ac wireless Ethernet connections.
What the test does: The test gathers information on all the network devices and runs this procedure:
  1. Bounce the interface ( ifdown, ifup) being tested, as long as the root partition is not on an NFS mount. If we were running on NFS root, the system would never come back after losing its connection to root.
  2. ifdown all interfaces not under test.
  3. Create a test file of random data (using /dev/urandom) the size of which is tuned to the speed of your NIC.
  4. TCP testing - A TCP latency test ( lat_tcp) is run 5 times. This test watches to see if the system runs into any OS timeouts, which would cause the test to fail. It's followed by a TCP bandwidth test ( bw_tcp). For wired devices, we expect the speed to be close to the theoretical maximum.
  5. UDP testing - A UDP latency test ( lat_udp) is run and the script watches to see if the system runs into any OS timeouts.
  6. HTTP file transfer testing - The script uploads the random testfile created in step three via HTTP multi-part form enclosure, then downloads it via HTTP GET. It times how long it takes to upload and download the file, and verifies the contents of the original to the second generation copy.
  7. ICMP (ping) test - The script causes a ping flood at the default packet size to make sure nothing in the system fails (the system should not restart/reset or oops or anything else that indicates the inability to withstand a ping flood.). 5000 packets are sent, and a 100% success rate is expected. The test will retry 5 times for an acceptable success rate.
  8. The final action of the test is to bring all interfaces back to where they started, either active or inactive depending on their state when the test was launched.
Preparing for testing wired devices: You may test as many network devices from the official test plan as you wish in each run of the test suite. Connect each device at its native (maximum) speed or the test will fail. Ensure that the hwcert network test server is up and running before beginning, and make sure that each network device has an IP address assigned either statically or via DHCP.
If any network devices support partitioning, we need to see them demonstrate both full-speed data transfer and the partitioning function in one or more runs of the network test. This requirement will be accounted for in the official test plan by having two entries for each NIC that supports partitioning. If the NIC can run at full speed while it's partitioned, please configure a partition with the NIC running at its native speed and perform your network tests in that configuration. This single test run will satisfy both official test plan entries for the NIC.
If the NIC cannot run at full speed while it's partitioned, please perform one network test without partitioning so that we can see full-speed operation, and then perform another network test with partitioning enabled so that we can see a demonstration of the partitioning function. We recommend that you choose either 1Gb/s or 10Gb/s for your partitioned configuration so that it conforms to one of our existing network speed tests.
Preparing for testing wireless Ethernet devices: In Red Hat Enterprise Linux 6 and Red Hat Enterprise Linux 7, any system with a supported wireless card will automatically receive any necessary firmware package(s) at install time and all configuration of the cards can be done with the NetworkManager graphical tool. Simply select an SSID on a test network that does not require any additional user input during up/down operations (no authentication requests, VPN login, etc.) and you can run the test as explained in the "Executing the test" section below.

Note

Based on the wireless card which is being tested, the wireless access point that you connect to should be capable of performing WirelessG, WirelessN and WirelessAC network tests.
Executing the test: The network test is non-interactive. Check the checkbox next to the test and click the Run Selected button to perform the test.
Run time: The network test takes about 21 minutes for each PCIe-based, gigabit, wired Ethernet card that is being tested. We'll add 10GbE test times and wireless times at a future date. The required info test will add about a minute to the overall run time.

⁠A.1.27. pccard (Red Hat Enterprise Linux 6 only)

What the test covers: The pccard test covers PC Cards (also known as PCMCIA cards).
What the test does: The test uses the /sbin/pccardctl command to control the system's pccard sockets individually. It loops through all the sockets and performs three actions: a power off, power on and a card query to get the identity of the inserted card(s).
Preparing for the test: Each card slot must be populated before running the test. The /sbin/pccardctl utility has the ability to turn the slots off and on, simulating an eject and an insert, so the tester is not prompted to insert cards at test time.
Executing the test: The pccard test is non-interactive. Check the checkbox next to the test and click the Run Selected button to perform the test.

⁠A.1.28. profiler

What the test does: The profiler test will attempt to shut down oprofile to get a clean slate, then bring it up correctly (start the daemon). It will load all the oprofile modules and a handful of additional support items (for example, some directories under /dev are mounted), then it will start the oprofile application. The application will acquire some sample data, called a report, then quit. If all those steps are completed successfully, the test passes. There is another loop in the test that is executed if one of those actions fails. The oprofile application requires specific hardware registers in the CPU to record its data. If for some reason this dedicated support is not working (or the hardware counters are not present), the other loop enables timer mode, allowing the data to be recorded in software instead of in the CPU registers. If you encounter failures in the profiler test, try forcing timer mode by adding this line to /etc/modprobe.conf and then rebooting before attempting to run the test again: 
options oprofile timer=1
Preparing for the test: To prepare for the test, ensure that a CPU is installed that meets the requirements explained in the Policy Guide.
Executing the test: The profiler test is non-interactive. Check the checkbox next to the test and click the Run Selected button to perform the test.
Run time: The profiler test takes approximately 30 seconds on a 2013-era workstation. The required info test will add about a minute to the overall run time.

⁠A.1.29. realtime

Note

This test only runs when certifying hardware on the Red Hat Enterprise Linux for Real Time product on Red Hat Enterprise Linux 7.
What the test covers: The realtime test covers the testing of systems running Red Hat Enterprise Linux for Real Time with two sets of tests: one to find system management mode-based execution delays, and one to determine the latency of servicing timer events.
What the test does: The first portion of the test loads a special kernel module named hwlat_detector.ko. This module creates a kernel thread which polls the Timestamp Counter Register (TSC), looking for intervals between consecutive reads which exceed a specified threshold. Gaps in consecutive TSC reads mean that the system was interrupted between the reads and executed other code, usually System Management Mode (SMM) code defined by the system BIOS.
The second part of the test starts a program named cyclictest, which starts a measurement thread per cpu, running at a high realtime priority. These threads have a period (100 microseconds) where they perform the following calculation:
  1. get a timestamp (t1)
  2. sleep for period
  3. get a second timestamp (t2)
  4. latency = t2 - (t1 + period)
  5. goto 1
The latency is the time difference between the theoretical wakeup time (t1+period) and the actual wakeup time (t2). Each measurement thread tracks minimum, maximum and average latency as well as reporting each datapoint.
Once cyclictest is running, rteval starts a pair of system loads, one being a parallel linux kernel compile and the other being a scheduler benchmark called hackbench.
When the run is complete, rteval performs a statistical analysis of the data points, calculating mean, mode, median, variance and standard deviation.
Preparing for the test: Install and boot the realtime kernel-rt kernel before adding the system to the certification. The command will detect that the running kernel is a realtime kernel and will schedule the realtime test to be run.
Running the test: The realtime test is non-interactive. Check the checkbox next to the test and click the Run Selected button to perform the test. The test will only appear when the system is running the rt-kernel.
Run time: The system management mode portion of the test runs for two hours. The timer event analysis portion of the test runs for twelve hours on all machines. The required info test will add about a minute to the overall run time.

⁠A.1.30. reboot (Optional)

What the test covers: The reboot test confirms the ability of a system to reboot when prompted. It is not required for certification at this time.
What the test does: The test issues a shutdown -r 0 command to immediately reboot the system with no delay.
Preparing for the test: Ensure that the system can be rebooted before running this test by closing any running applications.
Executing the test: The reboot test is interactive. Click the Run Interactive button next to the test name to begin. You will be asked Ready to restart? when you reach the reboot portion of the test program. Answer y if you are ready to perform the test. The system will reboot and after coming back up, the test server will verify that the reboot completed successfully.

⁠A.1.31. storage

What the storage test covers: There are many different kinds of persistent on-line storage devices available in systems today. The storage test is designed to test anything that reports an ID_TYPE of "disk" in the udev database. This includes IDE, SCSI, SATA, SAS, and SSD drives, PCIe SSD block storage devices, as well as SD media, xD media, MemoryStick and MMC cards. The test plan script reads through the udev database and looks for storage devices that meet the above criteria. When it finds one, it records the device and its parent and compares it to the parents of any other recorded devices. It does this to ensure that only devices with unique parents are tested. If the parent has not been seen before, the device is added to the test plan. This speeds up testing as only one device per controller will be tested, as per the Policy Guide.
What the test does: The storage test performs the following actions on all storage devices with a unique parent:
  1. The script looks through the partition table to locate a swap partition that is not on an LVM or software RAID device. If found, it will deactivate it with swapoff and use that space for the test. If no swap is present, the system can still test the drive if it is completely blank (no partitions). Note that the swap device must be active in order for this to work (the test reads /proc/swaps to find the swap partitions) and that the swap partition must not be inside any kind of software-based container (no LVM or software RAID, but hardware RAID would work as it would be invisible to the system).
  2. The tool creates a filesystem on the device, either in a swap partition on the blank drive.
  3. The filesystem is mounted and dt is used to test the device. The dt command is the "data test" program and is a generic test tool capable of testing reads and writes to devices (among other things).
  4. After the mounted filesystem test, the filesystem is unmounted and a dt test is performed against the block device, ignoring the file system. The dt test uses the "direct" parameter to handle this.
Preparing for the test: You should install all the drives and storage controllers that are listed on the official test plan. In the case of multiple storage options, as many as can fit into the system at one time can be tested in a single run, or each storage device can be installed individually and have its own run of the storage test. The order of testing and number of controllers present for each test is left up to you. Each logical drive attached to the system must contain a swap partition in addition to any other partitions, or be totally blank. This is to provide the test with a location to create a filesystem and run the tests. The use of swap partitions will lead to a much quicker test, as devices left blank are tested in their entirety. They will almost always be significantly larger than a swap partition placed on the drive. Please see the Red Hat Knowledgebase article at https://access.redhat.com/site/solutions/15244 for more information on appropriate swap file sizing.

Note

If testing an SD media card, use the fastest card you can obtain. While a Class 4 SD card may take 8 hours or more to run the test, a Class 10 or UHS 1/2 card can complete the test run in 30 minutes or less.
When it comes to choosing storage devices for the official test plan, the rule that the review team operates by is "one test per code path". What we mean by that is that we want to see a storage test run using every driver that a controller can use. The scenario of multiple drivers for the same controller usually involves RAID storage of some type. It's common for storage controllers to use one driver when in regular disk mode and another when in RAID mode. Some even use multiple drivers depending on the RAID mode that they are in. The review team will analyze all storage hardware to determine the drivers that need to be used in order to fulfill all the testing requirements. That's why you may see the same storage device listed more than once in the official test plan. Complete information on storage device testing is available in the Policy Guide.
Executing the test: The storage test is non-interactive. Check the checkbox next to the test and click the Run Selected button to perform the test. 
Host bus adapter host0 has storage devices sda, sda1, sda2, sda3
Which disk would you like to test:  (sda|sda1|sda2|sda3|all)
Run time, bare-metal: The storage test takes approximately 22 minutes on a 6Gb/s SATA hard drive installed in a 2013-era workstation system. The same test takes approximately 3 minutes on a 6Gb/s SATA solid-state drive installed in a 2013-era workstation system. The required info test will add about a minute to the overall run time.

⁠A.1.32. suspend (Laptops only)

What the test covers: The suspend test covers suspend/resume from S3 sleep state (suspend to RAM) and suspend/resume from S4 hibernation (suspend to disk). This test is only scheduled on systems that have built-in batteries, like laptops, so it won't be present on any other type of system.

Important

The suspend to RAM and suspend to disk abilities are essential characteristics of laptops. We therefore schedule an automated suspend test at the beginning of all certification test runs on a laptop. This ensures that all hardware functions normally post-resume. The test will always run on a laptop, much like the info test, regardless of what tests are scheduled.
What the test does: The test queries the /sys/power/state file and determines which states are supported by the hardware. If it sees "mem" in the file, it schedules the S3 sleep test. If it sees "disk" in the file, it schedules the S4 hibernation test. If it sees both, it schedules both. What follows is the procedure for a system that supports both S3 and S4 states. If your system does not support both types it will only run the tests related to the supported type.
  • If S3 sleep is supported, the script uses the pm-suspend command to suspend to RAM. The tester wakes the system up after it sleeps and the scripts check the exit code of pm-suspend to verify that the system woke up correctly. Testing then continues on the test server interface.
  • If S4 hibernation is supported, the script uses the use the pm-suspend command to suspend to disk. The tester wakes the system up after it hibernates and the scripts check the exit code of pm-suspend to verify that the system woke up correctly. Testing then continues on the test server interface.
  • If S3 sleep is supported, the tester is prompted to press the key that manually invokes it (a Fn+ F-key combination or dedicated Sleep key) if such a key is present. The tester wakes the system up after it sleeps and the scripts check the exit code of pm-suspend to verify that the system woke up correctly. Testing then continues on the test server interface. If the system has no suspend key, this section can be skipped.
  • If S4 hibernation is supported, the tester is prompted to press the key that manually invokes it (a Fn+ F-key combination or dedicated Hibernate key) if such a key is present. The tester wakes the system up after it hibernates and the scripts check the exit code of pm-suspend to verify that the system woke up correctly. Testing then continues on the test server interface. If the system has no suspend key, this section can be skipped.
Preparing for the test: Ensure that a swap file large enough to hold the contents of RAM was created when the system was installed. Guidelines for swap file size can be found at this Red Hat Knowledgebase article: https://access.redhat.com/site/solutions/15244. Also, someone must be present at the system under test in order to wake it up from suspend and hibernate.
Executing the test: The suspend test is interactive. Click the Run Interactive button next to the test name to begin, or start any test run on a laptop. The test server GUI will display a status of suspend? when the test runs. Click on the suspend? status link or the Continue Testing button and then click the Yes button to suspend the laptop.
The test server will display waiting for response after it sends the suspend command. Check the laptop and confirm that it has completed suspending, then press the power button or any other key that will wake it from suspend. The test server will continuously monitor the system under test to see if it has awakened. Once it has woken up, the test server GUI will display the question Has resume completed?. Press the Yes or No button to tell the test server what happened.
The server will then continue to the hibernate test. Again, click the Yes button under the suspend? question to put the laptop into hibernate mode.
The test server will display waiting for response after it sends the hibernate command. Check the laptop and confirm that it has completed hibernating, then press the power button or any other key that will wake it from hibernation. The test server will continuously monitor the system under test to see if it has awakened. Once it has woken up, the test server GUI will display the question has resume completed?. Press the Yes or No button to tell the test server what happened.
Next the test server will ask you if the system has a keyboard key that will cause the system under test to suspend. If it does, click the Yes button under the question Does this system have a function key (Fn) to suspend the system to mem?. Follow the procedure described above to verify suspend and wake the system up to continue with testing.
Finally the test server will ask you if the system has a keyboard key that will cause the system under test to hibernate. If it does, click the Yes button under the question Does this system have a function key (Fn) to suspend the system to disk? Follow the procedure described above to verify hibernation and wake the system up to continue with any additional tests you have scheduled.
Run time: The suspend test takes about 6 minutes on a 2012-era laptop with 4GB of RAM and a non-SSD hard drive. This is the time for a full series of tests, including both pm-suspend-based and function-key-based suspend and hibernate runs. The time will vary depending on the speed at which the laptop can write to disk, the amount and speed of the RAM installed, and the capability of the laptop to enter suspend and hibernate states through function keys. The required info test will add about a minute to the overall run time.

⁠A.1.33. tape

What the test covers: The tape test covers all types of tape drives. Any robots associated with the drives are not tested by this test.
What the test does: The test uses the mt command to rewind the tape, then it does a tar of the /usr directory and stores it on the tape. A tar compare is used to determine if the data on the tape matches the data on the disk. If the data matches, the test passes.
Preparing for the test: Insert a tape of the appropriate size into the drive.
Executing the test: The tape test is non-interactive. Check the checkbox next to the test and click the Run Selected button to perform the test.

⁠A.1.34. USB2

What the test covers: The USB2 test covers USB2 ports from a basic functionality standpoint, ensuring that all ports can be accessed by the OS.
What the test does: The purpose of the test is to ensure that all USB2 ports present in a system function as expected. It asks for the number of available USB2 ports (minus any that are in use for keyboard/mouse, etc.) and then asks the tester to plug and unplug a USB2 device into each port. The test watches for attach and detach events and records them. If it detects both plug and unplug events for the number of unique ports the tester entered, the test will pass.
Preparing for the test: Count the available USB2 ports and have a spare USB2 device available to use during the test. You may need to trace the USB ports from the motherboard header(s) to distinguish between USB2 and USB3 ports.
Executing the test: The USB2 test is interactive. Click the Run Interactive button next to the test name to begin. When prompted by the system, enter the number of available USB2 ports present on the system. Don't count any that are currently in use by keyboards or mice. The system will ask for the test USB2 device to be plugged into a port and will then pause until the tester presses y to continue. The system will then ask for the device to be unplugged and again will pause until the tester presses y to continue. These steps repeat for the number of ports that were entered. Note that there is no right or wrong order for testing the ports, but each port must be tested only once.
Run time: The USB2 test takes about 15 seconds per USB2 port. This includes the time to manually plug in the device, scan the port, unplug the device, and scan the port again. The required info test will add about a minute to the overall run time.

⁠A.1.35. USB3

What the test covers: The USB3 test covers USB3 ports from a basic functionality standpoint, ensuring that all ports can be accessed by the OS.
What the test does: The purpose of the test is to ensure that all USB3 ports present in a system function as expected. It asks for the number of available USB3 ports (minus any that are in use for keyboard/mouse, etc.) and then asks the tester to plug and unplug a USB3 device into each port. The test watches for attach and detach events and records them. If it detects both plug and unplug events for the number of unique ports the tester entered, the test will pass.
Preparing for the test: Count the available USB3 ports and have a spare USB3 device available to use during the test. You may need to trace the USB ports from the motherboard header(s) to distinguish between USB2 and USB3 ports.
Executing the test: The USB3 test is interactive.Click the Run Interactive button next to the test name to begin. When prompted by the system, enter the number of available USB3 ports present on the system. Don't count any that are currently in use by keyboards or mice. The system will ask for the test USB3 device to be plugged into a port and will then pause until the tester presses y to continue. The system will then ask for the device to be unplugged and again will pause until the tester presses y to continue. These steps repeat for the number of ports that were entered. Note that there is no right or wrong order for testing the ports, but each port must be tested only once.
Run time: The USB3 test takes about 15 seconds per USB3 port. This includes the time to manually plug in the device, scan the port, unplug the device, and scan the port again. The required info test will add about a minute to the overall run time.

⁠A.1.36. video

What the test covers: All video hardware, whether removeable or integrated on the motherboard, is tested using the video test. Devices are selected for testing by their PCI class ID. Specifically, the test is looking for a device class of "30000" in the output of udev.
What the test does: The video test first determines which command is used to control the X configuration on the machine where it is running (either redhat-config-xfree86 or system-config-display). It then runs it with the --noui flag and generates a clean X configuration file. It runs startx using the new configuration file and runs x11perf, which is a X11 server performance test program. After the performance test completes it also runs xdpyinfo to determine the screen resolution and color depth. The configuration file created at the start of the test should allow the system to run at the maximum resolution that the monitor and video card are capable of achieving. The final potion of the test uses grep to search through the /var/log/Xorg.0.log logfile to determine which driver is being used.
Preparing for the test: Ensure that the monitor and video card in the system are capable of running at a resolution of 1024x768 with a color depth of 24 bits per pixel (bpp). This is the minimum resolution and color depth required to achieve a passing video test. Higher resolutions or color depths are also acceptable, but nothing lower than 1024x768 at 24bpp will pass. You can confirm this ability by looking at the output of xrandr. All the resolutions that can be achieved by the monitor and video card should be displayed in the output of xrandr. Check the output for 1024x768 at 24 bits per pixel (or higher). You may need to remove any KVM switches that are between the monitor and video card if you are not seeing all the resolutions that the card/monitor combination are capable of generating.
Executing the test: The video test is non-interactive. Check the checkbox next to the test and click the Run Selected button to perform the test. The screen on the test system will go blank, followed by a series of test patterns from the x11perf test program. It will return to the desktop or to the virtual terminal screen that the system was on at execution time when the test finishes.
Run time: The video test takes about 1 minute to perform on a 2013-era workstation. The required info test will add about a minute to the overall run time.

⁠A.1.37. WirelessG

What the test covers: The WirelessG test is run on all wireless Ethernet connections with a maximum connection speed of 802.11g.
What the test does: This is a new test that combines the existing wlan and network tests. In addition to passing all the existing network test items, this test must detect a "g" link type as reported by iw and demonstrate a throughput of 22Mb/s (with a margin for overhead) in order to pass. Please see Section A.1.26, “network” for information on the rest of the test functionality.

⁠A.1.38. WirelessN

What the test covers: The WirelessN test is run on all wireless Ethernet connections with a maximum connection speed of 802.11n.
What the test does: This is a new test that combines the existing wlan and network tests. In addition to passing all the existing network test items, this test must detect an "n" link type as reported by iw and demonstrate a throughput of 100Mb/s (with a margin for overhead) in order to pass. Please see Section A.1.26, “network” for information on the rest of the test functionality.

⁠A.1.39. WirelessAC (Red Hat Enterprise Linux 7 only)

Note

The WirelessAC test will not plan automatically at this time, as we are waiting for full 802.11ac support to be incorporated into Red Hat Enterprise Linux. All 802.11ac-capable systems will have the WirelessN test planned instead, and only "N" speeds are required to pass the test.
What the test covers: The WirelessAC test is run on all wireless Ethernet connections with a maximum connection speed of 802.11ac.
What the test does: This is a new test that combines the existing wlan and network tests. In addition to passing all the existing network test items, this test must detect an "ac" link type as reported by iw and demonstrate a throughput of 300Mb/s (with a margin for overhead) in order to pass. Please see Section A.1.26, “network” for information on the rest of the test functionality.

⁠A.2. Manually Adding Tests

On rare occasions, tests may fail to plan due to problems with hardware detection or other issues with the hardware, OS, or test scripts. If this happens you should get in touch with your Red Hat support contact for further assistance. They will likely ask you to open a support ticket for the issue, and then explain how to manually add a test to your local test plan using the rhcert-cli command on the SUT. Any modifications you make to the local test plan will be sent to the LTS, so you can continue to use the web interface on the LTS to run your tests. The command is run as follows: 
# rhcert-cli plan --add --test=<testname> --device=<devicename> --udi-<udi>
The options for the rhcert-cli command used here are:
  • plan - Modify the test plan
  • --add - Add an item to the test plan
  • --test=<testname> - The test to be added. The test names are as follows:
    • hwcert/suspend
    • hwcert/audio
    • hwcert/battery
    • hwcert/lid
    • hwcert/usbbase/expresscard
    • hwcert/usbbase/usbbase/usb2
    • hwcert/usbbase/usbbase/usb3
    • hwcert/kdump
    • hwcert/network/Ethernet/100MegEthernet
    • hwcert/network/Ethernet/1GigEthernet
    • hwcert/network/Ethernet/10GigEthernet
    • hwcert/network/Ethernet/40GigEthernet
    • hwcert/network/wlan/WirelessG
    • hwcert/network/wlan/WirelessN
    • hwcert/network/wlan/WirelessAC (available in Red Hat Enterprise Linux 7 only)
    • hwcert/memory
    • hwcert/core
    • hwcert/cpuscaling
    • hwcert/fvtest/fv_core
    • hwcert/fvtest/fv_memory
    • hwcert/fvtest/fv_network
    • hwcert/fvtest/fv_storage
    • hwcert/profiler
    • hwcert/storage
    • hwcert/video
    • hwcert/info
    • hwcert/optical/bluray
    • hwcert/optical/dvd
    • hwcert/optical/cdrom
    • hwcert/fencing
    • hwcert/realtime
    • hwcert/reboot
    • hwcert/tape
  • The other options are only needed if a device must be specified, like in the network and storage tests that need to be told which device to run on. There are various places you would need to look to determine the device name or UDI that would be used here. Support can help determine the proper name or UDI. Once found, you would use one of the following two options to specify the device:
    • --device=<devicename> - The device that should be tested, identified by a device name such as "enp0s25" or "host0".
    • --udi=<UDI> - The unique device ID of the device to be tested, identified by a UDI string.

⁠Appendix B. Revision History

Revision 2.0-24Mon Mar 6 2017Silas Silas
bumping to r24 for testing
Revision 2.0-22Mon Mar 6 2017Silas Silas
bumping to r22 for testing
Revision 2.0-21Friday, February 17 2017Gary Case
Updated GUI screenshots and directions to match v4.4 of the tool
Removed references to old Bugzilla accounts
Removed references to deprecated redhat-certification-information package
Updated RHEL download URL structure
Replace "rhcert-backend" commands with appropriate replacement
Removed references to MRG Realtime product as it is no longer eligible for certification
Revision 2.0-20Thursday, December 22 2016Nidhi Srinivas
Added an example of leveraging of existing results.
Revision 2.0-19Thursday, December 22 2016Nidhi Srinivas
Added an example of leveraging of existing results.
Revision 2.0-18Thursday, October 6 2016Nidhi Srinivas
Added an example of leveraging of existing results.
Revision 2.0-15Thursday, October 6 2016Nidhi Srinivas
Merging the current changes.
Revision 2.0-14Wednesday, September 7 2016Nidhi Srinivas
Added a note about Infiniband tests.
Revision 2.0-13Thursday, August 25 2016Nidhi Srinivas
Removed the entries on MB/s and fixed text.
Revision 2.0-12Wednesday, August 24 2016Nidhi Srinivas
Fixed the screenshots in the topics on creating a new certification
Revision 2.0-11Wednesday, August 24 2016Nidhi Srinivas
Fixed the screenshots in the topics on creating a new certification
Revision 2.0-10Tuesday, August 16 2016Nidhi Srinivas
Added SSO and CWE dialog changes
Revision 2.0-9Tuesday, August 16 2016Nidhi Srinivas
Added SSO and CWE dialog changes
Revision 2.0-8Thursday, August 4 2016Nidhi Srinivas
Publishing the guide on the portal after the recent fixes as part of issue ID CERTPM-795
Revision 2.0-7Thursday, August 4 2016Nidhi Srinivas
Publishing the guide on the portal after the recent fixes as part of issue ID CERTPM-795
Revision 2.0-6Tuesday, May 3 2016Nidhi Srinivas
Publishing the guide on the portal after the recent fixes committed by Gary.
Combined the information about submitting feedback for managed and non-managed partners in a single topic "Troubleshooting Issues and Submitting Feedback"
Revision 2.0-5Friday, April 29 2016Nidhi Srinivas
Publishing the guide on the portal after the recent fixes committed by Gary.
Revision 2.0-4Thursday, April 28 2016Nidhi Srinivas
Publishing the guide on the portal after the recent fixes.
Revision 2.0-3Thursday, April 28 2016Nidhi Srinivas
Publishing the guide on the portal after the recent fixes.
Revision 2.0-2Friday, December 18 2015Nidhi Srinivas
Publishing the guide on the portal after the recent fixes.
Revision 2.0-1Wednesday, December 16 2015Gary Case
Removed document convention preface section
Revision 2.0-0Wednesday, November 18 2015Gary Case
Pointed to temporary locations for test suite packages
Updated "Preparing the Test Environment" section to include new files and dependencies for 2.0 revision of test tool
Rewrote "Scheduling and Running Tests with the Red Hat Certification Tool" to use new procedures and graphics in 2.0
Updated "Submitting Results" section for new upload procedures
Graphics updates throughout
Added new appendix that details manual test planning
Revision 1.4-0Tuesday, June 30 2015Gary Case
Changed local storage location for pre-built guests on local test server
Made necessary changes to indicate that RHEL 6 is now using a RHEL 6-based guest instead of RHEL 5
Updated 40GigEthernet test information to indicate that the test is present for RHEL 6
Updated kickstart file locations to temporarily point to people.redhat.com FTP site
Removed unneeded references to kernel-rt debug/debuginfo kernels
Added temporary download locations for certification test suite packages
Converted the hwcert-based user guide to cover the new redhat-certification test suite
Revision 1.3-4Monday, April 24 2015Gary Case
Removed unnecessary directions for installing debuginfo packages for MRG Reatime and Real Time kernels. Debuginfo packages are used in kdump tests and these only run on the regular kernels.
Added partitioning directions to the 'network' test section of the appendix
Updated 'realtime' test procedure to reflect new test method
Updated download directions for debuginfo packages to use new Customer Portal location
Revision 1.3-3Monday, March 2 2015Gary Case
Updated kickstart files with new naming convention
Added section for Red Hat Enterprise Linux for Real Time
Added notices that MRG Realtime and Real Time need the newest version of both RHEL and RT
Added updated information throughout for Real Time
Removed references to Red Hat Enterprise Linux 5
Updated Red Hat Enterprise Linux test procedure and examples to reflect latest version of hwcert tools
Updated MRG Realtime test procedure
Updated Red Hat Enterprise Linux OpenStack Platform Compute test procedure
Updated Red Hat Storage Server test procedure
Updated pictures to reflect new certification site
Removed outdated troubleshooting section
General updates to reflect new catalog procedures
Revision 1.3-2Friday, Oct 17 2014Gary Case
Updated the titles in section three
Added a component pass-through section to the process summary
Updated directions for purchasing program membership
Revision 1.3-1Thursday, Aug 7 2014Gary Case
Updated the "Preparing the Test Environment" section with Red Hat Enterprise Linux 7 links
Changed incorrect references to non-existent "hwcert-info" package to use the correct "hwcert-client-info" name
Revision 1.3-0Thu Apr 24 2014Gary Case
Updated the "Opening a Standard Certification Request" section for Red Hat Enterprise Linux 7
Updated the "Opening a Hardware Specification Entry" section for Red Hat Enterprise Linux 7
Updated the "Preparing the Test Environment" section for Red Hat Enterprise Linux 7
Updated the "Using Locally-Hosted Pre-Built Guest Files" section for Red Hat Enterprise Linux 6 and 7
Updated the "Certifying for Red Hat Enterprise Linux Open Stack Platform Compute" section for Red Hat Enterprise Linux 7
Updated the "Certifying for Red Hat Storage Server" section
Added a "Preparing a Kickstart File to Install Red Hat Enterprise Linux 7 and hwcert-client" section
Added a "Certifying for Red Hat Enterprise Virtualization Hypervisor" section
Added a 40GigEthernet test section
Added a WirelessAC test section
Added information on how to open Red Hat Storage Server certifications
Updated the fv_network section to add new SR-IOV recommendations
Updated swap partition recommendations for all versions of Red Hat Enterprise Linux
Updated the 'kdump' section to clarify what to do during and after the reboots
Updated the "Using Locally-Hosted Pre-Built Guest Files" section with a new RHEL 6 local test server FV image directory
Updated the "Using Locally-Hosted Pre-Built Guest Files" section with a new Red Hat Enterprise Linux 6 local test server FV image directory
Revision 1.2-3Tue Jan 14 2014Gary Case
Added component pass-through certification details.
Revision 1.1-0Wed Nov 7 2013Gary Case
Added explanation for the new Hardware Specification entries.
Added new Red Hat Enterprise Linux 6-only network tests.
Rewrote the locally hosted pre-built guest section, greatly simplifying the directions there.
Revision 1.0-0Mon Aug 12 2013Gary Case
Added explanation for the new Hardware Specification entries.
Added new Red Hat Enterprise Linux 6-only network tests.
Added new Red Hat Enterprise Linux 6-only USB tests.
Simplified virt guest file directions for hosting files locally.
Documentation updated for new 'hwcert' package and moved to the Red Hat Customer Portal.

Logo
Linux

更多推荐

网卡速率和双工模式的配置

http://linux.chinaitlab.com/system/792187.html1、mii-tool 配置网络设备协商方式的工具；    1.1 mii-tool 介绍；    mii-tool - view, manipulate media-independent interface status （mii-tool 是查看，管理介质的网络接口的状态）

avatar Linux

Linux虚拟文件系统之文件系统卸载（sys_umount())

Linux中卸载文件系统由umount系统调用实现，入口函数为sys_umount()。较于文件系统的安装较为简单，下面是具体的实现。1. /*sys_umont系统调用*/2. SYSCALL_DEFINE2(umount, char __user *, name, int, flags)3. {4.struct path path;

avatar Linux

Linux系统下超级终端Minicom的使用方法（例如：连接交换机，路由器等）转http://baike.baidu.com/view/2911642.htm?fr=ala0_1

<br />　　Linux系统下超级终端Minicom的使用方法 <br />　　Linux下的Minicom的功能与下的超级终端功能相似，适于在通过超级终端对设备的管理以及对嵌入操作系统的升级，现写出Minicom的使用手册： <br />　　1． 启动minicom <br />　　以root权限登录系统 <br />　　使用命令 <br />　　minicom –s 则minicom启动，屏

avatar Linux