Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

プログラムポリシーガイド

Red Hat Enterprise Linux Hardware Certification 7.31

Red Hat Enterprise Linux Hardware Certification 向け

概要

『Red Hat Hardware Certification プログラムポリシーガイド』では、Red Hat Hardware Certification を実現するための手順的な技術要件およびポリシー要件を説明します。最終更新: 2021 年 6 月 28 日

パート I. 多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメントにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に変更を加える予定です。言語をより包含的に作成する方法は、弊社の CTO、Chris Wright のメッセージ を参照してください

第1章 ハードウェアプログラムポリシーの概要

本書を使用して、認定プロセス、ハードウェア認定に関するポリシー、その後に Red Hat Hardware Certification Team がハードウェアテストプランを作成する方法を説明します。

1.1. Audience

Red Hat Hardware Certification プログラムポリシーガイドは、Red Hat でのハードウェアの認定を検討するハードウェアベンダーを対象としています。Red Hat Enterprise Linux に関する強力な知識が必要です。参加する前に、Red Hat 認定エンジニアの認定が推奨されます

1.2. プログラムの概要

Red Hat Hardware Certification Program は、Red Hat と連携してハードウェアの公式サポートを確立するための正式な手段を提供します。認定済みハードウェアは、Red Hat のグローバルサポートサービス(GSS) によってサポートされ、Red Hat Certification Ecosystem Catalog で公開されています。

認定プロセス中に、Red Hat のエンジニアは、認定を達成するのに必要なハードウェア基準を定義するテスト計画を作成します。Red Hat のエンジニアは、「テスト計画の概要 」で説明されているプロセスに従い、ハードウェア仕様に適したテスト計画を作成します。

ハードウェア認定プロセスの説明は、「認定プロセスの概要」を参照してください。

1.3. 証明書の前提条件

ハードウェア認定プログラムに参加する資格があることを確認するには、重要なポリシーの概要を以下に示します。

  • Red Hat は、ハードウェアモデルを認定しますが、モデルの特定の設定は認定していません。同じモデルの一部として指定されたすべての任意のハードウェア設定をテストすることが想定されます。
  • テストは、Red Hat が提供していないドライバーなど、特別な設定や追加のソフトウェアを使用せずに、Red Hat Enterprise Linux の標準インストールで実行する必要があります。
  • 現在、認定は以下の目的で利用できます。

    • 64 ビット x86、IBM Power Big/Little-Endian、Power9(LE)、IBM System z、および ARM 用の Red Hat Enterprise Linux バージョン 7.x およびバージョン 8.x。
    • Red Hat Enterprise Linux OpenStack Platform Compute 16 and 17.
    • Red Hat Gluster Storage 3.x.
    • Red Hat Hyperconverged Infrastructure 1
    • Red Hat Enterprise Linux for Real Time 7 および 8。
    • Red Hat OpenStack Platform Hardware Bare Metal
    • Red Hat Virtualization
重要

IBM Power9(LE)アーキテクチャーおよび ARM アーキテクチャーでは、認定対象となるために承認されたコラボレーションが必要です。詳細およびディスカッションについては、エンジニアリングパートナーマネージャー(EPM)にお問い合わせください。

第2章 証明書プロセスの概要

前提条件

  • Red Hat との認定関係を確立します。
  • 認定を受ける製品と Red Hat 製品の組み合わせで構成されるテスト環境を確立します。
  • この組み合わせが適切に機能するように、事前テストを実施します。
  • redhat-certification ツールをインストールします。

手順

  1. redhat-certification を使用して、特定のシステムまたはハードウェアコンポーネントの認定要求を作成します。
  2. Red Hat の認定チームは、認定ポリシーをハードウェア仕様に適用し、公式のテスト計画を作成します。
  3. 公式のテストプランで指定したテストを実行し、解析のために redhat-certification を使用して結果を Red Hat に送信します。
  4. 認定チームは、テスト結果を分析し、必要に応じてクレジットをマークし、必要な再テストについて通知します。
  5. 認定対象の項目をカバーする代表的なハードウェアサンプルを Red Hat に提供します。

すべてのテストに合格すると、認定は完了し、エントリーは認定時に外部の Red Hat Hardware Certification Web サイトで公開されます。

第3章 ハードウェア認定ポリシー

3.1. プログラムポリシー

3.1.1. ポリシーの変更

通常、Red Hat は、認定テストと基準の主要な改訂を Red Hat Enterprise Linux のメジャーリリースに制限します。

Red Hat は、ハードウェア認定ポリシー、基準、テストスイートのアップデートを、新しいハードウェアサポート機能が導入されたマイナー OS リリースや、必要と思われるその他のポイントなど、いつでもリリースする可能性があります。

ポリシーの 1 つのバージョンのみがアクティブになります。この現在のポリシーはリリース時に有効であり、以前のすべてのバージョンに優先します。

注記

認定プロセス中に適用されるポリシーガイドのバージョンは、正常に完了すると認定に記録されます。

