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 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" Table 4.2, "System Memory" Table 4.3, "System Elements" Table 4.4, "Sound" Table 4.5, "Thunderbolt Ports" Table 4.6, "USB Ports" 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. 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 Class Catalog Features Required Tests Required Hardware Install, Boot, kdump System Memory Maximum supported System memory memory Minimum of 1GB per logical core using the maximum number of logical cores. [a] [b] [c] Install, Boot, Kdump HBM Memory HBM System Memory memory_HBM_only Maximum HBM memory size using the corresponding number of logical Cores [d] Install, Boot, Kdump HBM Cache Memory memory_HBM_cache Maximum HBM memory size using the corresponding number of logical Cores [e] Install, Boot, Kdump HBM Flat Memory memory_HBM_flat Maximum HBM memory size using the corresponding number of logical Cores [f] Install, Boot, Kdump NVDIMM NVDIMM - Memory Mode [g] memory [h] Any supported NVDIMM memory size Install, Boot, Kdump NVDIMM - AppDirect Mode [i] NVDIMM [j] Any supported NVDIMM memory size Install, Boot, Kdump CXL Memory Expansion CXL Memory Expansion [k] memory_CXL Each implementation [l] with maximum supported memory size [m] [n] [o] Install, Boot, Kdump [a] Systems must be available in configurations within the memory requirements listed in the RHEL limits article [b] Additional testing is required when the maximum total memory available across system memory + HBM + NVDIMM + CXL is greater than the maximum memory limit for the architecture 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] Depending on the available system configurations, the required HBM memory testing may need to be conducted separately from regular system memory [e] Depending on the available system configurations, the required HBM memory testing may need to be conducted separately from regular system memory [f] Depending on the available system configurations, the required HBM memory testing may need to be conducted separately from regular system memory [g] Available in RHEL versions 8.0 and later [h] Additional EET testing is also required for NVDIMM - Memory Mode [i] Available in RHEL versions 8.0 and later [j] The NVDIMM test utilizes sectors [k] Available in RHEL version 9.3 and later [l] Individual testing is required for each implementation available in a single component or system model [m] Memory sizes includes all embedded or socketed options with the same model name [n] A support matrix for approved memory modules is to be provided to customers by Partners with socketed designs [o] Including physicial devices, virtual devices, and NUMA nodes 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] [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" Table 4.8, "Power Control" Table 4.9, "Identity Management" 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 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" Table 4.11, "Fibre Channel" Table 4.12, "Fibre Channel over Ethernet (FCoE)" Table 4.13, "iSCSI" Table 4.14, "Infiniband" Table 4.15, "iWarp" Table 4.16, "Omnipath" Table 4.17, "RDMA over Converged Ethernet (RoCE)" Table 4.18, "WiFi" Table 4.19, "Bluetooth" 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" Table 4.21, "Tape" Table 4.22, "Memory Cards or Readers" Table 4.23, "Optical" 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, 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 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. [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.

Commands: