Red Hat Training

A Red Hat training course is available for Red Hat Certified Cloud and Service Provider Certification

Red Hat Cloud Instance Type Policy Guide

Red Hat Certified Cloud and Service Provider Certification 2024

For Use with Red Hat Cloud Instance Type Policy Guide

Red Hat Customer Content Services

Abstract

This document describes the technical and operational certification requirements for Instance Type Partners who want to offer Infrastructure-as-a-Service (IaaS) based on Red Hat Enterprise Linux.
Version 8.75 updated February 14, 2024.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code and documentation. We are beginning with these four terms: master, slave, blacklist, and whitelist. Due to the enormity of this endeavor, these changes will be gradually implemented over upcoming releases. For more details on making our language more inclusive, see our CTO Chris Wright’s message.

Chapter 1. Introduction to Red Hat Cloud Instance policies

Use this guide to understand the technical and operational certification requirements for CCSP Partners who want to offer their own virtual and/or physical hardware with Red Hat products both on-demand or as-a-service to our joint Customers.

1.1. Audience

As a Certified Cloud and Service Provider (CCSP) Partner who want to learn about the requirements of offering their own hardware. The Red Hat Cloud Instance Type certification presumes an advanced level of hardware and Red Hat product knowledge and skills.

Important

Red Hat product support is neither offered nor covered in the Red Hat Cloud Instance Type certification, but may be provided as part of your CCSP program membership or separately.

1.2. Create value for our joint customers

The certification process includes a series of tests that provide your Red Hat customers:

  • A consistent experience across cloud providers,
  • A consistent experience across instances with similar features, and
  • An assurance that the Instance Type is tested, verified and supported

1.3. Overview of program and product

The Red Hat Cloud Instance Type Certification provides a formal means for you to work with Red Hat to establish an official support for your hardware.

An Instance Type is required to include a set of compute, network, management, and storage features to establish a functioning system environment. You can select your specific feature requirements for an Instance Type according to the intended application or use cases at your own discretion. An Instance Type may also include one or more sizes if the features provided by the Instance are available in a variety of capacities such as, faster and slower networking, smaller and larger storage, more and less logical cores.

During the certification process, Red Hat engineers follow the process described in Overview of test plan to create a test plan suitable for your Instance Type specification. The test plan defines the testing criteria required to achieve certification for the overall Instance Type including the sizes.

1.4. Certification prerequisites

  • An active membership in the CCSP Program.

  • a support relationship with Red Hat. This can be fulfilled through:

    • a custom support agreement or
    • TSANet
  • working knowledge of Red Hat Enterprise Linux (RHEL).
  • Use of already certified or enabled virtual and physical hardware as presented to the Red Hat product.
  • Certifications are currently available for:

    • RHEL 7, RHEL 8 and RHEL 9 versions.
    • For the x86_64 Intel and AMD, ARM (by invitation), Power 8 & 9 Little Endian, and System Z platforms.

Additional resources

  • For more information about Technical Support Alliance Network, see TSANet web page.

1.5. Give feedback and get help

We Need Feedback!

If you find a typographical error in this guide, or if you think of a way to improve the certification program or documentation, we would appreciate hearing from you!

Submit a report in the Red Hat Bugzilla system against the product Red Hat Certification Program. Fill in the Description field with your suggestion for improvement, try to be as specific as possible when describing it. If you find an error in the documentation include a link to the relevant part(s) of the documentation.

Do You Need Help?

If you experience difficulty with a procedure described in this documentation, visit the Red Hat Customer Portal. Through the customer portal, you can:

  • Search or browse through technical support articles and solutions about Red Hat products
  • Submit a support case to Red Hat Global Support Services (GSS)
  • Access product documentation

The Red Hat Cloud Instance Type Certification Workflow Guide assists you with the steps on Opening a Support Case.

Questions During Certification

During the certification process, you may need to ask or reply to a question about topics which affect a specific certification. These questions and responses of the certification entry are recorded in the Dialog Tab > Additional Comments.

Important

Personal emails are not a tracked support mechanism and do not include a Service Level Agreement. Please use the correct support procedure when asking questions.

Chapter 2. Program policies

2.1. Cloud Instance Type

An Instance Type is a specific hardware configuration known by a unique name that will be made available to customers as part of a CCSP solution. The hardware defined in the specification can be physical, virtual, complete, or partitioned.

An Instance Type may also be available in multiple configuration specifications where each configuration includes a unique name within a common naming convention. These configurations (sizes) may be certified and listed together in the Red Hat Ecosystem Certification Catalog. For more information see, SuperSet Instance Type certification

