Search

Chapter 4. Creating a test plan

download PDF

4.1. Overview of test plan

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

  1. Define the model by its specification.
  2. Determine the option.
  3. Remove unsupported operating system features and unintentional hardware.
  4. Apply the minimum test set criteria.
  5. Add the install, boot, and kdump requirements.
  6. Add additional policy requirements.

After performing the steps above, the items remaining determine the test plan for your hardware. The Hardware Catalog records the test plan under the Test Plan Progress.

Additional resources

Note

Red Hat Hardware Certification Test Plans are not meant to substitute for proper and complete internal quality assurance testing, criteria, and processes. Each vendor is responsible for their own internal shipment criteria and is encouraged to do testing in excess of the required certification test plan items.

4.2. Models

The Red Hat Hardware Certification program certifies entire hardware models, rather than specific configurations of models. A model includes all Integrated Hardware and Optional Hardware as described by the Hardware Partner in the hardware specification.

4.2.1. Model names

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

The Red Hat Hardware Certification program supports tiered naming schemes. A tiered naming scheme is any naming scheme that includes a hierarchical collection of models and submodels. When employing tiered naming schemes for the purposes of certification the specification is considered to include all submodels which would reasonably be represented by the name provided in the certification request.

For example; consider three model names: 3000, 3000a, and 3000s. If 3000 represents the collection that includes the 3000a and 3000s models, submitting 3000 as the model name incorporates the specifications of 3000a and 3000s. Conversely, if 3000s is submitted, the specification is limited to only the hardware detailed in the 3000s specification. In cases where 3000 is a distinct model separate from 3000a and 3000s, the certification will only consider the hardware outlined in the 3000 specification. The published model name may be altered for clarity in certain situations. Any changes should be discussed during the certification process and prior to publication. Such alterations are made at the discretion of Red Hat.

4.3. Specifications

To maintain consistency and accuracy in hardware specifications, ensure to provide the same specifications to both Red Hat and customers. Also, follow the listed guidelines to guarantee precise and comprehensive hardware specifications:

  • Provide a publicly accessible URL containing all available specifications for the hardware. This URL should host the finalized, public specifications. Early specifications can be submitted before the product’s official launch, even in different formats. However, these early specifications must align with the format and structure of the final customer specifications, as Red Hat will validate them against the finalized public specifications before publication.
  • For any generalized specifications, you must provide precise and detailed information to Red Hat. For example, while mentioning "10gig Ethernet," you must specify the manufacturer such as Broadcom, Intel, Mellanox, or any other specific variant. Additionally, we recommend including the specific device model, like 'Intel 40GbE XL710-QDA’, this allows Red Hat in creating test plans more efficiently.
  • In cases where generalized specifications can be interpreted in multiple ways or cover a range of possibilities, you must provide clear details to Red Hat. For example, if your hardware can potentially support up to 80 cores, but you intend to offer only 40 cores, Red Hat will consider the 40-core limit for certification purposes. However, If you plan to offer more than 40 cores to customers, a supplemental certification will be necessary before such configurations can be made available.

4.4. Types of options

It is important to understand the different types of options that can be associated with a model when certifying hardware. These options help define what components are included and how they impact the certification process.

4.4.1. Integrated hardware

Integrated Hardware is the hardware required to be present in all configurations of a model. All integrated hardware components, including CPU options, memory options, integrated graphic controllers, integrated displays, and other non-field-removable hardware within a model, must be tested. This includes features integrated into System-on-Chip (SoC), System-in-Package (SiP), and other fully or partially integrated system solution designs. Specific portions of integrated hardware may be exempted from the certification if they provide features that meet the exclusion criteria specified in the non-os features and system processors table section.

4.4.2. Optional hardware

Optional Hardware is hardware that is present in some configurations of a model.

