Red Hat Cloud Instance Type Policy Guide
For Use with Red Hat Cloud Instance Type Policy Guide
Abstract
Making open source more inclusive Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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.
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 Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
To be eligible for certification, ensure the following requirements are met:
- An active membership in the CCSP Program. If you are not a member, visit Red Hat Connect for Business Partners to learn more and become a member.
A support relationship with Red Hat, which can be fulfilled through:
- A custom support agreement
- TSANet
- Working knowledge of Red Hat Enterprise Linux (RHEL).
- Use of previously certified or enabled virtual and physical hardware, as presented to the Red Hat product.
1.5. Available Certifications Copy linkLink copied to clipboard!
Certifications are currently available for:
- Red Hat Enterprise Linux versions 8, 9, and 10
- Red Hat Enterprise Linux AI version 1.x
- For the x86_64 Intel and AMD, ARM (by invitation), Power 8, 9, & 10 Little Endian, and System Z platforms.
1.6. Give feedback and get help Copy linkLink copied to clipboard!
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.
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 Copy linkLink copied to clipboard!
2.1. Cloud Instance Type Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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.
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 Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
Instance Type certifications are limited to the versions and architecture of RHEL and their subsequent minor releases.
Example
RHEL 8.4 for x86_64 will carry forward through each minor release such as RHEL 8.5, 8.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:
- Recertification is required
- Red Hat no longer supports that version of RHEL
- The vendor ceases participation in the CCSP Program or
- The Instance is no longer offered and is no longer in use by customers with the corresponding RHEL.
3.1. Lifecycle of Instance Type Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
4.1. Single Instance Type certification Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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.
Both Partners are required to be members of the CCSP program; only the original provider may request Pass-Through certifications.
You may also utilize the pass-through process where the same Instance Type is available with multiple names.
4.5. Red Hat Enterprise Linux AI and Red Hat AI Inference Server Copy linkLink copied to clipboard!
Red Hat Enterprise Linux AI (RHEL AI) and Red Hat AI Inference Server (RHAIIS) deliver production-grade large language models (LLMs) through scalable and cost-effective inferencing across the hybrid cloud, using vLLM inference server to maximize GPU usage. This section explains how the Red Hat AI products relate to each other and how you can use them to achieve Red Hat AI certifications.
- Red Hat AI Inference Server 3.2
Red Hat AI Inference Server (RHAIIS) provides fast and cost-effective inference at scale. It is powered by vLLM, an inference server that maximizes GPU utilization, and enables faster response times. When combined with LLM Compressor capabilities, it increases inference efficiency without sacrificing performance.
To achieve RHAIIS 3.2 certification, you must complete a RHEL cloud instance certification for RHEL 9 or RHEL 10. During your RHEL certification, you can run the vllm_inferencing test with a fully supported RHAIIS container for the AI accelerators included with your platform.
You can also achieve RHAIIS certification by testing on RHEL AI cloud, as outlined in the Red Hat Enterprise Linux AI 3.0 section.
If the vllm_inference testing on RHEL is successful your system qualifies for RHAIIS 3.2 certification.
If your AI accelerator requires software that is not included in RHEL for successful RHAIIS inference testing, the AI Inference feature will be Partner Validated for RHEL and RHAIIS. In this case, the certification publications will include a knowledge base link to guide customers on obtaining and installing the additional software.
- Red Hat Enterprise Linux AI 3.0
Red Hat Enterprise Linux AI (RHEL AI) runs large language models (LLMs) in individual server environments. It includes Red Hat AI Inference Server (RHAIIS) and a bootable image of Red Hat Enterprise Linux (RHEL) with the AI software stack optimized for inference with AI Accelerators. This enables fast, cost-effective inferencing across the hybrid cloud by maximizing throughput and minimizing latency. The platform enables you to deliver production-grade LLMs through scalable and cost-effective inferencing.
To achieve RHEL AI 3.0 certification, you must first complete a RHEL cloud instance certification, which includes RHEL 9.6. After that, you conduct the vllm_inferencing test on Red Hat Enterprise Linux AI 3.0. If the testing is successful, your instance qualifies for both RHEL AI 3.0 and RHAIIS 3.2 cloud instance certification.
RHEL AI includes software not included in RHAIIS or RHEL, as a result, the AI Inference feature is Red Hat Certified for RHEL AI, and Partner Validated for RHAIIS. The RHAIIS certification publication will include a knowledge base link for customer clarity on obtaining the additional software.
- A RHEL cloud instance certification is a prerequisite for a RHEL AI cloud and RHAIIS system certification.
- The RHEL cloud instance certification testing verifies the general functionality of your system.
- The RHEL AI and RHAIIS cloud instance certification testing focuses on ensuring that DataCenter GPUs and AI Inference Accelerators in your instance function correctly.
- Certification policies
The RHEL AI and RHAIIS cloud instance certifications follow the standard RHEL cloud instance certification policies, except where otherwise noted. This includes the general certification policies and requirements.
- RHEL testing must be conducted on production equivalent hardware with production level hypervisors, providing production level VM and bare-metal instances.
- RHEL AI testing must be conducted using an unmodified, bootable RHEL AI container without additional layers.
- RHAIIS testing not conducted on RHEL AI must be conducted on unmodified RHEL 9 or RHEL 10 GA releases, except for the addition of approved AI software stacks.
- RHEL AI and RHAIIS cloud instance certifications support pass-through certification for naming and sizes, similar to RHEL cloud instance certification.
- RHEL AI and RHAIIS cloud instance certifications support component leveraging, component leverage pools, and component pass-through for Data Center GPUs and AI Inference accelerators, similar to RHEL cloud instance certification.
- Testing requirements
The Red Hat Certification Hardware AI test suite includes the necessary tests to obtain a RHEL AI or RHAIIS cloud instance certification. To run the tests, you must first deploy RHEL AI or RHEL on a cloud instance that meets the hardware requirements of RHEL AI cloud or RHAIIS criteria. Instructions for running the tests are found in the Red Hat Cloud Instance Type Workflow Guide.
Red Hat strongly recommends obtaining a Red Hat Certified Engineer accreditation as well as familiarity with image mode vLLM, AI software stacks, and pytorch before participating in RHEL AI or RHAIIS certification.
Chapter 5. Software policies Copy linkLink copied to clipboard!
5.1. Test Suite versions Copy linkLink copied to clipboard!
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.
The current valid package versions are displayed on the results package submission form.
5.2. Red Hat Enterprise Linux versions Copy linkLink copied to clipboard!
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.
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, RHEL 9, and RHEL 10 Base OS 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.
Technical assistance during certification is not offered when using these variants.
5.3. Red Hat Enterprise Linux AI and Red Hat AI Inference Server Versions Copy linkLink copied to clipboard!
- Red Hat Enterprise Linux AI
- New Red Hat Enterprise Linux AI (RHEL AI) requests are accepted only on the current minor release of the RHEL AI product. When a new RHEL AI minor release becomes available, in progress certifications from the previous minor release must be completed within 30 days.
- Red Hat AI Inference Server
- New Red Hat AI Inference Server (RHAIIS) requests are accepted only on the current minor release of the RHAIIS product. When a new RHAIIS minor release becomes available, in progress certifications from the previous minor release must be completed within 30 days.
| Hardware Class | Catalog Features | Required Tests | Required Hardware |
|---|---|---|---|
| Data Center GPU [a] | AI Inferencing Accelerator | vllm_inferencing or Pytorch_inferencing | One member from each GPU design [b] configured with each logical compute units and sufficient memory [c] for inference testing. |
| AI Inference Accelerator [d] | AI Inferencing Accelerator | pytorch_inferencing | One member from each GPU design [e] configured with each logical compute units and sufficient memory [f] for inference testing. |
[a]
Available, but not required, in RHEL versions 9.0 and later certifications.
[b]
An accelerator family is considered to be any set of accelerators with the same design and generation, scaled up or down, that uses the same code path(s) in the same drivers and software stacks.
[c]
Different accelerator memory is not tracked in the context of instance certification.
[d]
Available, but not required, in RHEL versions 9.0 and later certifications.
[e]
An accelerator family is considered to be any set of accelerators with the same design and generation, scaled up or down, that uses the same code path(s) in the same drivers and software stacks.
[f]
Different accelerator memory is not tracked in the context of instance certification.
| |||
5.4. Unmodified Red Hat software Copy linkLink copied to clipboard!
To certify a Red Hat CCSP Instance Type, you must use a standard installation of Red Hat Enterprise Linux without making any modifications. You can adjust the default configuration set by the installer and first-boot utilities, only if you use standard system tools and the changes do not risk data loss. You must document any required changes in a Red Hat Knowledge Base Solution linked to your certification listing.
Do not modify the Red Hat certification test suite. The suite includes a self-check and will fail the supportable test if it detects any modifications.
If you are building bootc container images for RHEL AI certification, ensure the image includes only content from the corresponding Red Hat Enterprise Linux AI product version and associated downloads. Additional packages from other Red Hat products or modifications from outside of the base RHEL AI content are not allowed.
For cloud deployments, Red Hat provides official RHEL AI images on RHEL AI download page for AWS, Google Cloud, IBM Cloud, and Azure. Partners are encouraged to use these images when possible to streamline certification and ensure alignment with supported configurations.
For more detailed requirements and guidance on using bootc containers or cloud images with RHEL AI, refer to the RHEL AI installation documentation.
5.5. Kernel Boot parameters Copy linkLink copied to clipboard!
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.6. SELinux Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
6.1. Production level Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
Changes to BIOS, firmware, or hardware that enable or disable features require recertification. However, partners need not recertify their product for minor fixes, such as correcting small flaws, addressing minor bugs, or modifying superficial elements like splash screens and silkscreens.
Partners must internally test these changes to ensure they do not negatively impact customers, Red Hat Enterprise Linux, or certification status. Red Hat does not require submission of these test results.
Partners must certify UEFI mode, if the cloud instance supports both legacy BIOS mode and UEFI mode. Red Hat expects partners to conduct internal testing for both the modes.
6.3. Settings Copy linkLink copied to clipboard!
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.
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 Copy linkLink copied to clipboard!
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.
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.
6.5. Performance limits Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
A certification engineer creates a test plan by following these steps:
- Determine the Instance Types to be covered by the certification.
- Define and determine the hardware features based on the specification provided.
- Remove unsupported operating system features.
- Apply the minimum test set criteria.
- Add the install, boot, and kdump requirements.
- Apply any other additional policy requirements.
- 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 Copy linkLink copied to clipboard!
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.
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 Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
All Integrated Hardware features, CPU options, memory options, and any other feature a customer cannot remove from an instance must be tested.
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 Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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.
A Red Hat Knowledge Base Article may be added to the certification listing for clarity of Non-OS features.
7.7. Minimum test set Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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 8, RHEL 9, and RHEL 10 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 Copy linkLink copied to clipboard!
The hardware class requirements are categorized in Compute, Management, Network, and Storage.
8.1. Compute Copy linkLink copied to clipboard!
The hardware features that are included in Compute are:
| Hardware Class | Catalog Features | Required Tests | Required Hardware | Install, Boot, kdump |
|---|---|---|---|---|
| System Processors, System-on-Chip (SoC), System-in-Package (SiP) | System Processor (Maximum quantity of Cores) | CORE, CPUSCALING [a], FV_CORE, FV_MEMORY, PROFILER | Maximum number of logical cores [b] and feature set from available CPUs [c] | 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 cpuscaling test is required for cloud instance types where the operating system can control processor C-states or P-states.
[b]
The Core clock speed, FSB speed, cache size, cache depth and manufacturing size are not considered for feature set review.
[c]
The minimum installed memory is required to match the System Memory testing requirement.
| ||||
| Hardware Class | Catalog Features | Required Tests | Required Hardware | Install, 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
| ||||
| 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 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 Copy linkLink copied to clipboard!
The hardware features that are included in Management are:
| Hardware Class | Catalog Features | Required Tests | Required Hardware | Install, 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
| ||||
| 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. |
8.3. Network Copy linkLink copied to clipboard!
The hardware features that are included in Network are:
| 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 | 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.
| ||||
| 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.
| ||||
| 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.
| ||||
| Hardware Class | Catalog Features | Required Tests | Required Hardware | Install, Boot, kdump |
|---|---|---|---|---|
| Infiniband[a] | QDR Infiniband, FDR Infiniband, EDR Infiniband | Infiniband_QDR, Infiniband_FDR, or Infiniband_ED | 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.
| ||||
| 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 | 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.
| |||
| Hardware Class | Catalog Features | Required Tests | Required Hardware |
|---|---|---|---|
| OmniPath | OmniPath | OmniPath | Each interface with the corresponding test for the maximum claimed connection speed. |
| Hardware Class | Catalog Features | Required Tests | Required 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 Copy linkLink copied to clipboard!
The hardware features that are included in Storage are:
| 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 |
[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.
| ||||
| 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
| |||
| 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.).
| ||||
Multi-Readers follow the Multi-Port Adapter criteria.
| 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
| ||||
Providing feedback on Red Hat documentation Copy linkLink copied to clipboard!
We appreciate your feedback on our documentation. Let us know how we can improve it.
Submitting feedback through Jira (account required)
- Log in to the Jira website.
- Click Create in the top navigation bar.
- Enter a descriptive title in the Summary field.
- Enter your suggestion for improvement in the Description field. Include links to the relevant parts of the documentation.
- Click Create at the bottom of the dialogue.