If an Instance Type size configuration is above or below the limits of RHEL the other sizes within the Instance Type may still be certified.

2.2. Policy Changes

Typically, Red Hat limits major revisions in the certification tests and criteria to major releases of RHEL. Red Hat may also release updates to the CCSP Instance Type for the following:

  • Policy and/or workflow,
  • Criteria,
  • Minor OS releases; where new hardware support features are introduced or
  • At any other point as deemed necessary.

Only a single version of the policy is active at any one time. This current policy is effective upon its release and supersedes all previous versions.

Note

The CCSP Instance Policy Guide version applied during the certification process will be recorded in certifications upon successful completion. Changes to the workflow guide will be documented in the workflow guide errata notification and package changelog.

2.3. Original Provider

Partner support of certified Instance Type is a fundamental part of Red Hat CCSP Instance type certification. All requests and information about the Instance Type to be certified, including details for the physical and virtual hardware contained within must be submitted by the original provider of the Instance Type to Red Hat.

You may choose to use your own internal or outside Partners for any portion of their testing however any such arrangement are the exclusive responsibility of the CCSP Partner. Red Hat will only interact with the CCSP Partner who is responsible for submitting the certification request and Red Hat will only post original certifications that will be easily identifiable.

2.4. Submission Window

New Instance Type certifications for a given, major release of RHEL can typically be submitted until the 2nd, subsequent major version of RHEL is released.

Certification requests that fall outside of the window must be raised with your EPM or SA. These requests are reviewed on a case-by-case basis.

Chapter 3. Certification lifecycle

Instance Type certifications are limited to the versions and architecture of RHEL and their subsequent minor releases.

Example

RHEL 7.4 for x86_64 will carry forward through each minor release such as RHEL 7.5, 7.6, and so on.

Certifications do not apply to previous or future major versions of RHEL versions nor any additional or alternate architectures that RHEL may be or become available for. Certifications for each major release + architecture combination must be obtained separately.

Once an Instance has been certified, the Instance will retain its certification until:

  1. Recertification is required
  2. Red Hat no longer supports that version of RHEL
  3. The vendor ceases participation in the CCSP Program or
  4. The Instance is no longer offered and is no longer in use by customers with the corresponding RHEL.

3.1. Lifecycle of Instance Type

It is required that an already certified Instance Type is not modified in a way that would invalidate the certification. This is in order to avoid inconvenience to customers . Red Hat recognizes that an Instance Type may change over time and the Instance Type Certification program does support the following changes to a certified instance type:

  • Changes to the specification
  • Offering adding additional sizes, smaller or larger
  • Offering the same instance type under additional names

To change the specification of an already certified Instance a supplemental certification is to be opened before the specification is modified for customers. The details of the upcoming changes is to be provided along with any relevant tests successfully conducted and credited. For more information, see Supplemental certification.

To add an additional Instance Type name to an existing certified Instance Type create a pass-through certification. For more information, see Pass-Through Instance Type certification

To add an additional Instance Type size to an existing certified Instance Type extending or contracting the configuration specification of that instance Type, create a pass-through certification providing the additional specifications and submit the relevant results to the supplemental tests.

3.2. Recertification

Changes to the Instance Type that would alter the original test plan criteria require recertification. The changes include hardware, BIOS, or firmware. For example, an increase to the number of CPUs supported or the addition of new components such as network or storage controllers requires recertification. See Lifecycle of Instance Type.

Chapter 4. Types of certification workflow

4.1. Single Instance Type certification

A Single Instance Type Certification consists of bootable, installable, and operableable collection of physical or virtual hardware features, as defined by a specification provided by a Partner.

The specification may define features as standard, or optional. The Instance Type is considered to provide all of the features from the complete collection of standard and optional components unless explicitly excluded by or from the specification.

4.2. SuperSet Instance Type certification

The SuperSet Instance Type Certification covers a variety of different configurations of the same Instance Type. The SuperSet Instance Type is known by a unique name within a naming convention.

Example

compute_slow, compute_medium, compute_fast

The certification is conducted as per the basic process where all of the configurations are reviewed. The test plan will consider multiple configurations in order to increase the testing and processing efficiency without creating risks. The certification publication in the catalog will be a combined entry where the sizes covered by the certification will be displayed on the Instance Type certification entry.

4.3. Supplemental certification

A supplemental certification allows a certified Instance Type to extend or alter the configuration of the Instance Type.

4.4. Pass-Through Instance Type certification