Testing of Optional Hardware is not required in the following conditions:

  1. The Optional Hardware is field removable.
  2. It does not provide a unique function within the model [1]
  3. It is clearly indicated for use with another operating system [2]
  4. It is clearly marked to disclose any Service Level impacts, as necessary, on either the model specification or the model support URL, and on all materials using the Red Hat Hardware Certification marks in association with the model.

4.4.3. Additional hardware

Additional Hardware is hardware that can be purchased in addition to but is not included as part of any configuration of the model and is not required to be tested. Additional Hardware may appear on the model specification but must be clearly identifiable. Check KB articles attached to the certification listing of the particular additional hardware for more information.

4.4.4. Special cases

The Hardware policy changes may be used when Optional Hardware or a series of CPUs causes a minor release higher than initially desired during the original certification process. This may allow the testing and posting of the model with the desired release along with the associated Red Hat Knowledge Base Article to reflect the higher release required by the Optional Hardware or CPUs.

4.5. Non-OS features and unintentional features

Hardware feature classes not offered by the operating system are not required to be tested if the remaining hardware continues to be fully functional. A Red Hat Knowledge Base Article may be added to the certification listing for clarity.

An Unintentional Feature is defined as any feature offered on integrated or optional hardware that is not intentionally included by the hardware partner. This feature must not be mentioned in the hardware specification unless it is called out as not supported. Unintentional features can not be supported by the hardware partner on any OS. Unintentional features are not required to be tested if the remaining hardware continues to be fully functional, even if the provided feature is unique. We recommend that unintentional features are masked from end users where possible, i.e. by disabling or removing features from the BIOS, not providing power, not including connectors, headers, etc. to minimize confusion. A Red Hat Knowledge Base Article may be added to add clarity. Changes to unintentional features are considered to be hardware changes and subject to the hardware changes policies and requirements.

Unintentional features can also cover items that are not available on all architectures.

Example

If an Infiniband storage controller were supported by a system vendor on the Intel 64 and AMD64 architecture only, the controller could be considered an unintentional feature for the system’s i386 certification. The feature must not be supported on any i386 architecture operating system for the unintentional feature status to be granted.

4.6. Minimum Test Set

The Red Hat Hardware Certification program encourages testing with all configurations including the maximum and minimum supported configuration of your hardware. It is also recognized that resourcing these configuration can be difficult due to availability, cost, timing, and other constraints.

For these reasons we have defined a minimum requirements policy by hardware class in the Hardware class requirements. This column in combination with Component, Component leveraging pool and Component Pass-Through certifications.

The minimum testing requirements are not intended as product release criteria and it is expected that internal Red Hat Enterprise Linux and other Red Hat product interoperability, and qualification testing is conducted in addition to and prior to certification testing.

Warning

All hardware used during testing is required to be part of the model specification. Similar hardware that might otherwise qualify as part of the minimum test set if it were part of the model is not accepted. For example, only those CPUs which appear in the model specification may be used. Results from other members of the same CPU product family are not accepted.

The maximum supported limits for Red Hat Enterprise Linux are defined at https://access.redhat.com/articles/rhel-limits.

4.7. Installation, Boot, and Kdump requirements

The installation of Red Hat Enterprise Linux may require testing via a number of mediums (Optical Media and Network for example). Additionally, all boot devices must be tested to ensure a successful boot of Red Hat Enterprise Linux. The Hardware class requirements table shows the hardware that requires installation and boot testing. A complete installation is not required to fulfill the boot testing requirement.

For increased testing efficiency, Red Hat recommends combining boot and install testing where possible. For example, booting from the Red Hat Enterprise Linux installation media on a CD and performing a full installation fulfills the CD boot and installation testing requirement.

Kdump is utilized in the event of a crash to capture the state of the previous kernel. This feature is enabled by default and must be tested to ensure this critical information can be captured properly to debug issues.

Kdump testing is required on an integrated storage controller and an integrated network adapter when these items are available in the model. These requirements apply to all RHEL certifications.

4.8. Hardware class requirements