ポリシーまたは基準への変更は、hwcert-announce-list@redhat.com メーリングリストに通知として送信されます。Web インターフェース(https://www.redhat.com/mailman/listinfo/hwcert-announce-list)から一覧にサブスクライブします。

テストスイートへの変更は、テストスイートのエラータ通知とパッケージ変更ログにも文書化されます。

3.1.2. 認定ライフサイクル

すべての製品のハードウェア認定エントリーは、その製品の一般提供(GA)リリースまで公開されません。

Red Hat Hardware Certification は、公開されているリリースおよび後続のマイナーリリースの更新に対して有効です。たとえば、Red Hat Enterprise Linux 7.1 で付与された 64 ビットの認定は 7.2、7.3 などでも有効です。

認定は、以前の例に関して、過去または将来の主要な Red Hat Enterprise Linux バージョンや、Red Hat Enterprise Linux の追加または代替アーキテクチャー(Red Hat Enterprise Linux 8、Red Hat Enterprise Linux 7 for Intel 64 および AMD64 など)には適用されません。これらの認定は個別に取得する必要があります。

ハードウェアモデルが認定されると、ハードウェアはその認定を以下まで保持します。

  1. 再認証が必要です。
  2. Red Hat は、そのバージョンの Red Hat Enterprise Linux OR に対応しなくなりました。
  3. ベンダーがハードウェアプログラムへの参加を中止します。

このライフサイクルポリシーは、Red Hat Enterprise for Real Time、Red Hat Gluster Storage、Red Hat Hyperconverged Infrastructure、および Red Hat OpenStack のオプションの認定にも適用されます。

3.1.3. 提出ウィンドウ

Red Hat Enterprise Linux の特定のメジャーリリースの新しいハードウェア認定は、通常、2 番目のメジャーバージョンの Red Hat Enterprise Linux がリリースされるまで提出できます。

通常、通知は 30 日前に hwcert-announce@redhat.com メーリングリストに送信され、ウィンドウの終了が通知されます。これらの各ウィンドウクラッシュの計画は、Enterprise Partner Manager と調整する必要があります。

通常ウィンドウ外にある認定要求は、Enterprise Partner Manager で発生する必要があります。

これらのリクエストはケースバイケースで検討されます。送信ウィンドウ以外の認定要求は、オペレーティングシステムに追加の更新を必要としません。

注記

Red Hat Enterprise Linux の新しいメジャーバージョンがリリースされるまでの期間中、パートナーはリリース候補メディアを使用して認定テストを開始することを選択できます。このオプションにより、ベンダーは新規製品の開始時に認定されたシステムを利用できるようになります。

リリース候補と一般提供バージョンの間で大きな変更がある場合は、さらなるテストが必要になる場合があります。このオプションは、メジャーバージョン(7.0、8.0 など)でのみ利用でき、更新リリース(7.1、8.1 など)では使用できません。

3.1.4. 元の認定

認定済みハードウェアのパートナーサポートは、Red Hat Hardware Certification の基礎的な部分です。認定されるハードウェアに関するすべての要求と情報は、元のハードウェアの製造元から Red Hat に提出する必要があります。

ハードウェアパートナーは、ハードウェアの任意の部分とテストに独自の外部パートナーを使用できますが、すべての利点と追加コストはパートナーの責任です。

Red Hat は、認定要求を送信したパートナーとのみ対話し、送信パートナーとして Red Hat が簡単に特定できる vendor+make+model の値で元の認定を提出します。

3.1.5. 公開されていない認定

Red Hat に提出されたすべてのハードウェア認定要求は、ハードウェアカタログで公開されたエントリーの要求であると見なされます。証明書は公開されていないままにすることができます。この場合、パートナーの要求時に認定は Hardware Catalog にまだ公開されていません。

公開されていない認定は、公開された認定と同じポリシーに従いますが、インターネットでは利用できません。

認定基準を満たさない認定要求は、デフォルトではデフォルトでは公開されません。

重要

証明書を公開しないようにするための要求は、証明書が最初に開かれたときに、証明書要求のコメントダイアログで行う必要があります。

注記

通常、Red Hat の記事やソリューションで提供されるコンテンツの非公開認定でコメントを提供できます。

3.1.6. コンポーネントの影響

ハードウェア認定テストプロセスの効率を最大化するために、Red Hat では、ハードウェア認定パートナーが Red Hat Enterprise Linux の同じ(またはそれ以降のマイナー) リリースとアーキテクチャーの特定のテストケースを再利用または活用でき、テスト計画の要件を満たすことができます。コンポーネントは同様のモデル間で再利用されます。

すべてのハードウェアを網羅した Red Hat Enterprise Linux の品質保証(QA)プロセスが必要になります。この QA プロセスは、この機能を提供するために Red Hat によって活用されます。このようなパートナーは、「Component Pass-Through 認定」で説明されているように、他のパートナーのテストを利用できません活用に関するその他の要件は、「ハードウェアクラス要件」を参照してください

3.1.7. コンポーネントレバレッジプール

レバレッジプールとは、システムベンダーが、後のシステム認証で活用することを目的としたコンポーネントの一覧を確立するために、システムベンダーによって実行される一連の非公開コンポーネント認定です。レバレッジプールには次の条件が適用されます。

  • コンポーネントの通常の認定基準を渡すには、レバレッジプール証明書が必要です。
  • ハードウェアカタログの通常の Create ページを使用して、レバレッジプール証明書を開く必要があります。
  • Leverage Pool に設定する認証のタイプを要求するコメントを追加する必要があります。
  • レバレッジプール認定では、1 つのコンポーネントのみを使用できます。
  • システム認証でレバレッジプール認定テスト結果を使用するには、レバレッジプール認証の認証 ID をシステム認証テスト計画のレバレッジフィールドに入力する必要があります。

3.1.8. システムのパススルー認定

パススルー認定とは、サードパーティーのシステムまたはコンポーネントが、元のハードウェアメーカーによって以前に認定されたハードウェアと同じ認定を付与される能力を指します。

システムメーカーは、元のベンダーがシステムに付与した認定を、元のベンダーの別のシステムに拡張できます。

  1. サードパーティーからのパーミッションがあること
  2. Red Hat によって認定された元のモデルのサブセットと見なされなくなるような方法でサードパーティーがハードウェアを変更しないようにするための仕組み および
  3. サポートと代表的なハードウェアの責任を拡張して、サードパーティのハードウェアが関係する状況を含めます (Hardware Certification Agreementセクション 1.2 および 1.3 を参照)。

さらに、サードパーティーは別のベンダーにパススルー認定を拡張することはできません。両方のベンダーが Hardware Certification プログラムのメンバーである必要がありますが、元のベンダーのみがパススルー認定を要求することができます。

パススルーリクエストは、元の証明書のハードウェアカタログエントリーの Advanced タブにある Pass-Through ダイアログを使用して開く必要があります。

ベンダーは同じハードウェアに対して同じベンダーの名前が複数あるパススループロセスも使用できます。

3.1.9. コンポーネントのパススルー認定

コンポーネントベンダーは、コンポーネントのベンダーがパススループロセスを使用できます。

(a)サードパーティーからのパーミッションがあること

(b)サードパーティーがハードウェアを変更しないようにするための仕組み

(c)サポートと代表的なハードウェアの責任を拡張して、サードパーティのハードウェアが関係する状況を含めます (Hardware Certification Agreementセクション 1.2 および 1.3 を参照)。

サードパーティーベンダーは、パススルー認定を別のベンダーに拡張しない場合があります。両方のベンダーが Hardware Certification プログラムのメンバーである必要がありますが、元のコンポーネントベンダーのみがパススルー認定を要求することができます。元の認定およびパススルーの認定は公開または公開されません。

サードパーティーのシステムベンダーは、標準の PCIe フォームファクターイーサネット、ファイバーチャネル、Infiniband、iSCSI、SATA、SAS、RAID、CNA、および WLAN オプションカードのシステム認定を利用することを選択できます。

通常のレバレッジポリシーは、コンポーネントパススルー認定を利用することで、内部 QE プロセスを含むシステム認定に適用されます。内部 QE プロセスには、利用で認定されるすべてのハードウェアが含まれます。コンポーネントパススルーの認定は、レバレッジプールポリシーに従います (プールを利用するプログラムポリシーコンポーネントを参照)。

コンポーネントのパススルー認定は、元のコンポーネントベンダーによる元のコンポーネント認定のハードウェアカタログエントリーの Advanced タブの下にある Pass-Through ダイアログを使用して開きます。

正常に完了すると、パススルー認定がシステムベンダーから利用可能になります。システムベンダーは、システム認証テスト計画のレバレッジ値としてパススルー認証 ID を提供できます。

3.1.10. 再認定

元のテスト計画基準を変更するモデルへの変更には、再認定が必要です。モデルの変更には、ハードウェア、BIOS、またはファームウェアが含まれます。

サポートされる CPU の数を増やしたり、ネットワークコントローラーやストレージコントローラーなどの新しいコンポーネントを追加したりするには、再認定が必要です。

ハードウェアの変更を処理するために、新しい補助認定を開く必要があります。

3.1.11. 既知の問題

モデルには、Red Hat Enterprise Linux に関する既知の重大な問題はありません。Red Hat は認定プロセスの一環として、お客様に影響する未解決の重大な問題が存在しないことを確認するために調査します。

3.1.12. ハードウェアのサンプル

自己テスト認定と Red Hat テスト認定の両方で、Red Hat のエンジニアリングチームおよびサポートで代表的なハードウェアサンプルが必要です。このハードウェアは、Red Hat が顧客の問題を検証、デバッグ、修正するため、または将来の製品テストで利用するか、その両方に使用されます。ハードウェアサンプルについては、以下の条件に注意してください。

  • ハードウェアサンプルは、すべてのモデル機能のフル機能を提供する設定でなければなりません。
  • 規定されたテスト計画 (テスト計画の概要)は、最小構成ガイドラインとして使用できます。ただし、Red Hat サポートは、特定のハードウェア、計画されているお客様のデプロイメント、およびその他の要因に応じて、特定の構成を要求する場合があります。
  • ハードウェアサンプルには、適切なインストールおよび操作に必要なアクセサリーを追加する必要があります。
  • ハードウェアは、認定の投稿前に Red Hat の場所に存在する必要があります。
  • Red Hat サポートは、ハードウェアの将来の提供の判断で受け入れる場合があります。
  • テクニカルアカウントマネージャー(TAM)またはサポート担当者は、場所と設定の詳細を提供でき、ハードウェアの出荷前にお問い合わせください。

3.2. RHEL 8 のハードウェアポリシー

RHEL 8 以降、ハードウェア認定は、Red Hat 認定カタログで公開される認定のより詳細な表示を実装します。ただし、以前のバージョンの RHEL に適用されたすべての確立された手順とポリシーは、RHEL 8 にも適用されます。認定のきめ細かい発行を実装すると、顧客のニーズを満たす認定ソリューションを見つけて使用するために必要な顧客の労力が軽減されます。この追加の詳細レベルには、ハードウェアの認定された機能(機能)が含まれます。

3.2.1. 対応している RHEL バージョンおよびアーキテクチャー

ハードウェア認定は、以下の RHEL バージョンおよびアーキテクチャーでサポートされます。

RHEL のバージョンアーキテクチャー

RHEL 7

  • x86_64
  • IBMz
  • RHELforPowerBE
  • RHELforPowerLE

RHEL 8

  • x86_64
  • IBMz
  • AARCH64
  • RHELforPowerLE

3.2.2. コンポーネント認定

Red Hat は、引き続き RHEL 8 でシステムコンポーネントのモデルを認定します。コンポーネントとは、パートナーが提供する仕様で定義されている 1 つ以上のシステム機能の固定のサブセットを実装するハードウェアです。また、Red Hat は、RHEL 8 用のコンポーネントハードウェアを認定する際に、パススルー、レバレッジのためのパススルー、およびコンポーネントレバレッジプールを引き続きサポートします。仕様からの機能のスーパーセットは、異なる機能セットの一意のコンポーネントモデル名によって除外されない限り、モデル定義の一部と見なされます。

Red Hat は、Red Hat が定義および指定する、特定して有効な RHEL 8 ハードウェア機能に基づいて、コンポーネント認定のテストプランを作成します。RHEL 8 ハードウェア認定のテスト計画は、以前の RHEL リリースのプロセスと基準を使用して引き続きビルドおよび機能します。

成功基準

  • Red Hat が提供する認定テスト計画に従ってすべての有効な機能をテストして合格すると、コンポーネントは RHEL 8 で認定されます。
  • RHEL 8 では、1 つ以上の有効な機能がテストされ、テスト計画に従って渡されたコンポーネントが RHEL 8 で認定されます。

3.2.3. システムの認定

Red Hat は、引き続き RHEL 8 でシステムモデルの認定を行います。システムは、パートナーが提供する仕様で定義されているコンポーネントハードウェアの RHEL 8 の起動可能、インストール可能、および動作可能なコレクションです。また、Red Hat は、RHEL 8 のハードウェア認定で、パススルー、レバレッジ、補足、およびパススルーのサポートも継続します。

この仕様は、標準機能、または任意の機能としてコンポーネントを定義できます。システムモデルは、仕様で明示的に除外された場合を除き、標準および任意のコンポーネントの完全なコレクションからすべての機能を提供すると見なされます。

Red Hat は、Red Hat が定義および指定する、特定して有効な RHEL 8 ハードウェア機能に基づいて、システム認定のテストプランを作成します。RHEL 8 ハードウェア認定のテスト計画は、以前の RHEL リリースのプロセスと基準を使用して引き続きビルドおよび機能します。

成功基準

  • 有効な機能がすべてテストされ、Red Hat が提供する認定テスト計画に従って渡すと、RHEL 8 でシステムが認定されます。
  • RHEL 8 では、テストして合格し、最低 1 つのコンピュート、管理、ネットワーク、およびストレージ機能のセットを提供する場合、RHEL 8 でシステムが認定されます。
注記

最小限の機能セットがモデル内の標準として提供されていない場合は、顧客に明確さを提供するために、知識ベースエントリーを追加できます。

3.2.4. 証明書および機能の公開

成功基準を満たす認定を公開することができます。テスト計画内のすべての機能は、認定の公開時に認定カタログに一覧表示されます。この機能は、以下のステータスのいずれかと共に表示されます。

  • サポート対象: テストして合格、またはテストして条件付きで合格
  • サポート対象外: テストして不合格、またはテストされていません。

3.2.5. カタログ検索結果

認定済みのハードウェアは、テスト計画で特定されたすべての機能を含む詳細リストと共に Red Hat 認定カタログに表示されます。お客様は、製品の名前または使用可能な認定機能でカタログを検索できます。

お客様が機能別に製品を検索すると、プロダクトの認定でサポート対象の機能が検索リクエスト内の機能と一致する場合にのみ、製品が検索結果に表示されます。これにより、必要な機能に対して認定されているハードウェアを検索できます。変更されたカタログ検索機能により、認定に適用されるナレッジベースはフィルターできます。

重要

テストされていない機能、またはシステムが最初に認定されたときに合格しなかった機能は、システムの補足認定を使用して更新できます。追加機能は、認定されている場合には認定カタログに追加されます。

3.3. RHEL 7 およびレイヤード製品のハードウェアポリシー

以下のポリシーは、RHEL 7 およびレイヤード製品に含まれます。

3.3.1. Red Hat Enterprise Linux

Red Hat Hardware Certification は、Red Hat Enterprise Linux 製品ファミリーで利用できます。認定は、バージョンおよびアーキテクチャーのペア(例: Red Hat Enterprise Linux 7 for x86_64)ごとに検証され、バリアント(Red Hat Enterprise Linux for Desktops)では提供されません。

Red Hat Enterprise Linux 製品の重要な機能は、すべてのファミリーメンバーが共通のコア(カーネル、開発ツールチェーン、ライブラリーなど)を共有することです。したがって、認定は同じバージョンとアーキテクチャーのすべてのバリアントに適用されます。

現時点では、Red Hat は、Red Hat Enterprise Linux 7.x または 8.x リリースで実施されたハードウェアテストの結果のみ受け付けます。

3.3.2. Red Hat Enterprise Linux OpenStack Platform Compute

Red Hat Enterprise Linux OpenStack Platform Compute は、Red Hat Enterprise Linux 向けに最適化され、統合した Red Hat OpenStack テクノロジーを提供します。

Red Hat Enterprise Linux OpenStack Platform Compute は、Red Hat Enterprise Linux の機能を拡張する追加パッケージで構成されており、固有のカーネルや特殊ハードウェアのサポートを必要とせずに、仮想マシンに 数万台 に迅速にスケールアップします。この共通ベースにより、サーバーが Red Hat Enterprise Linux OpenStack Platform Compute 認定を受けるためには、仮想化による Red Hat Enterprise Linux 認定を超える追加のテストは必要ありません。

この認定は、Red Hat Enterprise Linux 7 および Red Hat Enterprise Linux 8 で送信される新しい Intel64 および AMD64 サーバー認定すべてに自動的に含まれます。

ベースの Red Hat Enterprise Linux 認定は、仮想化テストを含む正常に完了する必要があり、ベース認定は Red Hat Enterprise Linux OpenStack Platform Compute 認定が処理される前に提出される必要があります。

3.3.3. Red Hat Enterprise Linux for Real-Time(RHEL7 および RHEL8)

Red Hat Enterprise Linux for Real-Time は、予測可能性を提供し、一貫した低レイテンシーのシステム応答時間を実現します。これらの Real-Time 製品は、Red Hat Enterprise Linux を拡張する追加パッケージで構成されています。これには、独自のチューニング済みの代替カーネルが含まれます。これらのパッケージは、Red Hat Enterprise Linux のユーザースペース部分に追加されますが、変更はされません。

ハードウェア認定テストスイートには、ベースの Red Hat Enterprise Linux 認定を完了した後にリアルタイム認定を達成するために実行できる追加の Real-Time テストが含まれています (ハードウェアクラス要件を参照)。これらのテストを実行するには、追加の Real-Time パッケージがインストールされ、実行している必要があります。

ハードウェア認定パートナーは、既存の Red Hat Enterprise Linux 7 または Red Hat Enterprise Linux 8 の認定エントリーを選択し、Advanced セクションに移動して Create New Layered Product Certification - RHEL Real-Time 見出しの下にあるフィールドに入力することで、認定ワークフローで新しい Real-Time 認定リクエストを作成できます。

リアルタイムの結果を確認する前に、ベースの Red Hat Enterprise Linux 認定が完了して投稿されている必要があります。

3.3.4. Red Hat OpenStack Platform for Real-Time アプリケーション

Red Hat Openstack Platform for Real-Time Applications は、パフォーマンスに敏感な仮想環境向けに、非常に低レイテンシーを提供するように設計されています。Red Hat OpenStack Platform for Real-Time Applications 製品は、独自のチューニングされた代替カーネル、KVM、追加の Tuned プロファイルなど、Red Hat OpenStack Platform を拡張する追加パッケージで構成されます。これらのパッケージにより、Real-Time アプリケーションは RHOSP を使用してゲスト仮想マシンで実行できます。

Red Hat Hardware Certification Test Suite には、追加の fv_real-time テストが含まれており、これは Red Hat OpenStack Platform for Real-Time Applications の認定を実現するために実施されます。このテストは、Red Hat OpenStack Platform for Real-Time Applications 認定のデフォルトテスト計画です。Red Hat Enterprise Linux for Real-Time および Red Hat Enterprise Linux の認定を完了したら、Red Hat OpenStack Platform for Real-Time Applications の認定を開く必要があります。CPU コアごとのメモリーチェックに合格しない場合、fv_real-time テストは自動的に計画されません。このテストは、CLI を使用して手動で計画できます。

ハードウェア認定パートナーは、既存の Red Hat Enterprise Linux 7 または Red Hat Enterprise Linux 8 の認定エントリーを選択して、Create New Layered Product Certification - RHEL Real-Time 見出しの下にあるフィールドに入力することで、認定ワークフローに新しい Red Hat OpenStack Platform for Real-Time アプリケーション認定リクエストを作成できます。

Real-Time カーネル(kernel-rt)を実行しているホスト RHEL OS から fv_real-time テストを実行し、システムでサポートされている完全な仮想化を実行します。

重要

Red Hat Enterprise Linux for Real Time の認定は、Red Hat OpenStack Platform for Real-Time アプリケーションの結果を確認する前に完了して公開する必要があります。

3.3.5. オンプレミス向けの Red Hat Gluster Storage

Red Hat Gluster Storage for On-Premise は、信頼できる Red Hat ソフトウェアを Intel 64 および AMD 64 のコモディティーハードウェアと組み合わせており、高コストでプロプライエタリーなストレージシステムが必要なくなります。

Red Hat Gluster Storage は、追加パッケージと Red Hat Enterprise Linux ISO を組み合わせることで、簡単にデプロイできます。Red Hat Enterprise Linux をベースとしているため、Red Hat Gluster Storage の認定には、追加のハードウェア仕様レビューのみが必要になります。Red Hat Enterprise Linux 7 の認定テスト以外の追加テストは必要ありません。このレビューでは、Red Hat Gluster Storage 3.0 Compatible Physical, Virtual Server and Client OS Platforms Knowledge Base の「最小ハードウェア要件 」セクションで説明されているように、サーバーの仕様が Red Hat Gluster Storage イメージのサポートされるハードウェア構成に準拠していることを確認します。

パートナーには、新しい Red Hat Enterprise Linux 7 サーバー認定要求を作成する際に、対応する Red Hat Gluster Storage 認定を作成するオプションがあります。既存の Red Hat Enterprise Linux 7 認定サーバー用に Red Hat Gluster Storage の認定エントリーを作成するパートナーは、必要な Red Hat Enterprise Linux 7 の Advanced セクションに移動して、Create New Layered Product Certification - Red Hat Gluster Storage の見出しの下にあるフィールドに入力することで、Hardware Catalog でこの認定を行います。現在、Red Hat Gluster Storage の認定を作成することはできず、Red Hat Gluster ストレージの認定を希望するパートナーは、Red Hat Storage Architectural review プロセス で詳細を確認してください。

Red Hat Gluster Storage の認定が処理される前に、Red Hat Enterprise Linux ベースベースの認定が正常に完了および公開されている必要があります。

Red Hat Gluster Storage の認定プロセス時に、システムの仕様は、最小の Red Hat Gluster Storage ハードウェア要件と比較されます (詳細は「Red Hat Storage Architectural Review Process 」を参照してください)。

要件を満たさないシステムは拒否されます。

システムが必要な要件を満たす場合は、Red Hat Enterprise Linux の認定エントリーで、関連する Red Hat ナレッジベースアーティクルにチェックマークが付けられます。Red Hat Enterprise Linux 認定の該当する Red Hat ナレッジベースのエントリーは、エンドユーザーに適切で十分な情報を提供できるように、確認されています。必要なナレッジベースの確認と更新が完了したら、Red Hat Gluster Storage の認定を公開できます。

3.3.6. Red Hat Virtualization

Red Hat Virtualization(RHV)は、Red Hat Enterprise Linux(RHEL)に構築されたエンタープライズレベルの仮想化プラットフォームです。RHV は、RHEL カーネル、カーネルベースの仮想マシン(KVM)テクノロジー、および oVirt 仮想化管理プロジェクトから派生します。この共通ベースにより、仮想化を使用した RHEL 認定以外の追加テストは必要ありません。

RHEL 8 の通常の仮想化テストでは対応していない、より高度な仮想化機能については、RHEL 8 の認定中に追加のテストを実施することができます。これらの機能は、ゲストとホストマシン間の特定のハードウェア割り当てを対象としています。追加のテストは RHEL 8 で行うことができますが、追加の仮想化機能は RHV 4.4 証明書エントリーにのみ表示されます。

RHV 認定は、すべての新しい Intel64 および AMD64 サーバー認定に対して自動的に含まれます。ベースの RHEL 認定は、仮想化とともに正常に完了する必要があります。Red Hat Virtualization の認定が処理される前に公開する必要があります。

現時点では、Red Hat Virtualization の認定は RHV 4.2、RHV 4.3、および RHV 4.4 でサポートされ、以下のようになります。

  • RHV 4.2 for x86_64 アーキテクチャー(RHEL 7.0 から RHEL 7.4 までのベース RHEL バージョンに対応)
  • RHV 4.2 for x86_64 および ppc64le アーキテクチャー(7.5 から 7.6 までのベース RHEL バージョンに対応)
  • RHV 4.3 for x86_64 および ppc64le アーキテクチャー(ベース RHEL バージョン 7.7 に対応)
  • RHV 4.4 for x86_64 および ppc64le アーキテクチャー(8.0 から 8.2 までのベース RHEL バージョンに対応)

3.4. ソフトウェアポリシー

3.4.1. テストスイートバージョン

Red Hat は、すべてのテストに最新バージョンのテストスイートパッケージを使用することを推奨します。テストスイートパッケージの新規バージョンが利用可能になると、以前のバージョンを使用して作成された結果は引き続き 3 カ月間受け入れられます。この期間の最後に、Hardware Catalog は自動的に古いバージョンで作成された結果パッケージを拒否し、テストは有効なパッケージで繰り返す必要があります。現在の有効なパッケージバージョンは、結果パッケージの送信フォームに表示されます。

重要

テストスイートは、認定テストの実行に対して変更しないでください。テストスイートは自己チェックを実行し、変更されると情報テストに失敗します。

3.4.2. Red Hat Enterprise Linux バージョン

Red Hat Enterprise Linux バージョンの最新のマイナーリリースを常に推奨しますが、完全なテスト基準を満たすすべてのリリースを使用できます。完全にサポートされた最も早いリリースでテストすることで、潜在的な顧客ベースを最大化できます。テスト中に複数のマイナーリリースを使用する場合は、最新のマイナーリリースがモデルの後続リリースとして使用されます。特定のモデルの機能によっては、必要なもの以外の最小リリースが必要になる場合があります。

Red Hat Enterprise Linux は、Red Hat Hardware Certification Review チームまたはソフトウェアのドライバーポリシーに従って推奨される場合を除き、エラータパッケージで更新しないでください。不要なエラータがインストールされていてテストを行った場合は、再テストが必要になる場合があります。

備考

テストスイートは、Red Hat Enterprise Linux 7 Server および Red Hat Enterprise Linux 8 ベース OS に対してのみテストされています。同じメジャーバージョンの Red Hat Enterprise Linux のすべてのバリアント(ワークステーション、デスクトップなど)は、共通のコアパッケージセットを共有します。これらのバリアントの使用は認定テスト時に許可されますが、必要なパッケージのサブセットを指定するだけで、再テストが必要になる場合があります。

これらのバリアントを使用する場合、認定中のテクニカルサポートは提供されません。

http://people.redhat.com/gcase/rhcert-2/ks/ で利用可能な適切な RHEL キックスタートファイルで説明するように、OS を設定します。

3.4.3. Red Hat Enterprise Linux for Real-Time バージョン

Red Hat Enterprise Linux for Real-Time テスト結果は、対応する Red Hat Enterprise Linux の現行および以前のマイナーリリースにインストールされた Realtime 製品の現在のマイナーリリースでのみ許可されます。Red Hat Enterprise Linux for Real-Time マイナーリリースが新たにリリースされると、以前の Realtime マイナーリリースで引き続き 30 日間受け入れられます。

3.4.4. 未変更の Red Hat Enterprise Linux

Red Hat Hardware Certification Program では、変更を加えずに、Red Hat Enterprise Linux の標準インストールでテストする必要があります。標準のシステムツールの 1 つを使用して構成を変更できる場合、およびデフォルト構成がデータ損失の可能性を生み出さない場合は、インストーラーおよび初回起動ユーティリティーによって提示されるデフォルト構成への変更が許可されます。デフォルト設定に必要な変更は、認定リストに関連付けられている Red Hat ナレッジベースソリューションに文書化されている必要があります。したがって、Red Hat 認定システムを購入するお客様は、システムが Red Hat Enterprise Linux の標準インストールで期待どおりに機能することが期待できます。

3.4.5. カーネルブートパラメーター

追加のカーネルパラメーターは、(a)ハードウェア構成を修正するために使用され、(b)機能を無効にせず、(c)使用されていないときにデータが失われる可能性がない場合に使用できます。たとえば、カーネルパラメーター noacpi が、そのパラメーターなしでインストールされないシステムを起動する必要がある場合は、許容範囲になります。ただし、noacpi が指定されていない場合、システムはインストールしてもデータが破損すると、問題が解決されるまで認定は中断されます。

関連情報

3.4.6. カーネルのテイント値

Red Hat は、テイントのマークが付けられていない(値が 0)カーネルを実行しているシステムでハードウェア認定テストをパートナー企業が実施することを想定しています。サポートされ、必要なカーネルドライバーの結果が Red Hat Driver Update Program または表面的な無害なカーネル警告からのものである場合、テイントのマークが付けられていないカーネルの警告を許容する場合があります。認定中に承認されたゼロ以外の taint の値は、認定公開に関連する Red Hat ナレッジベースソリューション に記載されています。

3.4.7. ドライバー

Red Hat は、ドライバーをテクノロジープレビューとして提供し、今後予定されている製品のイノベーションへの早期アクセスを付与する場合があります。これらのドライバーは完全にサポートされておらず、認定を実現するためには使用できません (「テクノロジープレビュー機能のサポート範囲」を参照)。ドライバーは、Red Hat Enterprise Linux 製品ドキュメント のリリースノートで、テクノロジープレビューとして指定されます。

Red Hat は、一部のドライバーが Red Hat Enterprise Linux に含まれることができないことを認識しています。追加のドライバーの使用は推奨されませんが、特定のケースでは、そのようなドライバーが認定プロセス中に使用される場合があります。このようなケースには、以下が含まれます。

注記

ナレッジベースエントリーは、ドライバー更新プログラムが使用されるすべての認定に関連付けられます。

ハードウェア認定で使用されている、Red Hat が正式に同梱されていない追加のドライバーは、kerneldrivers.org で説明されている標準の kmod プロセスを使用して構築する必要があります。承認されたシンボルのみを使用し、サブシステムを追加できず、提供された Red Hat と置き換えまたは競合することはできません。Red Hat が提供するドライバーにすでに存在するハードウェアサポートは競合とみなされます。追加ドライバーでは、Red Hat による品質およびソースのレビューは実行されません。

追加のドライバーの使用が有効と思われる場合は、ドライバーの名前、ドライバーが必要なハードウェアを含む認定要求にコメントを追加する必要があります。上記のドライバー構成の推奨事項が満たされている場合は、認証が開かれたときに、ドライバー情報およびエンドユーザーのカスタマーサポート情報(該当する場合)へのベンダーの URL アドレスが表示されます。

重要

テクノロジープレビュードライバーは Red Hat ではサポートされず、認定中は使用されない場合があります。

重要

可能な場合は、追加のドライバーおよびテクノロジープレビュードライバーを使用せずにテストを実施する必要があります。info テストは、すべてのテクノロジープレビューおよび Red Hat 以外が提供するドライバーに対して失敗を返します。

警告

Red Hat Enterprise MRG Realtime または Red Hat Enterprise Linux for Realtime カーネルでは提供されていないドライバーは、リアルタイムテストでは許可されません。これには、Red Hat が提供するドライバーディスク、テクノロジープレビュードライバーパッケージ、およびサードパーティードライバーが含まれます。

注記

上記の要件は、ベンダーが認定済みのハードウェアを持つ代替のオープンソース、プロプライエタリー、バイナリー、ソースコード、またはその他のドライバーを提供しないようにする必要があります。この基準は、Red Hat Hardware Certification テストおよびリストにのみ適用されることを目的としています。

3.4.8. SELinux(Red Hat Enterprise Linux 7 および 8)

認定は、ターゲットポリシーを使用して SELinux を有効にし、Enforcing on で実行する必要があります。テストスイートは、これらの条件をチェックします。

3.4.9. ホストとしての Red Hat Enterprise Linux

Red Hat Enterprise Linux 7 および 8 では、64 ビットアーキテクチャーでの認定時に KVM 仮想化をテストする必要があります。「ハードウェアクラス要件: 必要なテストの特定一覧」を参照してください。

3.4.10. ゲストとしての Red Hat Enterprise Linux

仮想化環境での Red Hat Enterprise Linux に関連する認定は、承認されたコラボレーションパートナーシップが確立されている場合にのみ発生する可能性があります(詳細については、パートナーマネージャーにお問い合わせください)。再認証を含むすべてのポリシーと基準は、Red Hat Enterprise Linux に示される仮想化ハードウェアに適用されます。基礎となるハードウェアや仮想化レイヤーへの変更は、必要に応じて開示およびテストするベンダーの責任です。

3.5. BIOS およびファームウェアポリシー

3.5.1. 実稼働レベル

テスト中は BIOS/ファームウェアのバージョンを実稼働レベルにする必要があります。

機能は、主な変更点なしに完了します。

BIOS/Firmware ポリシー変更基準を満たすには、テストに続く BIOS/ファームウェアの変更基準が必要になります。認定の公開日から、テスト済みまたはそれ以降のリビジョンをご利用いただく必要があります。

3.5.2. 変更

機能を有効または無効にする BIOS またはファームウェアの変更には、再認定が必要です。BIOS を変更してバグを修正したり、スプラッシュ画面などの表面的なアイテムを変更したりするには、再認証は必要ありません。ハードウェア、Red Hat Enterprise Linux、または認定ステータスに悪影響を与えることを確認するために、これらの変更のベンダー内部テスト。ただし、このテストの結果を Red Hat に提出する必要はありません。

3.5.3. 設定

必要な BIOS/ファームウェア設定情報は、認定要求のコメントに提示する必要があります。推奨される設定データやデフォルト設定データの提供は推奨されますが、必須ではありません。ベンダーが提供する設定情報は、関連する Red Hat ナレッジベース ソリューションを使用して認定リストで提供しています。代替構成設定を検証してもデータ破損の問題が発生したり、機能が予期せず中断したりすることは、ハードウェアベンダーの責任です。

ハードウェア機能や機能を有効または無効にするユーザーが設定可能な BIOS 設定は、テスト中に有効になるように設定する必要があります。たとえば、ネットワークインターフェースを有効にするには、オンボードネットワークを制御する設定を設定する必要があります。

3.5.4. 読み込み済みの OS

OS のサポートされているメカニズムを介して読み込まれるファームウェアは、上記のガイドラインに従い、サポートされているバイナリー RPM パッケージへの永続リンクがある場合に使用できます。Red Hat 製品に含まれていない OS Loaded ファームウェアは、認定リストに関連付けられた Red Hat ナレッジベースソリューションに記載されています。

3.5.5. ハードウェア正常性のサブテスト

Hardware Health サブテストは、ハードウェアが対応しているかどうかをテストし、要件を満たしていることを確認し、既知のハードウェアの脆弱性があるかどうかを確認します。サブテストは以下を行います。

  • Red Hat Enterprise Linux(RHEL)カーネルが、サポートされていないハードウェアを識別しないことを確認します。カーネルがサポートされていないハードウェアを特定すると、システムログにサポートされていないハードウェアメッセージを表示し、サポート対象外のカーネルテイントがトリガーされます。このサブテストにより、サポートされていない構成や環境で Red Hat 製品を実行することから生じる可能性のある実稼働環境のリスクが実現できなくなります。

    ハイパーバイザーでは、パーティション、クラウドインスタンス、その他の仮想マシンの状況では、仮想マシンが RHEL に提示されるハードウェアデータに基づいて、サポートされていないハードウェアメッセージまたはテイントがトリガーされる可能性があります。

  • test(SUT)のシステムが、ハードウェアの最低要件を満たしていることを確認します。

    • RHEL 8: 最小システム RAM は、CPU の論理コア数ごとに 1.5GB である必要があります。
    • RHEL 7: 最小システムメモリーは、CPU の論理コア数ごとに 1GB である必要があります。
  • カーネルが既知のハードウェアの脆弱性を報告しているかどうかを確認します。脆弱性を解決するには、お客様がアクティブな手順を実行する必要がないように、多くの軽減策が自動的に行われます。これを使用できない場合もあります。これらの残りのケースでは、システム BIOS/ファームウェアの設定に変更を加える必要がある場合がありますが、すべての状況で変更できないシステム BIOS/ファームウェアの設定を変更する必要があります。
  • システムにオフライン CPU がないことを確認します。
  • 同時マルチスレッド(SMT)がシステムで利用可能で、有効かどうかを確認してください。

これらのテストのいずれかに失敗すると、テストスイートの WARN が表示され、適切かつ意図された動作を持つように、パートナー企業により検証される必要があります。

成功基準

  • カーネルには UNSUPPORTEDHARDWARE テイントビットが設定されていません。
  • カーネルは、サポートされていないハードウェアシステムメッセージを報告しません。
  • カーネルは、脆弱性のある脆弱性を脆弱と報告しません。
  • カーネルは、範囲外として、インストールしたメモリー比率のロジックコアを報告しません。
  • カーネルは、オフライン状態で CPU を報告しません。

3.6. ハードウェアポリシー

3.6.1. スタンドアロン

Red Hat Enterprise Linux のみの環境でフル機能を有効にするには、すべてのハードウェアおよびソフトウェアが含まれている必要があります。たとえば、管理コンソールの起動や設定が必要なシステムは、コンソールが別のシステムの Internet Explorer からしかアクセスできない場合は、認定の対象にはなりません。

3.6.2. コンポーネントおよび周辺機器

個別に一覧表示されるコンポーネントと周辺機器は、アーキテクチャーで利用可能な場合、仮想化でテストする必要があります。ハードウェアカタログに記載されているコンポーネントには、コンポーネントが Red Hat Enterprise Linux との互換性を示しているものの、特定のシステムでの動作を保証できないため、互換性を確保するためにシステムベンダーに連絡する必要があることをお客様に通知する一般的な免責事項があります。

3.6.3. 実稼働レベル

Red Hat Hardware Certification Program では、実稼働レベルのハードウェアによるテストが必要です。同等の実稼働レベルでアップグレードされた実稼働前のハードウェアも受け入れ可能です。

3.6.4. 変更

認定モデルは、認定テスト結果のリグレッションや基準の変更が発生するような変更はできません。機能を追加または変更しない小さな変更は、ベンダーによってテストされることが予想されますが、再提出する必要はありません。たとえば、ケーブルの長さまたはパッシブバックプレーンのポート数が変わります。ベンダーは、機能を追加するものを含む重要な変更を Red Hat に通知する必要があります。再認定が必要な場合は、元の認定から新たな補助認定エントリーを開く必要があります。必要な追加のテストは、元の提出と同じ Red Hat Enterprise Linux バージョンを使用して実行する必要があります。更新されたテストと送信間でバージョンの不一致が発生した場合は、明確にするために、Red Hat ナレッジベースの記事が元の認定に関連付けられている場合があります。補助認定は他の認定と共にキューで処理されますが、公開されていません。

3.6.5. 設定の制限

Red Hat 製品の制限を超える設定で利用可能なモデルは、引き続き認定の対象となります。テストでは、手動または自動設定により、制限内でモデルを推測する必要があります。たとえば、カーネルは、制限を超えたメモリーや、制限を超える CPU を自動的に無視します。手動の設定は、標準的な設定およびカーネルパラメーターのポリシーに従います。分かりやすくするために、Red Hat ナレッジベースの記事を認定リストに追加することができます。

ベンダーは、機能リクエストに関して Hardware Partner Manager およびパートナー TAM と連携して、認定作業の前に関連する Red Hat Enterprise Linux 製品の制限を引き上げることが推奨されます。すべての Red Hat Enterprise Linux 機能リクエストと同様に、必要なタイムライン、開発、およびテストの取り組みはケースバイケースで決定され、認定プロセスの範囲外と見なされます。

注記

Red Hat Enterprise Linux の現在のサポート上の制限は、「Red Hat Enterprise Linuxテクノロジーの機能と制限 」に記載されています。

3.6.6. パフォーマンスの最小

通常、Red Hat Hardware Certification は、パフォーマンステストの責任がハードウェアベンダーに配置されます。ただし、お客様に重大な影響があると見なされる主要なパフォーマンスの問題は、解決策が決定されるまで認定を遅れる可能性があります。

3.6.7. 外部業界の標準および認定

Red Hat では、ハードウェアパートナー企業が関連するテストと認定を実施して、Red Hardware Certification プログラム以外のハードウェアに適用される government、市場、および業界標準に対応します。Red Hat は、ハードウェアの Red Hat 製品との相互運用性と機能性に関連する場合を除いて、そのような標準または認定が満たされているか、または請求したことを特定の評価または検証しません。

PCI-SIG、USB-SIG 、ARM Server Ready、CE、CE、FCC などの規格は、Red Hat から独立しており、ハードウェアパートナー企業が保証どおりにアーカイブまたは取得する責任を負います。

第4章 テスト計画の作成

4.1. テスト計画の概要

ハードウェア認定エンジニアは、以下の手順に従ってテスト計画を作成します。

  1. 仕様でモデルを定義します。
  2. オプションを確認します。
  3. サポートされないオペレーティングシステムの機能と意図しないハードウェアを削除します。
  4. テストセットの最小基準を適用します。
  5. install、boot、および kdump 要件を追加します。
  6. 追加のポリシー要件を追加します。

上記の手順を実施すると、残りの項目でハードウェアのテストプランが決まります。Hardware Catalog は、Test Plan Progress でテスト計画を記録します

注記

Red Hat Hardware Certification Test Plans は、適切で完全な内部品質保証テスト、基準、およびプロセスに代わるものではありません。各ベンダー企業は、独自の内部出荷基準の責任を負い、必要な認定テスト計画項目を超えるテストを行うことが推奨されます。

4.2. モデル

Red Hat Hardware Certification プログラムはモデルを認定し、モデルの特定の設定ではありません。Red Hat は、ハードウェアパートナーがハードウェア仕様に記載しているすべての統合ハードウェアと任意のハードウェアを含むモデルを定義しています。統合ハードウェアは、モデルのすべての設定に存在する必要があるハードウェアです。オプションのハードウェアは、モデルの一部の設定に存在するハードウェアです。追加のハードウェアは、モデルの仕様にも表示される場合があります。追加ハードウェアは、モデルの設定の一部として追加で購入できるハードウェアです。追加ハードウェアはテストする必要はありませんが、追加ハードウェアとして明確に識別でき、統合ハードウェアまたは任意のハードウェアと混同しないようにする必要があります。Red Hat ナレッジベースの記事は、追加のハードウェアを明確にするために認定リストに関連付けることができます。

モデル名は一意で、特定のハードウェア仕様が必要です。

階層化されたモデル命名スキームは、Red Hat Hardware Certification プログラムで許可され、サポートされます。階層化された命名スキームは、モデルおよびサブモデルの階層的なコレクションが含まれる命名スキームです。認証の目的で段階的な命名スキームを採用する場合、仕様には、認定要求で提供された名前で合理的に表されるすべてのサブモデルが含まれると見なされます。たとえば、3 つのモデル名(3000、3000a、および 3000s)です。3000 が 3000a モデルおよび 3000s モデルを含むコレクションを反映し、3000 が送信されると、仕様には 3000a モデルおよび 3000s モデルのコンテンツが含まれます。ただし、3000 個が送信されると、仕様は 3000 個に記載されたハードウェアのみに限定されます。3000 が 3000a および 3000s とは別のモデルである場合、これは段階的なスキームではなく、類似したモデルの命名であり、3000 仕様に記載されているハードウェアのみが考慮されます。

Red Hat は、リストを明確にするためにモデル名を変更する場合があります。たとえば、NUMA およびクラスターの状況では、システム/ノードの数が仕様を変更し、Red Hat ナレッジベースエントリーではお客様の混乱を避けるのに十分なものとは見なされない場合に、モデル名の後に「up to 2 ノード」を追加するとします。

重要

分かりやすくするため、レバレッジプール認定モデル名は、メーカーおよびモデルフィールドでコンポーネントベンダーのモデル情報を利用できます。モデル名はシステムベンダーのプール内で一意で、公開されないままになります。

4.3. オプション

4.3.1. 統合ハードウェア

統合ハードウェア、CPU オプション、メモリーオプション、統合グラフィックスコントローラー、統合ディスプレイ、およびその他の非フィールドリムーバブルハードウェアはすべてテストする必要があります。これには、System-on-Chip(SoC)、System-in-Package(SiP)、およびその他の完全または部分的な統合システムソリューション設計に統合される機能が含まれます。

統合されたハードウェアの特定の部分は、OS 以外の機能のセクションまたはシステムプロセッサーの活用で概説されているポリシーに基づいて除外の対象となる機能を提供する場合、認定から除外される場合があります。

4.3.2. 任意のハードウェア

オプションハードウェアがフィールドのリムーバブルで、モデル内で固有の機能を提供しない場合を除き、すべてのオプションハードウェアをテストする必要があります。 [1] 別のオペレーティングシステムとの使用を明確に説明しています。 [2] または、モデル仕様またはモデルサポート URL の少なくとも 1 つ、および Red Hat Hardware Certification は、モデルと関連するすべての資料に対する適切なサービスレベルの影響を開示するようにマークされています。

4.3.3. 特殊なケース

ハードウェア変更ポリシー。任意のハードウェアまたは(一連の)CPU が元の認定で必要になるよりも高いマイナーリリースが必要な場合に、「ハードウェアポリシーの変更 」を参照してください。これにより、任意のハードウェアまたは CPU が必要とする上位リリースを反映するために、関連する Red Hat ナレッジベース記事を含む目的のリリースで、モデルをテストして提出することができます。



[1] 機能の数量は一意とは見なされません。たとえば、他のすべての機能が同じであるデュアルおよびクワッドイーサネットアダプターは、同じ機能を提供すると見なされます。
[2] 注記は、正の tone(例: 「with…​」)で、マイナスは使用しないでください(例: 「not for use with…​」)。

4.4. OS 以外の機能および意図しない機能

残りのハードウェアが完全に機能し続ける場合は、オペレーティングシステムによって提供されないハードウェア機能クラスをテストする必要はありません。分かりやすくするために、Red Hat ナレッジベースの記事を認定リストに追加することができます。

意図しない機能として、ハードウェアパートナーが意図しない統合または任意のハードウェアで提供される機能として定義されます。この機能は、サポートされないと呼び出されない限り、ハードウェア仕様に記載しないでください。意図しない機能は、どの OS 上のハードウェアパートナーでもサポートできません。提供された機能が一意であっても、残りのハードウェアが完全に機能し続ける場合は、意図しない機能をテストする必要はありません。意図しない機能は、可能な場合はエンドユーザーからマスクされることが推奨されます。つまり、BIOS から機能を無効または削除し、コネクターやヘッダーなどの電源を提供しないようにすることで、混乱を軽減することを推奨します。明確にするために、Red Hat ナレッジベースの記事を追加できます。意図しない機能への変更はハードウェアの変更と見なされ、ハードウェア変更のポリシーと要件が適用されます。

意図しない機能は、すべてのアーキテクチャーで利用できない項目に対応することもできます。

Infiniband ストレージコントローラーが Intel 64 および AMD64 アーキテクチャーのシステムベンダーでサポートされている場合、コントローラーはシステムの i386 認定の意図しない機能と見なされる可能性があります。意図しない機能ステータスを付与するには、i386 アーキテクチャーオペレーティングシステムではこの機能をサポートすることはできません。

4.5. 最小テストセット

Red Hat Hardware Certification プログラムは、ハードウェアのサポートされる最大構成および最小構成を含むすべての構成でのテストが推奨されています。また、これらの設定の再開は、可用性、コスト、タイミング、およびその他の制約により困難である可能性があることも認識しています。

このような理由から、ハードウェアクラス要件では、ハードウェアクラスで最小要件のポリシーを定義しています。この列は、Component(コンポーネントコンポーネントを活用し、プール およびコンポーネントパススルー認定を組み合わせたものです

最小テスト要件は、製品リリース基準として意図されておらず、認定テストに加えておよびその前に、内部 Red Hat Enterprise Linux と他の Red Hat 製品の相互運用性および修飾テストが実施されることが期待されています。

警告

テスト中に使用されるすべてのハードウェアは、モデル仕様の一部にする必要があります。モデルの一部である場合は、最小テストセットの一部として適格となる可能性のある同様のハードウェアは受け入れられません。たとえば、モデル仕様に表示される CPU のみを使用できます。同じ CPU 製品ファミリーの他のメンバーからの結果は受け入れられません。

Red Hat Enterprise Linux でサポートされる最大の制限は、https://access.redhat.com/articles/rhel-limits で定義されています。

4.6. インストール、ブート、および Kdump 要件

Red Hat Enterprise Linux のインストールでは、多くのメディア(例: Optical Media and Network)によるテストが必要になる場合があります。また、Red Hat Enterprise Linux が正常に起動するには、すべてのブートデバイスをテストする必要があります。ハードウェアクラスの要件表には、インストールおよび起動のテストが必要なハードウェアをまとめています。起動テストの要件を満たすために、完全なインストールは必要ありません。

テスト効率を向上させるためには、可能な場合は起動テストとインストールテストを組み合わせることを推奨します。たとえば、CD の Red Hat Enterprise Linux インストールメディアから起動し、完全インストールを実行すると、CD の起動とインストールテストの要件が満たされます。

kdump は、Red Hat Enterprise Linux 7 と 8 の両方で一般的な機能です。kdump は、Linux カーネルの kexec 機能を使用して、クラッシュが発生した場合にハードウェアをリセットせずにカーネルを起動し、以前のカーネルの状態を取得します。この機能はデフォルトで有効にされており、この重要なデバッグ情報を適切にキャプチャーできるようにテストする必要があります。kdump サービスが有効になっていると、kdump テストが自動的に計画されます。

この項目がモデルで利用可能な場合は、統合ストレージコントローラーおよび統合ネットワークアダプターで kdump テストが必要です。これらの要件は、64 ビット Intel システムおよび AMD システム、64 ビット IBM PowerPC アーキテクチャー上のすべての Red Hat Enterprise Linux 7 および 8 認定に適用されます。また、Red Hat Enterprise Linux では、IBM System z アーキテクチャーでの Kdump のテストが可能です。

4.7. ハードウェアクラスの要件

クラスによるハードウェア要件

ハードウェアクラスの要件は、コンピュート、管理、ネットワーク、およびストレージで分類されます。

4.7.1. Compute

Compute に含まれるハードウェア機能は以下のとおりです。

表4.1 システムプロセッサー

ハードウェアクラスカタログ機能必要なテスト必要なハードウェアinstall、Boot、kdump

システムプロセッサー、System-on-Chip(SoC)、System-in-Package(SiP)

システムプロセッサー(コアの最大数)

CPUSCALING、INTEL_SST[a]CORE、HW_PROFILER、または SW_PROFILER

論理コアの最大数[b]利用可能な CPU からの機能セット

インストール、起動

リアルタイムシステム

リアルタイム

リアルタイム[c]

リアルタイムカーネルで使用可能な CPU からの論理コアおよび機能セットの最大数。[d]

 

システムの仮想化

ゲスト上の INFO および CORE および MEMORY

ゲスト上の INFO および CORE および MEMORY

FV_CORE および FV_MEMORY

完全に仮想化されたゲスト環境での実行

ホストマシン上で実行されます。

 

高度なシステムの仮想化[e]

CPU ピニング、

FV_CPU_PINNING,

完全に仮想化されたゲスト環境での実行

 

ストレージ、PCIE パススルーストレージ、USB パススルーネットワーク、PCIE パススルーネットワーク、PCIE パススルーネットワーク、仮想マシンのライブ移行

FV_USB_STORAGE_PASSTHROUGH、FV_PCIE_STORAGE_PASSTHROUGH、FV_USB_NETWORK_PASSTHROUGH、FV_PCIE_NETWORK_PASSTHROUGH、および fv_live_migration

IOMMU が有効になっているホストマシンで実行します。

 
[a] RHEL バージョン 8.3 以降で利用可能
[b] コアクロック速度、FSB 速度、キャッシュサイズ、キャッシュ深度、製造サイズは、機能セットのレビューでは考慮されません。
[c] これらのテストは、Red Hat(Red Hat Enterprise Linux for Real-Time and Red Hat OpenStack Platform for Real-Time Applications)製品を認定するのに使用します。
[d] CPU コアごとのメモリーチェックは、RHEL7 および RHEL8 のハードウェア認定テスト、メモリー、コア、リアルタイム、およびすべての完全仮想化テストの計画条件として、RHEL 最小要件のメモリー標準に従って追加されました。CPU コアチェックごとのメモリーが合格しないと、上記のテストはテスト計画に自動的に追加されません。ただし、CLI を使用して手動で計画できます。
[e] これらの機能は、Red Hat Virtualization の認定でのみ表示されます。
  • レバレッジの注記: モデル内での同等またはそれ以下の機能セット。設計のスケーリング上のプロセッサー/コア数。機能セットおよびコアカウントによる既存の認定へのアップグレードプロセッサーのアップグレードは、現場でインストール可能な物理パッケージとして定義されており、現場でインストール可能な BIOS/ファームウェアのアップグレード 「設定」 が必要になる場合があります。

表4.2 システムメモリー

ハードウェアクラスカタログ機能必要なテスト必要なハードウェアinstall、Boot、kdump

システムメモリー

サポートされているシステムメモリーの最大数

メモリー

論理 CPU、システム制限、または OS の制限ごとに 1GB(RHEL 7)/ 1.5GB(RHEL 8)の最小値[a][b]

インストール、起動

NVDIMM - メモリーモード

NVDIMM - メモリーモード[c]

メモリー[d]

NVDIMM のサイズ

インストール、起動

NVDIMM - アプリケーションダイレクト

NVDIMM - AppDirect Mode[e]

NVDIMM[f]

NVDIMM のサイズ

インストール、起動、Kdump

[a] 「RHEL 制限に一覧表示される現在の最大メモリー」では、システムメモリーの最大メモリーが現在の最大メモリーよりも大きい場合に追加のテストが必要になります。
[b] システムメモリーの最大に NVDIMM を使用する必要がある場合は、追加のテストが必要になる場合があります。
[c] RHEL バージョン 7.6 以降で利用可能
[d] NVDIMM - メモリーモードに追加の EET テストも必要です。
[e] RHEL バージョン 7.3 以降で利用可能
[f] NVDIMM テストがセクターを利用する
  • レバレッジの注記: RAM タイプとメモリーコントローラーが一致する数値またはそれ以下の量。
  • NVDIMM ハードウェアクラスに関するレバレッジの注記: ストレージモードは、OS の制限内で、容量が小さいか、またはそれ以上の容量を持つ同じ実装でのみ使用します。

表4.3 システム要素

ハードウェアクラスカタログ機能必要なテスト必要なハードウェアインストール、起動、Kdump

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

統合ハードウェアおよび任意のハードウェアに適用可能なクラス。

統合ハードウェアおよび任意のハードウェアに該当するクラステスト。

デバイスクラスで要求される各関数に適用可能なテスト

インストール、起動

Multi-Function/Multi-Port Adapters

各関数/ポートに適用可能なクラス

各関数/ポートに適用可能なクラステスト[a][b]

デバイスクラスで要求される各関数に適用可能なテスト

インストール、起動

[a] 使用不可ポートをテストする必要があります。
[b] リムーバブルカードに複数のポートを作成するには、同一のチップがレプリケートされます。レバレッジは、マルチポートを囲む可能性があります。

表4.4 サウンド

ハードウェアクラスカタログ機能必要なテスト必要なハードウェア

サウンドカード

Stereo Audio Playback、および Stereo Audio Record

オーディオ

ステレオの記録および再生(該当する場合)

HDMI オーディオ

HDMI オーディオ再生

オーディオ

HDMI ポート

  • レバレッジの注記: 同一の統合チップセット+codec およびリムーバブルアダプター

表4.5 Thunderbolt ポート

ハードウェアクラスカタログ機能必要なテスト必要なハードウェア

Thunderbolt 3, Thunderbolt 4

Thunderbolt 3, Thunderbolt 4

Thunderbolt 3, Thunderbolt 4

同等の機能ホットプラグを備えたデバイスを備えた各ポート

表4.6 USB ポート

ハードウェアクラスカタログ機能必要なテスト必要なハードウェア

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

USB 2 ポート、USB 3(5 Gigabit)Ports、USB C(5 Gigabit)Ports、USB 3(10 Gigabit)Ports、USB C(10 Gigabit)Ports、USB C(10 Gigabit)Ports、USB C(20 Gigabit)Ports、USB 4(20 Gigabit)Ports、USB 4(40 Gigabit)Ports

USB2、USB3_5Gbps、USB3_10Gbps、USB3_20Gbps、USB4、USB4_20Gbps、または USB4_40Gbps

同等の機能ホットプラグを備えたデバイスを備えた各ポート。[a][b][c][d]

[a] すべての RHEL 7.x 認定では、USB 3.1 gen2 ポートは、RHEL 7.3 以降でテストする必要があります。
[b] gen1 デバイスでのみテストされた USB 3.1 gen2 ポートは認定できます。
[c] RHEL 7 のそれ以降のバージョンでは、10Gbps の USB 3.1 Gen2 に対応しています。
[d] USB 3.1 Gen2 ポートは、RHEL 7.5 以降および RHEL 7.4(EUS)より前の 5Gbps でのみサポートされます。

4.7.2. 管理

管理に含まれるハードウェア機能は以下のとおりです。

表4.7 コンソール

ハードウェアクラスカタログ機能必要なテスト必要なハードウェアinstall、Boot、kdump

アダプターおよび仮想コンソールの表示

グラフィックコンソール

video[a]

24 または 32 BP で、VRAM/VBIOS の制限、パネル機能、または 1024x768 の下限

インストール[b]、ブート

ラップトップパネル

グラフィックコンソール

video [LID][c]

ネイティブ解決[d][e] 利用可能なディスプレイ + グラフィックスコントローラーの組み合わせによる適応的またはネイティブの色深度[f][g]

インストール

[a] 3D アクセラレーションおよび GPGPU のサポートは現在テストされていません。
[b] インストール時にネイティブ解決は必要ありません。
[c] バックライトがある場合は、ノート PC スイッチに応答する必要があります。
[d] 補正/ストレッチングはネイティブテストとして適していません。
[e] 水平解像度 1360 は、ネイティブパネル 1366 で使用できます。
[f] 他のポリシーで除外されたオプションのグラフィックコントローラーをテストする必要はありません。各ディスプレイには、少なくとも 1 つのディスプレイ + コントローラーの組み合わせが必要です。
[g] 混乱を避けるために、ディスプレイとグラフィックスコントローラーの組み合わせを Red Hat ナレッジベースの記事の項目で明確化することができます。
  • レバレッジの注記: 共有メモリー、プロセッサ統合のない同一のリムーバブルカードまたは統合チップ。ビデオメモリー内が減少します。

表4.8 電源制御

ハードウェアクラスカタログ機能必要なテスト必要なハードウェア

電源管理、Battery

ディスクを一時停止し、Suspend to Memory, Battery Monitoring

バッテリー、Lid、および Suspend

バッテリー電源から実行可能なモデルすべてに必要。

4.7.3. ネットワーク

ネットワークに含まれるハードウェア機能は以下のとおりです。

表4.9 イーサネット

ハードウェアクラスカタログ機能必要なテスト必要なハードウェアinstall、Boot、kdump

イーサネット

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

接続速度が最大になる各インターフェース。[a]

install、Boot、kdump

[a] 1 つまたは複数のテストで完全な帯域幅と 1 つのパーティションの実行の両方を示すには、ネットワークのパーティションをサポートするデバイスが必要です。
  • レバレッジの注記: 同一の統合チップセットおよびリムーバブルアダプター

表4.10 ファイバーチャネル

ハードウェアクラスカタログ機能必要なテスト必要なハードウェアinstall、Boot、kdump

ファイバーチャネル

16 ギガビットファイバーチャンネル、32 ギガビットファイバーチャンネル、64 ギガビットファイバーチャンネル、128 ギガビットファイバーチャンネル

ネットワークまたはストレージ[a]

接続速度が最大になる各インターフェース

install、Boot、kdump

[a] 通常の接続速度は機能とみなされます。リモート接続ストレージデバイスには、追加のテストが必要になる場合があります。
  • レバレッジの注記: 同一の統合チップセット、リムーバブルアダプター、ドライバー、およびアレイ

表4.11 Fibre Channel over Ethernet(FCoE)

ハードウェアクラスカタログ機能必要なテスト必要なハードウェアinstall、Boot、kdump

FCoE アダプター

FCoE

ストレージ[a]

接続速度が最大になる各インターフェース

install、Boot、kdump

[a] 通常の接続速度は機能とみなされます。リモート接続ストレージデバイスには、追加のテストが必要になる場合があります。
  • レバレッジの注記: 同一の統合チップセット、リムーバブルアダプター、ドライバー、およびアレイ

表4.12 iSCSI

ハードウェアクラスカタログ機能必要なテスト必要なハードウェアinstall、Boot、kdump

iSCSI アダプター

iSCSI

ネットワークおよびストレージ[a]

接続速度が最大になる各インターフェース

install、Boot、kdump

[a] 通常の接続速度は機能とみなされます。リモート接続ストレージデバイスには、追加のテストが必要になる場合があります。
  • レバレッジの注記: 同一の統合チップセット、リムーバブルアダプター、ドライバー、およびアレイ

表4.13 Infiniband

ハードウェアクラスカタログ機能必要なテスト必要なハードウェアinstall、Boot、kdump

Infiniband[a]

QDR Infiniband、FDR Infiniband、EDDR Infiniband、HDR Infiniband、Socket Direct

Infiniband_QDR, Infiniband_FDR Infiniband_EDR, Infiniband_HDR, Infiniband_Socket_Direct

接続速度が最大になる各インターフェース。[b][c]

install、Boot、kdump

[a] PCIe インターフェースを複数の独立したインターフェースに分割し、単一のアダプターに接続する複数のホスト。
[b] レイテンシーを最小限に抑えてデータ配信を効率的にするために、ハードウェアに接続を実装します。
[c] 1 つまたは複数のテストで完全な帯域幅と 1 つのパーティションの実行の両方を示すには、ネットワークのパーティションをサポートするデバイスが必要です。
  • レバレッジの注記: 同一の統合チップセット、リムーバブルアダプター、ドライバー、およびアレイ

表4.14 iWARP

ハードウェアクラスカタログ機能必要なテスト必要なハードウェア

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

それぞれのインターフェースと、要求される最大接続速度に対応するテストが含まれます。footnote:[a]

[a] 1 つまたは複数のテストで完全な帯域幅と 1 つのパーティションの実行の両方を示すには、ネットワークのパーティションをサポートするデバイスが必要です。
  • レバレッジの注記: 同一の統合チップセットおよびリムーバブルアダプター

表4.15 Omnipath

ハードウェアクラスカタログ機能必要なテスト必要なハードウェア

OmniPath

OmniPath

OmniPath

各インターフェースと、要求される最大接続速度に対応するテストが含まれます。

  • レバレッジの注記: 同一の統合チップセット、プロセッサー、リムーバブルアダプター

表4.16 RoCE(RDMA over Converged Ethernet)

ハードウェアクラスカタログ機能必要なテスト必要なハードウェア

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

各インターフェースと、要求される最大接続速度に対応するテストが含まれます。[a]

[a] 1 つまたは複数のテストで完全な帯域幅と 1 つのパーティションの実行の両方を示すには、ネットワークのパーティションをサポートするデバイスが必要です。
  • レバレッジの注記: 同一の統合チップセット、プロセッサー、リムーバブルアダプター

表4.17 WiFi

ハードウェアクラスカタログ機能必要なテスト必要なハードウェアInstall,Boot, kdump

ワイヤレスネットワーク、インターフェースアダプター

ワイヤレス N、ワイヤレス AC、USB ワイヤレス N、USB ワイヤレス AC、ワイヤレス G、および USB ワイヤレス G

ワイヤレス G、ワイヤレス N、ワイヤレス AC[a]

N(最高)、G、B、A(最低)の順序で最大接続の各インターフェース。

Install,Boot

[a] Red Hat Enterprise Linux 7.0 は、802.11n の速度で 802.11ac デバイスのみをサポートします。Red Hat Enterprise Linux 7.0 に完全な 802.11ac 接続速度を提供するエラータが利用可能になるまで、802.11ac デバイスの WirelessN テストの結果は受け入れられます。
  • レバレッジの注記: 同一の統合チップセット、プロセッサー、リムーバブルアダプター

4.7.4. ストレージ

ストレージに含まれるハードウェア機能は以下のとおりです。

表4.18 HBA、HDD、および SDD

ハードウェアクラスカタログ機能必要なテスト必要なハードウェア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 SSD、SAS、SAS SSD、U.2 NVMe、U.2 SATA

M2_NVMe、M2_SATA、NVMe、SATA、SATA_SSD、SAS SSD、U2_NVMe(PCI Express)、U2_SATA

すべての容量[b] ドライブ[c]OS の制限を超える場合は、コントローラーまたはローカルアタッチアレイの最大ストレージ容量を割り当てる。

install、Boot、kdump

RAID コントローラー

ストレージ

ストレージ

各インターフェースには、各 OS コードパス(複数のドライバーが使用されている場合など)。OS の制限を超える場合のアレイの最大ストレージ容量。

install、Boot、kdump

[a] SAS コントローラーには、SAS ドライブのテストが必要です。
[b] ドライブ容量は、システムのコンテキストで追跡されません。
[c] SSD 機能では、SSD ドライブをテストする必要があります。
  • レバレッジの注記: 同一の統合チップセット、リムーバブルアダプター、ドライブ、およびアレイ
  • RAID コントローラーに関するレバレッジの注記: 同一の統合チップセット、リムーバブルアダプター、ドライブおよびアレイをタイプの基準に従って使用します。RAID レベルが減少し、メモリー容量またはバッテリーの存在が変更になりました。

表4.19 テープ

ハードウェアクラスカタログ機能必要なテスト必要なハードウェア

テープドライブとチェンジャー[a]

テープドライブ、Tape チェーチ

テープ

各ドライブ

[a] 変更者には、テストの説明と結果レポートを使用した手動テストが必要
  • レバレッジの注記: 同一のドライブとチェンジャー同じドライブの内部バージョンと外部バージョン。同じホストインターフェース、ハードウェア、ファームウェアの設計を含むモデル。機能、容量、メディアサイズ、/または合計スロット数、チェンジャー/ライブラリーのドライブ数が少なくなっています。

表4.20 メモリーカードまたはリーダー

ハードウェアクラスカタログ機能必要なテスト必要なハードウェア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

ストレージ

ストレージ容量およびフォーマットの機能セットの最大数

Install,Boot

[a] それぞれのバリアント(mini、マイクロなど)が含まれます。
  • レバレッジの注記: 同一の統合チップセット、リムーバブルアダプター同じ容量または機能カードとスティックが同一で小さくなっています。
注記

マルチリーダーは、マルチポートアダプター基準に従います。

表4.21 光学

ハードウェアクラスカタログ機能必要なテスト必要なハードウェアinstall、Boot、kdump

CD-ROM ドライブ、DVD ドライブ、または Blu-ray

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

CDROM ドライブ、DVD ドライブ、または BLURAY

BD-RW(最高)、BD-R、DVD-RW の順序の最もメディアタイプ[a]すべてのドライブの合理メディアサポートに基づいて、各ストレージコントローラーの、DVD-R、CD-R、BD、DVD、CD(lwest)、DVD-R、CD-RW、CD-R、CD-R、CD-R、CD-RW[b]そのストレージコントローラーで利用可能

インストール、起動

[a] 「+」および「-」は機能レビューと同等とみなされます。
[b] テスト中に使用される特定のドライブの数に関係なく、ハードウェアパートナーはモデルの一部であるすべてのドライブをサポートする必要があります。同等の実稼働サイクルドライブの変更は、ハードウェアパートナー企業によって内部でテストする必要があります。実稼働サイクルドライブの変更テスト結果は、Red Hat に送信する必要はありません。
  • レバレッジの注記: ストレージコントローラーのポリシーを利用するストレージコントローラーに従って、ストレージコントローラー上で同一または少ないメディアサポートを持つドライブ。

4.8. 手動テストの追加

追加の手動テストは、外部ストレージおよびマルチパス HBA で構成されます。

4.8.1. 外部ストレージおよびマルチパス HBA

ストレージコントローラー/デバイスのベース要件に加えて、ベンダーは、その内部品質保証プロセスが、以下のシナリオ下で Red Hat Enterprise Linux で完全な機能をテストすることを確認する必要があります。

  • マルチコントローラー/単一ホスト
  • マルチホスト/単一コントローラー
  • multi-controller/multi-host
  • マルチパスパスあり/なし
  • LUN マスクあり/なし(つまり特定のホスト専用の LUN)
  • 短いケーブルプル(障害検出の前にケーブルを削除および復元)
  • Red Hat Enterprise Linux でサポートされている特殊機能

上記のテストでは、テストの結果パッケージを Red Hat に送信する必要はありません。