A Pass-Through Instance Type Certification refers to the ability of a third party system or component to be granted the same certification as Instance Type previously certified by the Original Provider.

The Original Provider can extend a certification granted to their instance type to another Partner’s Instance Type where the original provider:

  • Has permission from the third party
  • Has the mechanics to ensure the third party does not alter the hardware in such a way that it would no longer be considered a subset of the original model certified by Red Hat
  • Extends their responsibilities of support and representative Instance Type to include situations involving the third party Instance Type

The third party however cannot extend their pass-through certification to another Partner.

Important

Both Partners are required to be members of the CCSP program; only the original provider may request Pass-Through certifications.

Note

You may also utilize the pass-through process where the same Instance Type is available with multiple names.

Chapter 5. Software policies

5.1. Test Suite versions

Red Hat recommends that the latest version of the test suite packages be used for all testing.

When a new version of any test suite package is made available, test results created using the previous versions will continue to be accepted for a period of three months. At the end of this period results from these previous versions will automatically be rejected and testing will need to be repeated with the later test suite packages.

Note

The current valid package versions are displayed on the results package submission form.

5.2. Red Hat Enterprise Linux versions

The latest minor release of Red Hat Enterprise Linux (RHEL) version is always recommended; however, any release that satisfies the full testing criteria may be used. Testing on the earliest fully-supported release will maximize the potential customer base. If multiple minor releases are used during testing, the newest minor release will be used as the posted release for the model. Depending on the features of a given model a minimum release may be required other than what is desired.

Important

Instance Type that are available without certified images are required to be installed and tested using the GA media (or equivalent) without additional errata.

The test suite is tested against RHEL 8 and RHEL 9 Base OS and Red Hat Enterprise Linux 7 server installations. All the variants of the RHEL major version share a common core set of packages, and the use of these variants is allowed during certification testing. However, the variants may only provide a subset of the required packages that may result in the need for retesting with the Base OS variant.

Important

Technical assistance during certification is not offered when using these variants.

5.3. Unmodified Red Hat software

The Red Hat CCSP Instance Type certification requires testing on a standard installation of Red Hat Enterprise Linux without any modifications. Changes to the default configuration presented by the installer and first boot utilities are allowed when the configuration change can be made using one of the standard system tools and when the default configuration does not create the potential for data loss. Required changes to the default configuration must be documented in a Red Hat Knowledge Base Solution that is associated with the certification listing.

Additionally, the Red Hat certification test suite should not be modified. The test suite will perform a self check and will fail the supportable test if modified.

5.4. Kernel Boot parameters

Additional kernel parameters may be utilized if they

  • Are used to correct hardware configuration
  • Do not disable functionality
  • Do not expose a potential for data loss when not in use

Example

if the kernel parameter noacpi is required to boot a system which does not install without that parameter, this would likely be acceptable. If, however, the system would install but corrupts data over time when noacpi is not specified, the certification would be suspended until the situation is resolved. Additional kernel parameters utilized during certification are documented in Red Hat Knowledge Base Solution associated with the certification listing.

5.5. SELinux

Certifications must be run with SELinux enabled using the Targeted Policy and with Enforcing on. The test suite will check for these conditions.

Chapter 6. BIOS, firmware, and hardware policies

6.1. Production level

BIOS, Firmware, and Hardware versions are required to be production-level (e.g. feature complete without major changes pending and/or upgraded to production equivalent) during testing. Changes subsequent to testing are required to meet the Changes criteria below. The tested or a later revision is required to be available to and without customer interactions in the Instance Type by the posting date of the certification.

6.2. Changes

BIOS, Firmware, and Hardware changes that enable or disable features necessitate recertification. Re-certification is not required for changes to correct small flaws and minor bugs and/or alter superficial items like splash screens and silkscreens. Partners are expected to have internal testing of these changes to verify they do not adversely affect customers, Red Hat Enterprise Linux, or the certification status. The results of this testing is not required to be submitted to Red Hat.

6.3. Settings

Any required BIOS/Firmware configuration information must be provided in a comment in the certification request. Providing suggested and/or default configuration data is encouraged but not required. Vendor provided configuration information may be provided in the certification listing using an associated Red Hat Knowledge Base Solution. Validating alternate configuration settings do not expose data corruption issues or unexpectedly disrupt functionality is the responsibility of the hardware vendor.

Important

User configurable BIOS settings that enable/disable hardware features and/or functions must be set such that the feature or function is enabled during testing.

6.4. Configuration limits