Hardware Requirements by Class

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

4.8.1. Compute

The hardware features that are included in Compute are:

Table 4.1. System Processors
Hardware ClassCatalog FeaturesRequired TestsRequired HardwareInstall, Boot, kdump

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

Maximum Logical Cores

CORE

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

Install, Boot

CPU Frequency Control

CPUSCALING, INTEL_SST [b], or POWER_STOP [c]

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

 
 

HW_PROFILER or SW_PROFILER

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

 

Realtime System

REALTIME

REALTIME [f]

Maximum number of logical cores and feature set from available CPUs with the realtime kernel. [g]

 

System Virtualization

SUPPORTABLE and CORE and MEMORY on the guest

SUPPORTABLE and CORE and MEMORY on the guest

FV_CORE and FV_MEMORY

Run on a fully virtualized guest environment.

Run on the host machine.

 

Advanced System Virtualization [h]

CPU Pinning,

FV_CPU_PINNING,

Run on a fully virtualized guest environment.

 

Pass-Through Storage, PCIE Pass-Through Storage, USB Pass-Through Network, PCIE Pass-Through Network, Virtual Machine Live Migration

FV_USB_STORAGE_PASSTHROUGH, FV_PCIE_STORAGE_PASSTHROUGH, FV_USB_NETWORK_PASSTHROUGH, FV_PCIE_NETWORK_PASSTHROUGH, and fv_live_migration [i]

Run on the host machine that has IOMMU enabled.

 
[a] The Core clock speed, FSB speed, cache size, cache depth and manufacturing size are not considered for feature set review.
[b] Available in RHEL versions 8.3 and later
[c] The Core clock speed, FSB speed, cache size, cache depth and manufacturing size are not considered for feature set review.
[d] The Core clock speed, FSB speed, cache size, cache depth and manufacturing size are not considered for feature set review.
[e] The Core clock speed, FSB speed, cache size, cache depth and manufacturing size are not considered for feature set review.
[f] These tests are used to certify the Red Hat (Red Hat Enterprise Linux for Real-Time and Red Hat OpenStack Platform for Real-Time Applications) products.
[g] The memory per CPU core check has been added as per the RHEL minimum requirement memory standards, as a planning condition for the hardware certification tests namely memory, core, realtime, and all the full-virtualization tests, for RHEL8. If the memory per CPU core check does not pass, the above tests will not be added to the test plans automatically. However, they can be planned manually via CLI.
[h] These features appear only on Red Hat Virtualization certifications.
[i] Starting with RHEL 9.4, all fv_tests, except fv_live_migration, are supported to run on ARM systems.
  • Leverage Notes: Equal or lesser feature set within a model. Processor/core count downward on scaling designs. Feature set and core count upgrades to existing certifications. Processor upgrades are defined as field installable physical packages and may require field installable BIOS/firmware upgrades Section 3.5.3, “Settings”.
Table 4.2. System Memory
Hardware ClassCatalog FeaturesRequired TestsRequired HardwareInstall, Boot, kdump

System Memory

Maximum supported System memory

memory, memory_HBM_only, memory_HBM_cache, memory_HBM_flat

Minimum of 1GB per logical core using the maximum number of logical cores.[a][b]

Maximum HBM memory size using the corresponding number of logical Cores [c]

Maximum supported HBM memory size for HBM_only, HBM_cache and HBM_flat

Install, Boot

NVDIMM - Memory Mode

NVDIMM - Memory Mode[d]

Memory[e]

Any size NVDIMM

Install, Boot

NVDIMM - App Direct

NVDIMM - AppDirect Mode[f]

NVDIMM[g]

Any size NVDIMM

Install, Boot, Kdump

