Chapter 4. Creating a test plan

4.1. Overview of test plan

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

Define the model by its specification.
Determine the option.
Remove unsupported operating system features and unintentional hardware.
Apply the minimum test set criteria.
Add the install, boot, and kdump requirements.
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

For more information about defining the testing required for each hardware class item, see Hardware class requirements.

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:

The Optional Hardware is field removable.
It does not provide a unique function within the model ^[1]
It is clearly indicated for use with another operating system ^[2]
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 Class	Catalog Features	Required Tests	Required Hardware	Install, 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.
Advanced System Virtualization ^[h]	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 RHEL7 as well as 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 Class	Catalog Features	Required Tests	Required Hardware	Install, 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 7.6 and later ^[e] Additional EET testing is also required for NVDIMM - Memory Mode ^[f] Available in RHEL versions 7.3 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 Class	Catalog Features	Required Tests	Required Hardware	Install, 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 Class	Catalog Features	Required Tests	Required 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 Class	Catalog Features	Required Tests	Required 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 Class	Catalog Features	Required Tests	Required 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]^[b]^[c]^[d]
^[a] In all RHEL 7.x certifications, USB 3.1 gen2 ports require testing with RHEL 7.3 or higher. ^[b] USB 3.1 gen2 ports that are tested only with the gen1 devices can be certified. ^[c] USB 3.1 Gen2 at 10Gbps is supported in later versions of RHEL 7. ^[d] USB 3.1 Gen2 ports are supported/tested at 5Gbps only, prior to RHEL 7.5 or later and RHEL 7.4 (EUS).

4.8.2. Management

The hardware features that are included in Management are:

Table 4.7. Console
Hardware Class	Catalog Features	Required Tests	Required Hardware	Install, 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
Laptop Panels	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 Class	Catalog Features	Required Tests	Required 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 Class	Catalog Features	Required Tests	Required 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 Class	Catalog Features	Required Tests	Required Hardware	Install, 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 Class	Catalog Features	Required Tests	Required Hardware	Install, 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 Class	Catalog Features	Required Tests	Required Hardware	Install, 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 Class	Catalog Features	Required Tests	Required Hardware	Install, 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 Class	Catalog Features	Required Tests	Required Hardware	Install, 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 Class	Catalog Features	Required Tests	Required 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 Class	Catalog Features	Required Tests	Required 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 Class	Catalog Features	Required Tests	Required 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 Class	Catalog Features	Required Tests	Required Hardware	Install,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 Class	Catalog Features	Required Tests	Required 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 Class	Catalog Features	Required Tests	Required Hardware	Install, Boot, kdump
M.2 NVMe, M.2 SATA, PCIe NVMe, SATA HDD, SATA SSD, SAS^[a], SAS SSD, U.2 NVMe, U.2 SATA	M.2 NVMe, M.2 SATA, NVMe, SATA, SATA SSD, SAS, SAS SSD, U.2 NVMe, U.2 SATA	M2_NVMe, M2_SATA, NVMe, SATA, SATA_SSD, SAS, SAS SSD, U2_NVMe (PCI Express), U2_SATA	Any capacity^[b] drive^[c] attached to the controller or the maximum storage capacity of local attach arrays if greater than OS limit	Install, Boot, kdump
RAID Controllers	Storage	Storage	Each OS code path (e.g. where multiple drivers are used) for each interface. Maximum storage capacity of arrays if greater than OS limit.	Install, Boot, kdump
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 Class	Catalog Features	Required Tests	Required 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 Class	Catalog Features	Required Tests	Required Hardware	Install, 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 Class	Catalog Features	Required Tests	Required Hardware	Install, 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.

Ce contenu n'est pas disponible dans la langue sélectionnée.