CCSP Instances available in configurations beyond the Red Hat product limits may still be eligible for certification. Testing will need to be performed demonstrating functionality within the limits and the partner will need to decide if they also want to pursue the features beyond the limits. Like all Red Hat Enterprise Linux feature requests, the required time lines, development, and testing efforts are determined on a case-by-case basis and are considered outside of the certification process.

A Red Hat Knowledge Base article can be added to the certification listing for clarity.

Important

Vendors are encouraged to work with their Hardware Partner Manager and Partner Technical Account Managers (TAMs) on feature requests to raise the relevant Red Hat Enterprise Linux product limits prior to the certification effort.

Additional resources

6.5. Performance limits

In general, Red Hat places the responsibility of performance testing on the Partner; however, major performance issues that are deemed to have significant customer impact may delay certification until a resolution is determined.

Chapter 7. Testing requirements for cloud instance

Understand the process followed by the Red Hat CCSP Instance team to create a test plan for a system or hardware component.

7.1. Overview of test plan

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

  1. Determine the Instance Types to be covered by the certification.
  2. Define and determine the hardware features based on the specification provided.
  3. Remove unsupported operating system features.
  4. Apply the minimum test set criteria.
  5. Add the install, boot, and kdump requirements.
  6. Apply any other additional policy requirements.
  7. Freeze and provide the testplan to the partner.

The created test plan will list the tests to be run against the Instance type features to achieve certification.

7.2. Instance Type and its specifications

Red Hat Cloud Instance Type Certification certifies a specific Instance Type. Red Hat defines an Instance Type as a unique name with a specific definition of physical and virtual hardware features. The specification is inclusive of all Integrated Hardware and Optional Hardware features described by the CCSP Partner.

Integrated-Hardware is a hardware feature present in all configurations of an Instance Type. Optional-Hardware is hardware or features which are only present in some configurations of an Instance Type.

An Instance Type may be available in multiple sizes using a tiered naming scheme. Sizes with tiered naming schemes are encouraged and supported by Red Hat Cloud Instance Type Certification. A tiered naming scheme is any naming scheme which includes a hierarchical collection of Instance Type. When employing tiered naming schemes for the purposes of certification the specification is considered to include all Instance Type and sizes which would reasonably be represented by the name provided in the certification request.

Example

An Instance Type with the names t1 is available in the sizes t1A, and t1B; the certification requirements would reflect the collection specification across the t1A and t1B sizes. The resulting certifications would be for the t1A and t1B sizes under the t1 Instance Type.

Note

Red Hat may alter the listed Instance Type name for clarity; for example in NUMA and cluster situations when a quantity of systems/nodes alters the specification , Red Hat may add "(up to 2 nodes)" to the Instance Type name.

7.3. Hardware features

The Hardware features identified in each Instance Type specification aligns to a hardware class, mentioned in Hardware requirements by class. These features along with the requirements outlined in Hardware requirements by class forms the basis of the test plan. Every feature will receive a clear alignment with a requirement in the test plan. This complete set will then continue to be refined in the next steps which will ensure an efficient and effective use of your and our resources for an assured customer success.

7.4. Integrated Hardware

All Integrated Hardware features, CPU options, memory options, and any other feature a customer cannot remove from an instance must be tested.

Note

Specific features of integrated hardware may later be excluded from the certification testing requirement if they qualify for exclusion based on the policies outlined in Non-OS-Features or Minimum-Test-Set sections.

7.5. Optional Hardware

All Optional Hardware must be tested except when the Optional Hardware is customer removable, and does not provide a unique function within the instance.

  • Quantity of a function is not considered unique.

Example

A dual and a quad Ethernet adapter with all other capabilities being the same are considered to provide the same function and is clearly noted for use with another operating system in the specification.

  • Notes must be in the positive tone (Example: "for use with…​") and not the negative (Example: "not for use with…​").] OR
  • Marked to disclose any Service Level impacts as appropriate on the instance specifications and/or the instance support URL and on all materials using the Red Hat Certification marks in association with the Instance Type.

Example

If an Instance Type is available both with and without a SAS controller, and is also available with three functionally identical optional network cards, one of which is identified for use with Fedora only, the required testing would include the SAS controller and the two remaining optional network cards.

7.6. Non-OS features

Hardware features not offered by the operating system are not required to be tested if the remaining Instance Type continues to be fully functional. For example, IEEE 1394, a type of storage not currently supported in Red Hat Enterprise Linux, would not require testing. If, however, the Instance Type only had IEEE 1394 storage, it would not qualify for a Red Hat Enterprise Linux certification.

Note