[a] Systems must be in configurations within the memory requirements listed in the RHEL limits article
[b] Additional testing is required when the maximum system memory available is greater than the maximum memory listed in the Red Hat Enterprise Linux Technology Capabilities and Limits article.
[c] Depending on the available system configurations, the required HBM memory testing may need to be conducted separately from regular system memory.
[d] Available in RHEL versions 8.0 and later
[e] Additional EET testing is also required for NVDIMM - Memory Mode
[f] Available in RHEL versions 8.0 and later
[g] The NVDIMM test utilizes sector
  • Leverage Notes: Equal or lesser quantities where RAM type and memory controller match.
  • Leverage Notes for NVDIMM Hardware Class: The storage mode is only for identical implementations with smaller or greater capacity within the OS limits.
Table 4.3. System Elements
Hardware ClassCatalog FeaturesRequired TestsRequired HardwareInstall, Boot, Kdump

Mainboard, Chassis, I/O Chassis, Docking Stations, Port Expanders

Applicable class for the integrated and optional hardware.

Applicable class tests for the integrated and optional hardware. hardware.

Applicable test for each function as required by the device class(es)

Install, Boot

Multi-Function/Multi-Port Adapters

Applicable class for each function/port

Applicable class testing for each function/port[a][b]

Applicable test for each function as required by the device class(es)

Install, Boot

[a] Unusable ports need to be tested
[b] To create multiple ports on a removable card, identical chips are replicated. Leverage may enclose multi-port.
Table 4.4. Sound
Hardware ClassCatalog FeaturesRequired TestsRequired Hardware

Sound Cards

Stereo Audio Playback, and Stereo Audio Record

Audio

Stereo record and playback as applicable

HDMI Audio

HDMI Audio Playback

Audio

HDMI Port

  • Leverage Notes: Identical integrated chipsets+codec and removable adapters.
Table 4.5. Thunderbolt Ports
Hardware ClassCatalog FeaturesRequired TestsRequired Hardware

Thunderbolt 3, Thunderbolt 4

Thunderbolt 3, Thunderbolt 4

Thunderbolt 3, Thunderbolt 4

Each port with a device with the equivalent capability hotplug

Table 4.6. USB Ports
Hardware ClassCatalog FeaturesRequired TestsRequired Hardware

USB 2, USB 3 (5 Gigabit), USB C (5 Gigabit), USB 3 (10 Gigabit), USB C (10 Gigabit), USB 3 (20 Gigabit), USB C (20 Gigabit), USB 4 (20 Gigabit), USB 4 (40 Gigabit)

USB 2 Ports, USB 3 (5 Gigabit) Ports, USB C (5 Gigabit) Ports, USB 3 (10 Gigabit) Ports, USB C (10 Gigabit) Ports, USB 3 (20 Gigabit) Ports, USB C (20 Gigabit) Ports, USB 4 (20 Gigabit) Ports, USB 4 (40 Gigabit) Ports

USB2, USB3, USB3_5Gbps, USB3_10Gbps, USB3_20Gbps, USB4, USB4_20Gbps, or USB4_40Gbps

Each port with a device with the equivalent capability hotplug. [a]

[a] USB 3.1 gen2 ports that are tested only with the gen1 devices can be certified.

4.8.2. Management

The hardware features that are included in Management are:

Table 4.7. Console
Hardware ClassCatalog FeaturesRequired TestsRequired HardwareInstall, Boot, kdump

Display Adapters, and Virtual Consoles

Graphic Console

VIDEO

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

Install[a], Boot

Display Adapters

Basic GPU Graphics

VIDEO_DRM

DRM Kernel Module supported graphics controller

 

Display Adapters

Accelerated GPU Graphics

VIDEO_DRM_3D

DRM Kernel Module supported graphics controller + Hardware Acceleration Supported graphics controller

 

Laptop Panels

Graphic Console LCD

Video [LID][b]

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

Install

LCD backlight control

backlight[g][h]

 
[a] Native resolutions not required during install
[b] The backlight must respond to lid switch if present.
[c] Compensation/Stretching does not qualify as native resolution for testing.
[d] A horizontal resolution of 1360 may be used on 1366 native panels.
[e] Optional graphics controllers excluded by other policies are not required to be tested. At least one display + controller combination is required for each display.
[f] Display and graphics controller combinations may be clarified in a Red Hat Knowledge Base Article entry to avoid confusion.
[g] Backlight test does not support external displays.
[h] Available, but not required, in RHEL versions 8.0 and later certifications.
  • Leverage Notes: Identical removable cards or integrated chips without shared memory,processor-integrated. Decreases in video memory.
Table 4.8. Power Control
Hardware ClassCatalog FeaturesRequired TestsRequired Hardware

Power Management, Battery

Suspend to Disk, Suspend to Memory, Battery Monitoring

Battery, Lid and Suspend

Required for all models capable of running from battery power.

Table 4.9. Identity Management
Hardware ClassCatalog FeaturesRequired TestsRequired Hardware

fingerprintreader

Fingerprint Reader

fingerprintreader

Built-in or External fingerprint reader

4.8.3. Network

The hardware features that are included in Network are:

Table 4.10. Ethernet
Hardware ClassCatalog FeaturesRequired TestsRequired HardwareInstall, Boot, kdump

Ethernet

1 Gigabit Ethernet, 2.5 Gigabit Ethernet, 5 Gigabit Ethernet, 10 Gigabit Ethernet, 20 Gigabit Ethernet, 25 Gigabit Ethernet, 40 Gigabit Ethernet, 50 Gigabit Ethernet, 100 Gigabit Ethernet, 200 Gigabit Ethernet

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

Each interface at maximum connection speed.[a]

Install, Boot, kdump

[a] Devices that support network partitioning are required to demonstrate both the complete bandwidth and a single partition in one or more test runs.
  • Leverage Notes: Identical integrated chipsets and removable adapters.
Table 4.11. Fibre Channel
Hardware ClassCatalog FeaturesRequired TestsRequired HardwareInstall, Boot, kdump

Fibre Channel

16 Gigabit Fibre Channel, 32 Gigabit Fibre Channel, 64 Gigabit Fibre Channel, 128 Gigabit Fibre Channel

Network or Storage[a]

Each interface at maximum connection speed

Install, Boot, kdump

[a] Nominal connection speed is considered a feature. Remote attached storage devices may require additional testing.
  • Leverage Notes: Identical integrated chipsets, removable adapters, drivers, and arrays.
Table 4.12. Fibre Channel over Ethernet (FCoE)
Hardware ClassCatalog FeaturesRequired TestsRequired HardwareInstall, Boot, kdump

FCoE adapters

FCoE

Storage[a]

Each interface at the maximum connection speed

Install, Boot, kdump

[a] Nominal connection speed is considered a feature. Remote attached storage devices may require additional testing.
  • Leverage Notes: Identical integrated chipsets, removable adapters, drivers, and arrays.
Table 4.13. iSCSI
Hardware ClassCatalog FeaturesRequired TestsRequired HardwareInstall, Boot, kdump

iSCSI Adapters

iSCSI

Network and Storage[a]

Each interface at maximum connection speed

Install, Boot, kdump

[a] Nominal connection speed is considered a feature. Remote attached storage devices may require additional testing.
  • Leverage Notes: Identical integrated chipsets, removable adapters, drivers, and arrays.
Table 4.14. Infiniband
Hardware ClassCatalog FeaturesRequired TestsRequired HardwareInstall, Boot, kdump

Infiniband[a]

QDR Infiniband, FDR Infiniband, EDR Infiniband, HDR Infiniband, Socket Direct

Infiniband_QDR, Infiniband_FDR Infiniband_EDR, Infiniband_HDR, Infiniband_Socket_Direct

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

Install, Boot, kdump

[a] Multiple hosts to be connected into a single adapter by separating the PCIe interface into multiple and independent interfaces.
[b] Implements a connection in hardware for efficient data delivery with minimal latency.
[c] Devices that support network partitioning are required to demonstrate both the complete bandwidth and a single partition in one or more test runs.
  • Leverage Notes: Identical integrated chipsets, removable adapters, drivers, and arrays.