A Red Hat Knowledge Base Article may be added to the certification listing for clarity of Non-OS features.

7.7. Minimum test set

The Red Hat CCSP Instance Type certification encourages testing with all configurations including the maximum and minimum supported configurations. It is also recognized that resourcing these configurations 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-Feature-Requirements-by-Class section.

The table is designed to ensure an appropriate and reasonable testing effort to achieve certification.

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

7.8. Installation requirements for CCSP Instance

The installation may require testing via a number of mediums. Additionally, all boot devices must be tested to ensure a successful boot of RHEL.

Red Hat recommends combining boot and install testing where possible.

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

Kdump is a common feature for RHEL. Kdump utilizes the Linux kernel kexec feature to boot a kernel without a hardware reset in the event of a crash and capture the state of the previous kernel. This feature is enabled by default and must be tested to ensure this critical debug information can be captured properly. The kdump test will automatically be planned when the kdump service is enabled.

Kdump testing is required for all architectures and is to be conducted on both an integrated storage controller and an integrated network adapter. These requirements apply to all RHEL 7, RHEL 8 and RHEL 9 version certifications on the 64-bit Intel and AMD systems , and 64-bit IBM PowerPC architectures. Additionally, RHEL allows testing of Kdump on IBM System z architectures.

The CCSP Instance Type installation testing is only required on Instance Type where installation is available to and performed by customers.

Chapter 8. Hardware feature requirements by class

The hardware class requirements are categorized in Compute, Management, Network, and Storage.

8.1. Compute

The hardware features that are included in Compute are:

Table 8.1. System Processors

Hardware ClassCatalog FeaturesRequired TestsRequired HardwareInstall, Boot, kdump

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

System Processor (Maximum quantity of Cores)

CORE,FV_CORE, FV_MEMORY, PROFILER

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

Install, Boot

System Virtualization

INFO and CORE and MEMORY on the guest

INFO and CORE and MEMORY on the guest

A fully virtualized guest environment

 
[a] The Core clock speed, FSB speed, cache size, cache depth and manufacturing size are not considered for feature set review.
[b] The minimum installed memory is required to match the System Memory testing requirement.

Table 8.2. System Memory

Hardware ClassCatalog FeaturesRequired TestsRequired HardwareInstall, Boot, kdump

System Memory

Maximum supported System memory

Memory

Lower of 1GB Per Logical CPU, system limit, or OS limit[a]

Install, Boot

NVDIMM

Maximum supported NVDIMM memory

Memory

Install, Boot, Kdump

NVDIMM block-mode

NVDIMM block-mode

NVDIMM

 
[a] Additional testing may be required where the maximum capacity is greater than the currently listed OS Certified storage or system memory maximums

Table 8.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.

8.2. Management

The hardware features that are included in Management are:

Table 8.4. Console

Hardware ClassCatalog FeaturesRequired TestsRequired HardwareInstall, Boot, kdump

Display Adapters, and Virtual Consoles

Graphic Console

Video[a]

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

Install[b], Boot

[a] 3D/GPGU support is not currently tested
[b] Native resolutions not required during install

Table 8.5. 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.

8.3. Network

The hardware features that are included in Network are:

Table 8.6. 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

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

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.

Table 8.7. 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.

Table 8.8. 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.

Table 8.9. Infiniband

Hardware ClassCatalog FeaturesRequired TestsRequired HardwareInstall, Boot, kdump

Infiniband[a]

QDR Infiniband, FDR Infiniband, EDR Infiniband

Infiniband_QDR, Infiniband_FDR, or Infiniband_ED

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.

Table 8.10. 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

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

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.

Table 8.11. Omnipath

Hardware ClassCatalog FeaturesRequired TestsRequired Hardware

OmniPath

OmniPath

OmniPath

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

Table 8.12. RDMA over Converged Ethernet (RoCE)

Hardware ClassCatalog FeaturesRequired TestsRequired Hardware

RoCE

10 Gigabit RoCE, 20 Gigabit RoCE, 25 Gigabit RoCE, 40 Gigabit RoCE, 50 Gigabit RoCE, 100 Gigabit RoCE

10GigRoCE, 20GigRoCE, 25GigRoCE, 40GigRoCE, 50GigRoCE, or 100GigRoCE

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.

8.4. Storage

The hardware features that are included in Storage are:

Table 8.13. 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

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

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

Table 8.14. 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

Table 8.15. 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.).
Note

Multi-Readers follow the Multi-Port Adapter criteria.

Table 8.16. 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

Legal Notice

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.