Table 4.15. iWarp
Hardware ClassCatalog FeaturesRequired TestsRequired Hardware

iWarp

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

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

Each interface with the corresponding test for the maximum claimed connection speed.footnote:[a]

[a] Devices that support network partitioning are required to demonstrate both the complete bandwidth and a single partition in one or more test runs.
  • Leverage Notes: Identical integrated chipsets and removable adapters.
Table 4.16. Omnipath
Hardware ClassCatalog FeaturesRequired TestsRequired Hardware

OmniPath

OmniPath

OmniPath

Each interface with the corresponding test for the maximum claimed connection speed.

  • Leverage Notes: Identical integrated chipsets, processors, and removable adapters.
Table 4.17. RDMA over Converged Ethernet (RoCE)
Hardware ClassCatalog FeaturesRequired TestsRequired Hardware

RoCE

2.5 Gigabit RoCE, 5 Gigabit RoCE, 10 Gigabit RoCE, 20 Gigabit RoCE, 25 Gigabit RoCE, 40 Gigabit RoCE, 50 Gigabit RoCE, 100 Gigabit RoCE, 200 Gigabit RoCE

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

Each interface with the corresponding test for the maximum claimed connection speed.[a]

[a] Devices that support network partitioning are required to demonstrate both the complete bandwidth and a single partition in one or more test runs.
  • Leverage Notes: Identical integrated chipsets, processors, and removable adapters.
Table 4.18. WiFi
Hardware ClassCatalog FeaturesRequired TestsRequired HardwareInstall,Boot, kdump

Wireless Network, Interface Adapters

Wireless N, Wireless AC, USB Wireless N, USB Wireless AC, Wireless G, and USB Wireless G

Wireless G, Wireless N, Wireless AC[a], WiFi6 (Previously WirelessAX)

Each interface at maximum connection in N(highest), G, B, A(lowest) order.

Install,Boot

[a] Red Hat Enterprise Linux 7.0 only supports 802.11ac devices at 802.11n speeds. Results will be accepted from the WirelessN test on 802.11ac devices until an erratum that provides full 802.11ac connection speeds to Red Hat Enterprise Linux 7.0 is available.
  • Leverage Notes: Identical integrated chipsets, processors, and removable adapters.
Table 4.19. Bluetooth
Hardware ClassCatalog FeaturesRequired TestsRequired Hardware

Bluetooth

Bluetooth 3.x, Bluetooth 4.x, Bluetooth 5.x

BLUETOOTH3, BLUETOOTH4, BLUETOOTH5

Each interface at maximum bluetooth version

  • Leverage Notes: Identical integrated chipsets and removable adapters.

4.8.4. Storage

The hardware features that are included in Storage are:

Table 4.20. HBA, HDD, and SDD
Hardware ClassCatalog FeaturesRequired TestsRequired HardwareInstall, Boot, kdump

M.2 NVMe, M.2 SATA, PCIe NVMe, SATA HDD, SATA SSD, SAS[a], SAS SSD, U.2 NVMe, U.2 SATA, U.3 NVMe, E.3 NVMe

M.2 NVMe, M.2 SATA, NVMe, SATA, SATA SSD, SAS, SAS SSD, U.2 NVMe, U.2 SATA, U.3 NVMe, E.3 NVMe

M2_NVMe, M2_SATA, NVMe, SATA, SATA_SSD, SAS, SAS SSD, U2_NVMe (PCI Express), U2_SATA, U3_NVMe, E3_NVMe

Any capacity[b] drive[c] attached to the controller or the maximum storage capacity of local attach arrays if greater than OS limit

Install, Boot, kdump

RAID Controllers

Storage

Storage

Each OS code path (e.g. where multiple drivers are used) for each interface. Maximum storage capacity of arrays if greater than OS limit.

Install, Boot, kdump

NVMe over Fabric

NVMe over Infiniband, NVMe over iWarp, NVMe over Omnipath, NVMe over RoCE, NVMe over TCP

nvme_infiniband, nvme_iwarp, nvme_omnipath, nvme_roce, nvme_tcp

An NVMe SSD drive shared from the test server to HUT ethernet controller sized under the maximum storage capacity of the OS limit.

 
[a] SAS Controllers require testing with SAS drives.
[b] Drive capacity is not tracked in the context of a system.
[c] SSD features require SSD drives to be tested.
  • Leverage Notes: Identical integrated chipsets, removable adapters, drives, and arrays.
  • Leverage Notes for RAID Controllers: Identical integrated chipsets, removable adapters, drives and arrays following type criteria. Reduced RAID levels, changes in memory amounts or battery presence.
Table 4.21. Tape
Hardware ClassCatalog FeaturesRequired TestsRequired Hardware

Tape Drives and Changers[a]

Tape drive, Tape changer

TAPE

Each drive

[a] Changers require manual testing with test description and results report
  • Leverage Notes: Identical drives and changers. Internal and external versions of the same drives. Models with the same host interface, hardware and firmware designs including reduced features, capacity, media size and/or total slots and drive count in changers/libraries.
Table 4.22. Memory Cards or Readers
Hardware ClassCatalog FeaturesRequired TestsRequired HardwareInstall, Boot, kdump

eMMC, PCIE SD Card Reader, SD Card, USB Flash Key, USB SD Card Reader[a]

eMMC, PCIE SD Card Reader, SD Card, USB Flash Key, USB SD Card Reader

Storage

The maximum storage capacity and format feature set

Install,Boot

[a] Including variants for each (eg. mini, micro, etc.).
  • Leverage Notes: Identical integrated chipsets, removable adapters. Identical, smaller capacity or feature cards and sticks.
Note

Multi-Readers follow the Multi-Port Adapter criteria.

Table 4.23. Optical
Hardware ClassCatalog FeaturesRequired TestsRequired HardwareInstall, Boot, kdump

CD-ROM drive, DVD drive, or Blu-ray

BD-RE, BD-R, Blu-ray, DVD-RW, DVD-R, DVD, CD-RW, CD-R, CD

CDROM drive, DVD drive, or BLURAY

The highest media type in order of BD-RW (highest), BD-R, DVD-RW[a], DVD-R, CD-RW, CD-R, BD, DVD, CD (lowest) on each storage controller, based on the collective media support of all drives[b] available on that storage controller

Install, Boot

[a] "+" and "-" are considered equal for feature review.
[b] The hardware partner is required to support all drives that are part of the model regardless of the specific drive or number of drives used during testing. Equivalent production cycle drive changes are required to be tested internally by the hardware partner. The production cycle drive change test results are not required to be submitted to Red Hat
  • Leverage Notes: Drives with identical or lesser media support on the storage controller following the storage controller leveraging policies.

4.9. Additional manual testing

The additional manual testing consists of the external storage and multipath HBAs.

4.9.1. External storage and multipath HBAs

In addition to the base requirements for storage controllers/devices; vendors must verify that their internal quality assurance processes have tested full functionality with Red Hat Enterprise Linux under the following scenarios as appropriate:

  • multi-controllers/single host
  • multi-host/single controller
  • multi-controller/multi-host
  • with/without multi-path
  • with/without LUN masking (i.e., dedicating LUNs to specific hosts)
  • a short cable pull (remove cable and restore prior to failure detection)
  • any special features listed as supported on Red Hat Enterprise Linux

Testing result packages are not required to be submitted to Red Hat for the above testing.



[1] The quantity of a function is not considered unique; for example, a dual and a quad Ethernet adapter with all other capabilities being the same are considered to provide the same function.
[2] Notes must be in a positive tone and not a negative.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.