4.6. Bare Metal Operator を使用した設定

ベアメタルホストに OpenShift Container Platform をデプロイする場合、プロビジョニングの前後にホストに変更を加える必要がある場合があります。これには、ホストのハードウェア、ファームウェア、ファームウェアの詳細の検証が含まれます。また、ディスクのフォーマットや、変更可能なファームウェア設定の変更も含まれます。

Bare Metal Operator (BMO) を使用して、クラスター内のベアメタルホストをプロビジョニング、管理、検査できます。BMO は次の操作を完了できます。

特定のイメージを使用したクラスターへのベアメタルホストのプロビジョニング
ホストをオンまたはオフにします。
ホストのハードウェアの詳細を検査し、ベアメタルホストへ報告する
ホストのファームウェアを特定のバージョンにアップグレードまたはダウングレードする
ファームウェアを検査し、BIOS を設定します。
ホストをプロビジョニングする前または後に、ホストのディスクの内容をクリーンアップします。

BMO はこれらのタスクを完了するために次のリソースを使用します。

BareMetalHost
HostFirmwareSettings
FirmwareSchema
HostFirmwareComponents
HostUpdatePolicy

BMO は、各ベアメタルホストを BareMetalHost カスタムリソース定義のインスタンスにマッピングすることにより、クラスター内の物理ホストのインベントリーを維持します。各 BareMetalHost リソースには、ハードウェア、ソフトウェア、およびファームウェアの詳細が含まれています。BMO は、クラスター内のベアメタルホストを継続的に検査して、各 BareMetalHost リソースが対応するホストのコンポーネントを正確に詳述していることを確認します。

BMO は、HostFirmwareSettings リソース、FirmwareSchema リソース、および HostFirmwareComponents リソースを使用して、ファームウェア仕様の詳細を指定し、ベアメタルホストのファームウェアをアップグレードまたはダウングレードします。

BMO は、Ironic API サービスを使用してクラスター内のベアメタルホストと接続します。Ironic サービスは、ホスト上のベースボード管理コントローラー (BMC) を使用して、マシンと接続します。

BMO の HostUpdatePolicy を使用すると、ホストのプロビジョニング後に、ベアメタルホストのファームウェア設定、BMC 設定、または BIOS 設定へのライブ更新を有効または無効にできます。デフォルトでは、BMO はライブ更新を無効にします。

4.6.1. Bare Metal Operator のアーキテクチャー
リンクのコピー

Bare Metal Operator (BMO) は、次のリソースを使用して、クラスター内のベアメタルホストをプロビジョニング、管理、検査します。次の図は、これらのリソースのアーキテクチャーを示しています。

BareMetalHost

BareMetalHost リソースは、物理ホストとそのプロパティーを定義します。ベアメタルホストをクラスターにプロビジョニングするときは、そのホストの BareMetalHost リソースを定義する必要があります。ホストの継続的な管理のために、BareMetalHost リソースの情報を確認したり、この情報を更新したりできます。

BareMetalHost リソースには、次のようなプロビジョニング情報が含まれます。

オペレーティングシステムのブートイメージやカスタム RAM ディスクなどのデプロイメント仕様
プロビジョニング状態
ベースボード管理コントローラー (BMC) アドレス
目的の電源状態

BareMetalHost リソースには、次のようなハードウェア情報が含まれます。

CPU 数
NIC の MAC アドレス
ホストのストレージデバイスのサイズ
現在の電源状態

HostFirmwareSettings

HostFirmwareSettings リソースを使用して、ホストのファームウェア設定を取得および管理できます。ホストが Available 状態に移行すると、Ironic サービスはホストのファームウェア設定を読み取り、HostFirmwareSettings リソースを作成します。BareMetalHost リソースと HostFirmwareSettings リソースの間には 1 対 1 のマッピングがあります。

HostFirmwareSettings リソースを使用して、ホストのファームウェア仕様を調べたり、ホストのファームウェア仕様を更新したりできます。

注記

HostFirmwareSettings リソースの spec フィールドを編集するときは、ベンダーファームウェアに固有のスキーマに従う必要があります。このスキーマは、読み取り専用の FirmwareSchema リソースで定義されます。

FirmwareSchema

ファームウェア設定は、ハードウェアベンダーやホストモデルによって異なります。FirmwareSchema リソースは、各ホストモデル上の各ファームウェア設定のタイプおよび制限が含まれる読み取り専用リソースです。データは、Ironic サービスを使用して BMC から直接取得されます。FirmwareSchema リソースを使用すると、HostFirmwareSettings リソースの spec フィールドに指定できる有効な値を特定できます。

スキーマが同じであれば、FirmwareSchema リソースは多くの BareMetalHost リソースに適用できます。

HostFirmwareComponents

Metal³ は、BIOS およびベースボード管理コントローラー (BMC) ファームウェアのバージョンを記述する HostFirmwareComponents リソースを提供します。HostFirmwareComponents リソースの spec フィールドを編集することで、ホストのファームウェアを特定のバージョンにアップグレードまたはダウングレードできます。これは、特定のファームウェアバージョンに対してテストされた検証済みパターンを使用してデプロイする場合に便利です。

HostUpdatePolicy

HostUpdatePolicy リソースを使用すると、ベアメタルホストのファームウェア設定、BMC 設定、または BIOS 設定のライブ更新を有効または無効にできます。デフォルトでは、各ベアメタルホストの HostUpdatePolicy リソースにより、ホストへの更新がプロビジョニング中だけに制限されます。ホストをプロビジョニングした後、ファームウェア設定、BMC 設定、または BIOS 設定を更新する場合は、ホストの HostUpdatePolicy リソースを変更する必要があります。

4.6.2. BareMetalHost リソースについて
リンクのコピー

Metal³ で、物理ホストとそのプロパティーを定義する BareMetalHost リソースの概念が導入されました。BareMetalHost リソースには、2 つのセクションが含まれます。

BareMetalHost spec
BareMetalHost status

4.6.2.1. BareMetalHost spec
リンクのコピー

BareMetalHost リソースの spec セクションは、ホストの必要な状態を定義します。

Expand

表4.1 BareMetalHost spec
パラメーター	説明
`automatedCleaningMode`	プロビジョニングおよびプロビジョニング解除時の自動クリーニングを有効または無効にするインターフェイス。`disabled` に設定すると、自動クリーニングはスキップされます。`metadata` に設定すると、自動消去が有効になります。デフォルト設定は `metadata` です。
`bmc: address: credentialsName: disableCertificateVerification:`	`bmc` 設定には、ホスト上のベースボード管理コントローラー (BMC) の接続情報が含まれます。フィールドの詳細は以下のとおりです。 `address`: ホストの BMC コントローラーとの通信用の URL。 `credentialsName`: BMC のユーザー名およびパスワードが含まれるシークレットへの参照。 `disableCertificateVerification`: `true` に設定されている場合に証明書の検証を省略するブール値。
`bootMACAddress`	ホストのプロビジョニングに使用する NIC の MAC アドレス。
`bootMode`	ホストのブートモード。デフォルトは `UEFI` ですが、BIOS ブートの `legacy` または `UEFISecureBoot` に設定することもできます。
`consumerRef`	ホストを使用している別のリソースへの参照。別のリソースが現在ホストを使用していない場合は、空になることがあります。たとえば、`machine-api` がホストを使用している場合に、`Machine` リソースがホストを使用する場合があります。
`description`	ホストの特定に役立つ、人間が提供した文字列。
`externallyProvisioned`	ホストのプロビジョニングとプロビジョニング解除が外部で管理されるかどうかを示すブール値。設定される場合: 電源ステータスは、オンラインフィールドを使用して引き続き管理できます。ハードウェアインベントリーは監視されますが、プロビジョニング操作やプロビジョニング解除操作はホストで実行されません。
`firmware`	ベアメタルホストの BIOS 設定に関する情報が含まれます。現在、`firmware` は、iRMC、iDRAC、iLO4、および iLO5 BMC でのみサポートされます。サブフィールドは以下のとおりです。 `simultaneousMultithreadingEnabled`: 単一の物理プロセッサーコアが複数の論理プロセッサーとして表示されるのを許可します。有効な設定は `true` または `false` です。 `sriovEnabled`: SR-IOV のサポートにより、ハイパーバイザーが PCI-express デバイスの仮想インスタンスを作成できるようになり、パフォーマンスが向上する可能性があります。有効な設定は `true` または `false` です。 `virtualizationEnabled`: プラットフォームハードウェアの仮想化をサポートします。有効な設定は `true` または `false` です。
`image: url: checksum: checksumType: format:`	`image` 設定には、ホストにデプロイされるイメージの詳細が保持されます。Ironic にはイメージフィールドが必要です。ただし、`externallyProvisioned` 設定が `true` に設定されていて、外部管理に電源制御が不要な場合、フィールドは空のままでもかまいません。この設定では次のフィールドがサポートされています。 `url`: ホストにデプロイするイメージの URL。 `checksum`: 実際のチェックサム、または `image.url` のイメージのチェックサムが含まれるファイルへの URL。 `checksumType`: チェックサムアルゴリズムを指定できます。現時点で `image.checksumType` は `md5`、`sha256`、および `sha512` のみをサポートしています。デフォルトのチェックサムタイプは `md5` です。 `format`: これはイメージのディスク形式です。`raw`、`qcow2`、`vdi`、`vmdk`、`live-iso` のいずれか、未設定のままにすることができます。これを `raw` に設定すると、そのイメージの Ironic エージェントでの raw イメージのストリーミングが有効になります。これを `live-iso` に設定すると、iso イメージをディスクにデプロイせずにライブブートが可能になり、`checksum` フィールドは無視されます。
`networkData`	ネットワーク設定データおよびその namespace が含まれるシークレットへの参照。したがって、ホストが起動してネットワークをセットアップする前にホストに接続することができます。
`online`	ホストの電源を入れる (`true`) かオフにする (`false`) かを示すブール値。この値を変更すると、物理ホストの電源状態に変更が加えられます。
`raid: hardwareRAIDVolumes: softwareRAIDVolumes:`	(オプション) ベアメタルホストの RAID 設定に関する情報が含まれます。指定しない場合は、現在の設定を保持します。注記 OpenShift Container Platform 4.19 は、BMC のインストールドライブ上で以下のハードウェア RAID をサポートします。 RAID レベル 0、1、5、6、および 10 をサポートする Fujitsu iRMC ファームウェアバージョン 6.10.30.20 以降および RAID レベル 0、1、および 5 に対応した Redfish API を使用する Dell iDRAC OpenShift Container Platform 4.19 は、インストールドライブ上のソフトウェア RAID をサポートしていません。次の構成設定を参照してください。 `hardwareRAIDVolumes`: ハードウェア RAID の論理ドライブの一覧が含まれ、ハードウェア RAID で必要なボリューム設定を定義します。`rootDeviceHints` を指定しない場合、最初のボリュームがルートボリュームになります。サブフィールドは以下のとおりです。 `level`: 論理ドライブの RAID レベル。`0`、`1`、`2`、`5`、`6`、`1+0`、`5+0`、`6+0` のレベルがサポートされます。 `name`: 文字列としてのボリュームの名前。サーバー内で一意である必要があります。指定されていない場合、ボリューム名は自動生成されます。 `numberOfPhysicalDisks`: 論理ドライブに使用する物理ドライブの数 (整数)。デフォルトは、特定の RAID レベルに必要なディスクドライブの最小数です。 `physicalDisks`: 物理ディスクドライブの名前の一覧です (文字列)。これはオプションのフィールドです。指定した場合、controller フィールドも指定する必要があります。 `controller`: (オプション) ハードウェア RAID ボリュームで使用する RAID コントローラーの名前 (文字列)。 `rotational`: `true` に設定すると、回転ディスクを用いるドライブのみが選択されます。`false` に設定すると、ソリッドステートドライブと NVMe ドライブのみが選択されます。設定されていない場合は、任意のドライブの種類を選択します (デフォルト動作)。 `sizeGibibytes`: 作成する論理ドライブのサイズ (GiB 単位の整数)。指定がない場合や `0` に設定すると、論理ドライブ用に物理ドライブの最大容量が使用されます。 `softwareRAIDVolumes`: OpenShift Container Platform 4.19 は、インストールドライブ上のソフトウェア RAID をサポートしていません。この設定には、ソフトウェア RAID の論理ディスクのリストが含まれています。`rootDeviceHints` を指定しない場合、最初のボリュームがルートボリュームになります。`HardwareRAIDVolumes` を設定すると、この項目は無効になります。ソフトウェア RAID は常に削除されます。作成されるソフトウェア RAID デバイスの数は、`1` または `2` である必要があります。ソフトウェア RAID デバイスが 1 つしかない場合は、`RAID-1` にする必要があります。2 つの RAID デバイスがある場合は、1 番目のデバイスを `RAID-1` にする必要があります。また、2 番目のデバイスの RAID レベルは `0`、`1`、または `1+0` に設定できます。最初の RAID デバイスはデプロイメントデバイスになりますが、ソフトウェア RAID ボリュームにすることはできません。`RAID-1` を強制すると、デバイス障害が発生した場合にノードが起動しなくなるリスクが軽減されます。`softwareRAIDVolume` フィールドは、ソフトウェア RAID のボリュームの必要な設定を定義します。サブフィールドは以下のとおりです。 `level`: 論理ドライブの RAID レベル。`0`、`1`、`1+0` のレベルがサポートされます。 `physicalDisks`: デバイスのヒントの一覧。アイテム数は、`2` 以上である必要があります。 `sizeGibibytes`: 作成される論理ディスクドライブのサイズ (GiB 単位の整数)。指定がない場合や `0` に設定すると、論理ドライブ用に物理ドライブの最大容量が使用されます。 `hardwareRAIDVolume` を空のスライスとして設定すると、ハードウェア RAID 設定を消去できます。以下に例を示します。 `spec: raid: hardwareRAIDVolume: []` ドライバーが RAID に対応していないことを示すエラーメッセージが表示された場合は、`raid`、`hardwareRAIDVolumes` または `softwareRAIDVolumes` を nil に設定します。ホストに RAID コントローラーがあることを確認する必要がある場合があります。
`rootDeviceHints: deviceName: hctl: model: vendor: serialNumber: minSizeGigabytes: wwn: wwnWithExtension: wwnVendorExtension: rotational:`	`rootDeviceHints` パラメーターを使用すると、特定のデバイスへの RHCOS イメージのプロビジョニングが可能になります。これは、検出順にデバイスを検査し、検出された値をヒントの値と比較します。ヒントの値と一致する最初に検出されたデバイスが使用されます。設定では複数のヒントを組み合わせることができますが、デバイスが選択されるには、デバイスがすべてのヒントと一致する必要があります。フィールドの詳細は以下のとおりです。 `deviceName`: `/dev/vda` などの Linux デバイス名が含まれる文字列。ヒントは、実際の値と完全に一致する必要があります。 `hctl`: `0:0:0:0` などの SCSI バスアドレスが含まれる文字列。ヒントは、実際の値と完全に一致する必要があります。 `model`: ベンダー固有のデバイス識別子が含まれる文字列。ヒントは、実際の値のサブ文字列になります。 `vendor`: デバイスのベンダーまたは製造元の名前が含まれる文字列。ヒントは、実際の値のサブ文字列になります。 `serialNumber`: デバイスのシリアル番号が含まれる文字列。ヒントは、実際の値と完全に一致する必要があります。 `minSizeGigabytes`: デバイスの最小サイズを表す整数 (ギガバイト単位)。 `wwn`: 一意のストレージ ID が含まれる文字列。ヒントは、実際の値と完全に一致する必要があります。 `wwnWithExtension`: ベンダー拡張が追加された一意のストレージ ID が含まれる文字列。ヒントは、実際の値と完全に一致する必要があります。 `wwnVendorExtension`: 一意のベンダーストレージ ID が含まれる文字列。ヒントは、実際の値と完全に一致する必要があります。 `rotational`: デバイスが回転ディスクを用いる (true) か、そうでないか (false) を示すブール値。

4.6.2.2. BareMetalHost status
リンクのコピー

BareMetalHost status は、ホストの現在の状態を表し、テスト済みの認証情報、現在のハードウェアの詳細などの情報が含まれます。

Expand

表4.2 BareMetalHost status
パラメーター	説明
`goodCredentials`	シークレットおよびその namespace の参照で、システムが動作中と検証できるベースボード管理コントローラー (BMC) 認証情報のセットが保持されています。
`errorMessage`	プロビジョニングバックエンドが報告する最後のエラーの詳細 (ある場合)。
`errorType`	ホストがエラー状態になった原因となった問題のクラスを示します。エラータイプは以下のとおりです。 `provisioned registration error`: コントローラーがプロビジョニング済みのホストを再登録できない場合に発生します。 `registration error`: コントローラーがホストのベースボード管理コントローラーに接続できない場合に発生します。 `inspection error`: ホストからハードウェア詳細の取得を試みて失敗した場合に発生します。 `preparation error`: クリーニングに失敗した場合に発生します。 `provisioning error`: コントローラーがホストのプロビジョニングまたはプロビジョニング解除に失敗した場合に発生します。 `power management error`: コントローラーがホストの電源状態を変更できない場合に発生します。 `detach error`: コントローラーがホストをプロビジョナーからデタッチできない場合に発生します。
`hardware: cpu arch: model: clockMegahertz: flags: count:`	`hardware.cpu` フィールドは、システム内の CPU の詳細を示します。フィールドには以下が含まれます。 `arch`: CPU のアーキテクチャー。 `model`: CPU モデル (文字列)。 `clockMegahertz`: CPU の速度 (MHz 単位)。 `flags`: CPU フラグのリスト。たとえば、`'mmx','sse','sse2','vmx'` などです。 `count`: システムで利用可能な CPU の数。
`hardware: firmware:`	BIOS ファームウェア情報が含まれます。たとえば、ハードウェアベンダーおよびバージョンなどです。
`hardware: nics: - ip: name: mac: speedGbps: vlans: vlanId: pxe:`	`hardware.nics` フィールドには、ホストのネットワークインターフェイスの一覧が含まれます。フィールドには以下が含まれます。 `ip`: NIC の IP アドレス (検出エージェントの実行時に IP アドレスが割り当てられている場合)。 `name`: ネットワークデバイスを識別する文字列。例:`nic-1` `mac`: NIC の MAC アドレス。 `speedGbps`: デバイスの速度 (Gbps 単位)。 `vlans`: この NIC で利用可能な VLAN をすべて保持するリスト。 `vlanId`: タグ付けされていない VLAN ID。 `pxe`: NIC が PXE を使用して起動できるかどうか。
`hardware: ramMebibytes:`	ホストのメモリー容量 (MiB 単位)。
`hardware: storage: - name: rotational: sizeBytes: serialNumber:`	`hardware.storage` フィールドには、ホストで利用可能なストレージデバイスの一覧が含まれます。フィールドには以下が含まれます。 `name`: ストレージデバイスを識別する文字列。たとえば、`disk 1 (boot)` などです。 `rotational`: ディスクが回転ディスクを用いるかどうかを示します。`true` または `false` のいずれかを返します。 `sizeBytes`: ストレージデバイスのサイズ。 `serialNumber`: デバイスのシリアル番号。
`hardware: systemVendor: manufacturer: productName: serialNumber:`	ホストの `manufacturer`、`productName`、および `serialNumber` に関する情報が含まれます。
`lastUpdated`	ホストのステータスの最終更新時のタイムスタンプ。
`operationalStatus`	サーバーのステータス。ステータスは以下のいずれかになります。 `OK`: ホストの詳細がすべて認識され、正しく設定され、機能し、管理可能であることを示します。 `discovered`: ホストの詳細の一部が正常に動作していないか、欠落しているかのいずれかを意味します。たとえば、BMC アドレスは認識されているが、ログイン認証情報が認識されていない。 `error`: システムで回復不能なエラーが検出されたことを示します。詳細は、status セクションの `errorMessage` フィールドを参照してください。 `delayed`: 複数ホストの同時プロビジョニングを制限するために、プロビジョニングが遅延していることを示します。 `detached`: ホストが `unmanaged` として識別されていることを示します。
`poweredOn`	ホストの電源が入っているかどうかを示すブール値。
`provisioning: state: id: image: raid: firmware: rootDeviceHints:`	`provisioning` フィールドには、ホストへのイメージのデプロイに関連する値が含まれます。サブフィールドには以下が含まれます。 `state`: 進行中のプロビジョニング操作の現在の状態。状態には、以下が含まれます。 `<empty string>`: 現在、プロビジョニングは行われていません。 `unmanaged`: ホストを登録するのに十分な情報が利用できません。 `registering`: エージェントはホストの BMC の詳細を確認しています。 `match profile`: エージェントは、ホストで検出されたハードウェア詳細と既知のプロファイルを比較しています。 `available`: ホストはプロビジョニングに使用できます。この状態は、以前は `ready` として知られていました。 `preparing`: 既存の設定は削除され、新しい設定がホストに設定されます。 `provisioning`: プロビジョナーはイメージをホストのストレージに書き込んでいます。 `provisioned`: プロビジョナーはイメージをホストのストレージに書き込みました。 `externally provisioned`: Metal³ は、ホスト上のイメージを管理しません。 `deprovisioning`: プロビジョナーは、ホストのストレージからイメージを消去しています。 `inspecting`: エージェントはホストのハードウェア情報を収集しています。 `deleting`: エージェントはクラスターから削除しています。 `id`: 基礎となるプロビジョニングツールのサービスの一意識別子。 `image`: 直近ホストにプロビジョニングされたイメージ。 `raid`: 最近設定したハードウェアまたはソフトウェア RAID ボリュームの一覧。 `firmware`: ベアメタルサーバーの BIOS 設定。 `rootDeviceHints`: 直近のプロビジョニング操作に使用されたルートデバイス選択の手順。
`triedCredentials`	プロビジョニングバックエンドに送信された BMC 認証情報の最後のセットを保持するシークレットおよびその namespace への参照。

4.6.3. BareMetalHost リソースの取得
リンクのコピー

BareMetalHost リソースには、物理ホストのプロパティーが含まれます。物理ホストのプロパティーをチェックするには、その BareMetalHost リソースを取得する必要があります。

手順

BareMetalHost リソースの一覧を取得します。
```
$ oc get bmh -n openshift-machine-api -o yaml
```
注記
oc get コマンドで、bmh の長い形式として、baremetalhost を使用できます。
ホストのリストを取得します。
```
$ oc get bmh -n openshift-machine-api
```

特定のホストの BareMetalHost リソースを取得します。

$ oc get bmh <host_name> -n openshift-machine-api -o yaml

ここで、<host_name> はホストの名前です。

出力例

apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  creationTimestamp: "2022-06-16T10:48:33Z"
  finalizers:
  - baremetalhost.metal3.io
  generation: 2
  name: openshift-worker-0
  namespace: openshift-machine-api
  resourceVersion: "30099"
  uid: 1513ae9b-e092-409d-be1b-ad08edeb1271
spec:
  automatedCleaningMode: metadata
  bmc:
    address: redfish://10.46.61.19:443/redfish/v1/Systems/1
    credentialsName: openshift-worker-0-bmc-secret
    disableCertificateVerification: true
  bootMACAddress: 48:df:37:c7:f7:b0
  bootMode: UEFI
  consumerRef:
    apiVersion: machine.openshift.io/v1beta1
    kind: Machine
    name: ocp-edge-958fk-worker-0-nrfcg
    namespace: openshift-machine-api
  customDeploy:
    method: install_coreos
  online: true
  rootDeviceHints:
    deviceName: /dev/disk/by-id/scsi-<serial_number>
  userData:
    name: worker-user-data-managed
    namespace: openshift-machine-api
status:
  errorCount: 0
  errorMessage: ""
  goodCredentials:
    credentials:
      name: openshift-worker-0-bmc-secret
      namespace: openshift-machine-api
    credentialsVersion: "16120"
  hardware:
    cpu:
      arch: x86_64
      clockMegahertz: 2300
      count: 64
      flags:
      - 3dnowprefetch
      - abm
      - acpi
      - adx
      - aes
      model: Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz
    firmware:
      bios:
        date: 10/26/2020
        vendor: HPE
        version: U30
    hostname: openshift-worker-0
    nics:
    - mac: 48:df:37:c7:f7:b3
      model: 0x8086 0x1572
      name: ens1f3
    ramMebibytes: 262144
    storage:
    - hctl: "0:0:0:0"
      model: VK000960GWTTB
      name: /dev/disk/by-id/scsi-<serial_number>
      sizeBytes: 960197124096
      type: SSD
      vendor: ATA
    systemVendor:
      manufacturer: HPE
      productName: ProLiant DL380 Gen10 (868703-B21)
      serialNumber: CZ200606M3
  lastUpdated: "2022-06-16T11:41:42Z"
  operationalStatus: OK
  poweredOn: true
  provisioning:
    ID: 217baa14-cfcf-4196-b764-744e184a3413
    bootMode: UEFI
    customDeploy:
      method: install_coreos
    image:
      url: ""
    raid:
      hardwareRAIDVolumes: null
      softwareRAIDVolumes: []
    rootDeviceHints:
      deviceName: /dev/disk/by-id/scsi-<serial_number>
    state: provisioned
  triedCredentials:
    credentials:
      name: openshift-worker-0-bmc-secret
      namespace: openshift-machine-api
    credentialsVersion: "16120"

4.6.4. BareMetalHost リソースの編集
リンクのコピー

OpenShift Container Platform クラスターをベアメタルにデプロイした後、ノードの BareMetalHost リソースを編集する必要がある場合があります。たとえば、次のような例が考えられます。

Assisted Installer を使用してクラスターをデプロイし、ベースボード管理コントローラー (BMC) のホスト名または IP アドレスを追加または編集する必要がある。
ノードをプロビジョニング解除せずに、あるクラスターから別のクラスターに移動する必要がある。

前提条件

ノードが Provisioned、ExternallyProvisioned、または Available 状態であることを確認する。

手順

ノードのリストを取得します。
```
$ oc get bmh -n openshift-machine-api
```
ノードの BareMetalHost リソースを編集する前に、次のコマンドを実行してノードを Ironic からデタッチします。
```
$ oc annotate baremetalhost <node_name> -n openshift-machine-api 'baremetalhost.metal3.io/detached=true' 
```
1
1
<node_name> はノード名に置き換えてください。
次のコマンドを実行して、BareMetalHost リソースを編集します。
```
$ oc edit bmh <node_name> -n openshift-machine-api
```

次のコマンドを実行して、ノードを Ironic に再アタッチします。

$ oc annotate baremetalhost <node_name> -n openshift-machine-api 'baremetalhost.metal3.io/detached'-

4.6.5. BareMetalHost リソースを削除する際の遅延のトラブルシューティング
リンクのコピー

Bare Metal Operator (BMO) が BareMetalHost リソースを削除すると、Ironic はクリーニングと呼ばれるプロセスでベアメタルホストのプロビジョニングを解除します。クリーニングが失敗すると、Ironic はクリーニングプロセスを 3 回再試行します。これが遅延の原因となります。クリーニングプロセスが成功せず、ベアメタルホストのプロビジョニングステータスが deleting 状態のまま無期限に残る原因となります。このような場合は、次の手順に従ってクリーニングプロセスを無効にしてください。

警告

BareMetalHost リソースからファイナライザーを削除しないでください。

手順

クリーニングプロセスが失敗して再開された場合は、完了するまで待機します。これには約 5 分かかる場合があります。
プロビジョニングステータスが deleting 状態のままの場合は、BareMetalHost リソースを変更し、automatedCleaningMode フィールドを disabled に設定して、クリーニングプロセスを無効にします。

詳細は、「BareMetalHost リソースの編集」を参照してください。

4.6.6. ブータブルでない ISO をベアメタルノードにアタッチする
リンクのコピー

DataImage リソースを使用すると、ブータブルでない汎用の ISO 仮想メディアイメージを、プロビジョニングされたノードにアタッチできます。リソースを適用すると、起動後にオペレーティングシステムから ISO イメージにアクセスできるようになります。これは、オペレーティングシステムをプロビジョニングした後、ノードが初めて起動する前にノードを設定する場合に便利です。

前提条件

この機能をサポートするために、ノードが Redfish またはそれから派生したドライバーを使用している。
ノードが Provisioned または ExternallyProvisioned 状態である。
name が、BareMetalHost リソースで定義されているノードの名前と同じである。
ISO イメージへの有効な url がある。

手順

DataImage リソースを作成します。
```
apiVersion: metal3.io/v1alpha1
kind: DataImage
metadata:
  name: <node_name> 
```
1
```
spec:
  url: "http://dataimage.example.com/non-bootable.iso" 
```
2
1
BareMetalHost リソースで定義されているノードの名前を指定します。
2
ISO イメージへの URL とパスを指定します。
次のコマンドを実行して、DataImage リソースをファイルに保存します。
```
$ vim <node_name>-dataimage.yaml
```
次のコマンドを実行して、DataImage リソースを適用します。
```
$ oc apply -f <node_name>-dataimage.yaml -n <node_namespace> 
```
1
1
namespace が BareMetalHost リソースの namespace と一致するように <node_namespace> を置き換えます。たとえば、openshift-machine-api です。
ノードを再起動します。
注記
ノードを再起動するには、reboot.metal3.io アノテーションを割り当てるか、BareMetalHost リソースで online ステータスをリセットします。ベアメタルノードを強制的に再起動すると、ノードの状態がしばらくの間 NotReady に変わります。具体的には、5 分以上変わります。

次のコマンドを実行して、DataImage リソースを表示します。

$ oc get dataimage <node_name> -n openshift-machine-api -o yaml

出力例

apiVersion: v1
items:
- apiVersion: metal3.io/v1alpha1
  kind: DataImage
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"metal3.io/v1alpha1","kind":"DataImage","metadata":{"annotations":{},"name":"bmh-node-1","namespace":"openshift-machine-api"},"spec":{"url":"http://dataimage.example.com/non-bootable.iso"}}
    creationTimestamp: "2024-06-10T12:00:00Z"
    finalizers:
    - dataimage.metal3.io
    generation: 1
    name: bmh-node-1
    namespace: openshift-machine-api
    ownerReferences:
    - apiVersion: metal3.io/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: BareMetalHost
      name: bmh-node-1
      uid: 046cdf8e-0e97-485a-8866-e62d20e0f0b3
    resourceVersion: "21695581"
    uid: c5718f50-44b6-4a22-a6b7-71197e4b7b69
  spec:
    url: http://dataimage.example.com/non-bootable.iso
  status:
    attachedImage:
      url: http://dataimage.example.com/non-bootable.iso
    error:
      count: 0
      message: ""
    lastReconciled: "2024-06-10T12:05:00Z"

4.6.7. 共有 NIC の NC-SI と DisablePowerOff の設定
リンクのコピー

Network Controller Sideband Interface (NC-SI) により、ベースボード管理コントローラー (BMC) は、Redfish、IPMI、ベンダー固有のインターフェイスなどのプロトコルを使用して、管理トラフィック用のシステムネットワークインターフェイスカード (NIC) をホストと共有できるようになります。DisablePowerOff 機能は、ハードな電源オフを防ぎ、ソフトリブートを行うことで BMC との接続を維持します。

前提条件

NC-SI 対応のハードウェアと NIC。
IP アドレスとネットワーク接続が設定された BMC。
BMC への管理アクセス。
cluster-admin 特権で OpenShift クラスターにアクセスする。

手順

共有 NIC に対して NC-SI を有効にするように BMC を設定します。

次のいずれかのコマンドを実行し、Redfish または IPMI を使用して BMC の接続を確認します。

$ curl -k https://<bmc_ip>/redfish/v1/Systems/1

$ ipmitool -I lanplus -H <bmc_ip> -U <user> -P <pass> power status

openshift-machine-api namespace の BareMetalHost リソースを編集して、DisablePowerOff 機能を有効にします。

apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: example-host
  namespace: openshift-machine-api
spec:
  online: true
  bmc:
    address: <protocol>://<bmc_ip>/<bmc_address_format>
    credentialsName: bmc-secret
  disablePowerOff: true

サポートされているプロトコルと BMC アドレス形式の詳細は、「BMC アドレス指定」セクションを参照してください。

次のコマンドを実行して変更を適用します。
```
$ oc apply -f <filename>.yaml
```

検証

次のコマンドを実行して、BareMetalHost のステータスを確認します。
```
$ oc get baremetalhost example-host -n openshift-machine-api -o yaml
```
spec セクションに disablePowerOff: true があることを確認します。
ノード Pod を再起動してリブートをテストし、BMC 接続がアクティブなままであることを確認します。
BareMetalHost.spec.online=false の設定を試みます。電源オフが無効であることを示すエラーが表示されて失敗するはずです。

4.6.8. HostFirmwareSettings リソースについて
リンクのコピー

HostFirmwareSettings リソースを使用して、ホストの BIOS 設定を取得および管理できます。ホストが Available 状態に移行すると、Ironic はホストの BIOS 設定を読み取り、HostFirmwareSettings リソースを作成します。リソースには、ベースボード管理コントローラー (BMC) から返される完全な BIOS 設定が含まれます。BareMetalHost リソースの firmware フィールドは、ベンダーに依存しない 3 つのフィールドを返しますが、HostFirmwareSettings リソースは、通常ホストごとにベンダー固有のフィールドの多数の BIOS 設定で構成されます。

HostFirmwareSettings リソースには、以下の 2 つのセクションが含まれます。

HostFirmwareSettings spec
HostFirmwareSettings status

注記

ファームウェア設定の読み取りと変更は、ベンダーに依存しない Redfish プロトコル、Fujitsu iRMC、または HP iLO ベースのドライバーでのみサポートされます。

4.6.8.1. HostFirmwareSettings spec
リンクのコピー

HostFirmwareSettings リソースの spec セクションは、ホストの BIOS の必要な状態を定義し、デフォルトでは空です。Ironic は spec.settings セクションの設定を使用して、ホストが Preparing 状態の場合、ベースボード管理コントローラー (BMC) を更新します。FirmwareSchema リソースを使用して、無効な名前と値のペアをホストに送信しないようにします。詳細は、「FirmwareSchema リソースについて」を参照してください。

例

spec:
  settings:
    ProcTurboMode: Disabled

1: 前述の例では、spec.settings セクションには、ProcTurboMode BIOS 設定を Disabled に設定する名前/値のペアが含まれます。

注記

status セクションに一覧表示される整数パラメーターは文字列として表示されます。たとえば、"1" と表示されます。spec.settings セクションで整数を設定する場合、値は引用符なしの整数として設定する必要があります。たとえば、1 と設定します。

4.6.8.2. HostFirmwareSettings status
リンクのコピー

status は、ホストの BIOS の現在の状態を表します。

Expand

表4.3 HostFirmwareSettings
パラメーター	説明
`status: conditions: - lastTransitionTime: message: observedGeneration: reason: status: type:`	`conditions` フィールドには、状態変更の一覧が含まれます。サブフィールドには以下が含まれます。 `lastTransitionTime`: 状態が最後に変更した時刻。 `message`: 状態変更の説明。 `observedGeneration`: `status` の現在の生成。`metadata.generation` とこのフィールドが同じでない場合には、`status.conditions` が古い可能性があります。 `reason`: 状態変更の理由。 `status`: 状態の変更のステータス。ステータスは `True`、`False`、または `Unknown` です。 `type`: 状態変更のタイプ。タイプは `Valid` および `ChangeDetected` です。
`status: schema: name: namespace: lastUpdated:`	ファームウェア設定の `FirmwareSchema`。フィールドには以下が含まれます。 `name`: スキーマを参照する名前または一意の識別子。 `namespace`: スキーマが保存される namespace。 `lastUpdated`: リソースが最後に更新された時刻。
`status: settings:`	`settings` フィールドには、ホストの現在の BIOS 設定の名前と値のペアのリストが含まれます。

4.6.9. HostFirmwareSettings リソースの取得
リンクのコピー

HostFirmwareSettings リソースには、物理ホストのベンダー固有の BIOS プロパティーが含まれます。物理ホストの BIOS プロパティーをチェックするには、その HostFirmwareSettings リソースを取得する必要があります。

手順

次のコマンドを実行して、HostFirmwareSettings リソースの詳細なリストを取得します。
```
$ oc get hfs -n openshift-machine-api -o yaml
```
注記
oc get コマンドで、hfs の長い形式として hostfirmwaresettings を使用できます。
次のコマンドを実行して、HostFirmwareSettings リソースのリストを取得します。
```
$ oc get hfs -n openshift-machine-api
```
次のコマンドを実行して、特定のホストの HostFirmwareSettings リソースを取得します。
```
$ oc get hfs <host_name> -n openshift-machine-api -o yaml
```
ここで、<host_name> はホストの名前です。

4.6.10. プロビジョニング済みホストの HostFirmwareSettings リソースの編集
リンクのコピー

プロビジョニング済みホストの HostFirmwareSettings 仕様を変更するには、次の操作を実行します。

ホストの HostFirmwareSettings リソースを編集します。
マシンセットからホストを削除します。
マシンセットをスケールダウンします。
マシンセットをスケールアップして変更を反映させます。

重要

ホストが provisioned 状態にある場合にのみ、ホストを編集できます (読み取り専用の値を除く)。externally provisioned 状態のホストは編集できません。

手順

次のコマンドを実行して、HostFirmwareSettings リソースのリストを取得します。
```
$ oc get hfs -n openshift-machine-api
```
次のコマンドを実行して、ホストの HostFirmwareSettings リソースを編集します。
```
$ oc edit hfs <hostname> -n openshift-machine-api
```
<hostname> はプロビジョニングされたホストの名前です。HostFirmwareSettings リソースは、ターミナルのデフォルトエディターで開きます。
次のコマンドを実行して、spec.settings セクションに名前と値のペアを追加します。
例
```
spec:
  settings:
    name: value 
```
1
1
FirmwareSchema リソースを使用して、ホストで利用可能な設定を特定します。読み取り専用の値は設定できません。
変更を保存し、エディターを終了します。
次のコマンドを実行して、ホストのマシン名を取得します。
```
 $ oc get bmh <hostname> -n openshift-machine name
```
<hostname> はホストの名前です。ターミナルの CONSUMER フィールドの下にマシン名が表示されます。
次のコマンドを実行して、マシンにアノテーションを付けてマシンセットから削除します。
```
$ oc annotate machine <machine_name> machine.openshift.io/delete-machine=true -n openshift-machine-api
```
ここで、<machine_name> は削除するマシンの名前です。
次のコマンドを実行して、ノードのリストを取得し、ワーカーノードの数をカウントします。
```
$ oc get nodes
```
次のコマンドを実行してマシンセットを取得します。
```
$ oc get machinesets -n openshift-machine-api
```
次のコマンドを実行して、マシンセットをスケールします。
```
$ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n-1>
```
<machineset_name> はマシンセットの名前です。<n-1> は減少させたワーカーノードの数です。
ホストが Available 状態になったら、次のコマンドを実行してマシンセットをスケールアップし、HostFirmwareSettings リソースの変更を反映します。
```
$ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n>
```
<machineset_name> はマシンセットの名前です。<n> はワーカーノードの数です。

4.6.11. HostFirmwareSettings リソースへのライブ更新の実行
リンクのコピー

ワークロードの実行を開始した後、HostFirmareSettings リソースに対してライブ更新を実行できます。ライブ更新では、ホストのプロビジョニング解除と再プロビジョニングはトリガーされません。

重要

ホストのライブ更新はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、以下のリンクを参照してください。

テクノロジープレビュー機能のサポート範囲

前提条件

HostUpdatePolicy リソースの firmwareSettings パラメーターが onReboot に設定されている。

手順

次のコマンドを実行して、HostFirmwareSettings リソースを更新します。
```
$ oc patch hostfirmwaresettings <hostname> --type merge -p \
```
1
```
    '{"spec": {"settings": {"<name>": "<value>"}}}' 
```
2
1
<hostname> はホスト名に置き換えます。
2
<name> は設定の名前に置き換えます。<value> は設定の値に置き換えます。複数の名前と値のペアを設定できます。
注記
ハードウェアがサポートする設定と、更新できる設定および値を確認するには、FirmwareSchema リソースを取得します。読み取り専用の値を更新することはできません。また、FirmwareSchema リソースを更新することもできません。oc edit <hostname> hostfirmwaresettings -n openshift-machine-api コマンドを使用して HostFirmwareSettings リソースを更新することもできます。
次のコマンドを実行して、ノードをスケジューリング対象から外してドレインします。
```
$ oc drain <node_name> --force 
```
1
1
<node_name> はノード名に置き換えてください。
次のコマンドを実行して、ホストの電源を 5 分間オフにします。
```
$ oc patch bmh <hostname> --type merge -p '{"spec": {"online": false}}'
```
このステップにより、デーモンセットまたはコントローラーが、ホスト上で実行されている可能性のあるインフラストラクチャー Pod をオフラインとしてマークし、残りのホストが受信リクエストを処理するようになります。
5 分後、次のコマンドを実行してホストの電源をオンにします。
```
$ oc patch bmh <hostname> --type merge -p '{"spec": {"online": true}}'
```
サービス操作が開始し、Bare Metal Operator (BMO) が BareMetalHost の operationalStatus パラメーターを servicing に設定します。BMO は、リソースを更新した後、operationalStatus パラメーターを OK に更新します。エラーが発生した場合、BMO は operationalStatus パラメーターを error に更新し、操作を再試行します。
Ironic が更新を完了し、ホストが起動したら、次のコマンドを実行してノードをスケジューリング対象に戻します。
```
$ oc uncordon <node_name>
```

4.6.12. HostFirmware Settings リソースが有効であることの確認
リンクのコピー

ユーザーが spec.settings セクションを編集して HostFirmwareSetting (HFS) リソースに変更を加えると、Bare Metal Operator (BMO) は読み取り専用リソースである FimwareSchema リソースに対して変更を検証します。この設定が無効な場合、BMO は status.Condition 設定の Type の値を False に設定し、イベントを生成して HFS リソースに保存します。以下の手順を使用して、リソースが有効であることを確認します。

手順

HostFirmwareSetting リソースの一覧を取得します。
```
$ oc get hfs -n openshift-machine-api
```

特定のホストの HostFirmwareSettings リソースが有効であることを確認します。

$ oc describe hfs <host_name> -n openshift-machine-api

ここで、<host_name> はホストの名前です。

出力例

Events:
  Type    Reason            Age    From                                    Message
  ----    ------            ----   ----                                    -------
  Normal  ValidationFailed  2m49s  metal3-hostfirmwaresettings-controller  Invalid BIOS setting: Setting ProcTurboMode is invalid, unknown enumeration value - Foo

重要

応答が ValidationFailed を返す場合、リソース設定にエラーがあり、FirmwareSchema リソースに準拠するよう値を更新する必要があります。

4.6.13. FirmwareSchema リソースについて
リンクのコピー

BIOS 設定は、ハードウェアベンダーやホストモデルによって異なります。FirmwareSchema リソースは、各ホストモデル上の各 BIOS 設定のタイプおよび制限が含まれる読み取り専用リソースです。データは BMC から Ironic に直接取得されます。FirmwareSchema を使用すると、HostFirmwareSettings リソースの spec フィールドに指定できる有効な値を特定できます。FirmwareSchema リソースには、その設定および制限から派生する一意の識別子があります。同じホストモデルは同じ FirmwareSchema 識別子を使用します。HostFirmwareSettings の複数のインスタンスが同じ FirmwareSchema を使用する可能性が高いです。

Expand

表4.4 FirmwareSchema 仕様
パラメーター	説明
`<BIOS_setting_name> attribute_type: allowable_values: lower_bound: upper_bound: min_length: max_length: read_only: unique:`	`spec` は、BIOS 設定名と設定の制限で構成される単純なマップです。フィールドには以下が含まれます。 `attribute_type`: 設定のタイプ。サポートされるタイプは以下のとおりです。 `Enumeration` `Integer` `String` `Boolean` `allowable_values`: `attribute_type` が `Enumeration` の場合の、許可される値のリスト。 `lower_bound`: `attribute_type` が `Integer` の場合に許可される最小値。 `upper_bound`: `attribute_type` が `Integer` の場合に許可される最大値。 `min_length`: `attribute_type` が `String` の場合に、値が取ることのできる最も短い文字列の長さ。 `max_length`: `attribute_type` が `String` の場合に、値が取ることのできる最も長い文字列の長さ。 `read_only`: 設定は読み取り専用で、変更することはできません。 `unique`: 設定はこのホストに固有のものです。

4.6.14. FirmwareSchema リソースの取得
リンクのコピー

各ベンダーの各ホストモデルの BIOS 設定は、それぞれ異なります。HostFirmwareSettings リソースの spec セクションを編集する際に、設定する名前/値のペアはそのホストのファームウェアスキーマに準拠している必要があります。有効な名前と値のペアを設定するには、ホストの FirmwareSchema を取得して確認します。

手順

次のコマンドを実行して、FirmwareSchema リソースインスタンスのリストを取得します。
```
$ oc get firmwareschema -n openshift-machine-api
```
次のコマンドを実行して、特定の FirmwareSchema インスタンスを取得します。
```
$ oc get firmwareschema <instance_name> -n openshift-machine-api -o yaml
```
ここで、<instance_name> は、HostFirmwareSettings リソース (表 3 を参照) に記載されているスキーマインスタンスの名前です。

4.6.15. HostFirmwareComponents リソースについて
リンクのコピー

Metal³ は、BIOS およびベースボード管理コントローラー (BMC) ファームウェアのバージョンを記述する HostFirmwareComponents リソースを提供します。HostFirmwareComponents リソースには 2 つのセクションが含まれています。

HostFirmwareComponents spec
HostFirmwareComponents status

4.6.15.1. HostFirmwareComponents spec
リンクのコピー

HostFirmwareComponents リソースの spec セクションでは、ホストの BIOS および BMC バージョンの目的の状態を定義します。

Expand

表4.5 HostFirmwareComponents spec
パラメーター	説明
`updates: component: url:`	`updates` 設定には、更新するコンポーネントを含めます。フィールドの詳細は以下のとおりです。 `component`: コンポーネントの名前。有効な設定は `bios` または `bmc` です。 `url`: コンポーネントのファームウェア仕様とバージョンへの URL。

4.6.15.2. HostFirmwareComponents status
リンクのコピー

HostFirmwareComponents リソースの status セクションは、ホストの BIOS および BMC バージョンの現在のステータスを返します。

Expand

表4.6 HostFirmwareComponents status
パラメーター	説明
`components: component: initialVersion: currentVersion: lastVersionFlashed: updatedAt:`	`components` セクションには、コンポーネントのステータスが含まれています。フィールドの詳細は以下のとおりです。 `component`: ファームウェアコンポーネントの名前。`bios` または `bmc` を返します。 `initialVersion`: コンポーネントの初期ファームウェアバージョン。Ironic は、`BareMetalHost` リソースを作成するときにこの情報を取得します。ユーザーが変更することはできません。 `currentVersion`: コンポーネントの現在のファームウェアバージョン。この値は、Ironic がベアメタルホストのファームウェアを更新するまで、`initialVersion` の値と同じです。 `lastVersionFlashed`: ベアメタルホストでフラッシュされたコンポーネントの最後のファームウェアバージョン。Ironic がファームウェアを更新するまで、このフィールドは `null` を返します。 `updatedAt`: Ironic がベアメタルホストのファームウェアを更新したときのタイムスタンプ。
`updates: component: url:`	`updates` 設定には、更新されたコンポーネントが含まれています。フィールドの詳細は以下のとおりです。 `component`: コンポーネントの名前。 `url`: コンポーネントのファームウェア仕様とバージョンへの URL。

4.6.16. HostFirmwareComponents リソースの取得
リンクのコピー

HostFirmwareComponents リソースには、物理ホストの BIOS およびベースボード管理コントローラー (BMC) の特定のファームウェアバージョンが含まれています。ファームウェアのバージョンとステータスを確認するには、物理ホストの HostFirmwareComponents リソースを取得する必要があります。

手順

次のコマンドを実行して、HostFirmwareComponents リソースの詳細なリストを取得します。
```
$ oc get hostfirmwarecomponents -n openshift-machine-api -o yaml
```
次のコマンドを実行して、HostFirmwareComponents リソースのリストを取得します。
```
$ oc get hostfirmwarecomponents -n openshift-machine-api
```

次のコマンドを実行して、特定のホストの HostFirmwareComponents リソースを取得します。

$ oc get hostfirmwarecomponents <host_name> -n openshift-machine-api -o yaml

ここで、<host_name> はホストの名前です。

出力例

---
apiVersion: metal3.io/v1alpha1
kind: HostFirmwareComponents
metadata:
  creationTimestamp: 2024-04-25T20:32:06Z"
  generation: 1
  name: ostest-master-2
  namespace: openshift-machine-api
  ownerReferences:
  - apiVersion: metal3.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: BareMetalHost
    name: ostest-master-2
    uid: 16022566-7850-4dc8-9e7d-f216211d4195
  resourceVersion: "2437"
  uid: 2038d63f-afc0-4413-8ffe-2f8e098d1f6c
spec:
  updates: []
status:
  components:
  - component: bios
    currentVersion: 1.0.0
    initialVersion: 1.0.0
  - component: bmc
    currentVersion: "1.00"
    initialVersion: "1.00"
  conditions:
  - lastTransitionTime: "2024-04-25T20:32:06Z"
    message: ""
    observedGeneration: 1
    reason: OK
    status: "True"
    type: Valid
  - lastTransitionTime: "2024-04-25T20:32:06Z"
    message: ""
    observedGeneration: 1
    reason: OK
    status: "False"
    type: ChangeDetected
  lastUpdated: "2024-04-25T20:32:06Z"
  updates: []

4.6.17. プロビジョニング済みホストの HostFirmwareComponents リソースの編集
リンクのコピー

プロビジョニング済みホストの HostFirmwareComponents リソースを編集できます。

手順

次のコマンドを実行して、HostFirmwareComponents リソースの詳細なリストを取得します。
```
$ oc get hostfirmwarecomponents -n openshift-machine-api -o yaml
```
次のコマンドを実行して、HostFirmwareComponents リソースを編集します。
```
$ oc edit <hostname> hostfirmwarecomponents -n openshift-machine-api 
```
1
1
<hostname> はホストの名前です。HostFirmwareComponents リソースが、ターミナルのデフォルトのエディターで開きます。

適切な編集を行います。

出力例

---
apiVersion: metal3.io/v1alpha1
kind: HostFirmwareComponents
metadata:
  creationTimestamp: 2024-04-25T20:32:06Z"
  generation: 1
  name: ostest-master-2
  namespace: openshift-machine-api
  ownerReferences:
  - apiVersion: metal3.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: BareMetalHost
    name: ostest-master-2
    uid: 16022566-7850-4dc8-9e7d-f216211d4195
  resourceVersion: "2437"
  uid: 2038d63f-afc0-4413-8ffe-2f8e098d1f6c
spec:
  updates:
    - name: bios


      url: https://myurl.with.firmware.for.bios


    - name: bmc


      url: https://myurl.with.firmware.for.bmc


status:
  components:
  - component: bios
    currentVersion: 1.0.0
    initialVersion: 1.0.0
  - component: bmc
    currentVersion: "1.00"
    initialVersion: "1.00"
  conditions:
  - lastTransitionTime: "2024-04-25T20:32:06Z"
    message: ""
    observedGeneration: 1
    reason: OK
    status: "True"
    type: Valid
  - lastTransitionTime: "2024-04-25T20:32:06Z"
    message: ""
    observedGeneration: 1
    reason: OK
    status: "False"
    type: ChangeDetected
  lastUpdated: "2024-04-25T20:32:06Z"

1: BIOS のバージョンを設定するには、name 属性を bios に設定します。
2: BIOS のバージョンを設定するには、url 属性を BIOS のファームウェアバージョンの URL に設定します。
3: BMC のバージョンを設定するには、name 属性を bmc に設定します。
4: BMC のバージョンを設定するには、url 属性を BMC のファームウェアバージョンの URL に設定します。

変更を保存し、エディターを終了します。
次のコマンドを実行して、ホストのマシン名を取得します。
```
$ oc get bmh <host_name> -n openshift-machine name 
```
1
1
ここで、<host_name> はホストの名前です。ターミナルの CONSUMER フィールドの下にマシン名が表示されます。
次のコマンドを実行して、マシンにアノテーションを付けてマシンセットから削除します。
```
$ oc annotate machine <machine_name> machine.openshift.io/delete-machine=true -n openshift-machine-api 
```
1
1
ここで、<machine_name> は削除するマシンの名前です。
次のコマンドを実行して、ノードのリストを取得し、ワーカーノードの数をカウントします。
```
$ oc get nodes
```
次のコマンドを実行してマシンセットを取得します。
```
$ oc get machinesets -n openshift-machine-api
```
次のコマンドを実行して、マシンセットをスケールダウンします。
```
$ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n-1> 
```
1
1
<machineset_name> はマシンセットの名前です。<n-1> は減少させたワーカーノードの数です。
ホストが Available 状態になったら、次のコマンドを実行してマシンセットをスケールアップし、HostFirmwareComponents リソースの変更を反映します。
```
$ oc scale machineset <machineset_name> -n openshift-machine-api --replicas=<n> 
```
1
1
<machineset_name> はマシンセットの名前です。<n> はワーカーノードの数です。

4.6.18. HostFirmwareComponents リソースへのライブ更新の実行
リンクのコピー

すでにプロビジョニングされているホスト上の HostFirmwareComponents リソースに対してライブ更新を実行できます。ライブ更新では、ホストのプロビジョニング解除と再プロビジョニングはトリガーされません。

重要

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、以下のリンクを参照してください。

テクノロジープレビュー機能のサポート範囲

重要

実稼働ホストではライブ更新を実行しないでください。BIOS のライブ更新はテスト目的で実行できます。特に以前の世代のハードウェアでは、テスト目的で OpenShift Container Platform 4.19 上の BMC にライブ更新を実行することは推奨しません。

前提条件

HostUpdatePolicy リソースの firmwareUpdates パラメーターが onReboot に設定されている。

手順

次のコマンドを実行して、HostFirmwareComponents リソースを更新します。
```
$ oc patch hostfirmwarecomponents <hostname> --type merge -p \
```
1
```
    '{"spec": {"updates": [{"component": "<type>", \
```
2
```
                        "url": "<url>"}]}}' 
```
3
1
<hostname> はホスト名に置き換えます。
2
<type> はコンポーネントのタイプに置き換えます。bios または bmc を指定します。
3
<url> はコンポーネントの URL に置き換えます。
注記
oc edit <hostname> hostfirmwarecomponents -n openshift-machine-api コマンドを使用してリソースを更新することもできます。
次のコマンドを実行して、ノードをスケジューリング対象から外してドレインします。
```
$ oc drain <node_name> --force 
```
1
1
<node_name> はノード名に置き換えてください。
次のコマンドを実行して、ホストの電源を 5 分間オフにします。
```
$ oc patch bmh <hostname> --type merge -p '{"spec": {"online": false}}'
```
このステップにより、デーモンセットまたはコントローラーが、ノード上で実行されている可能性のあるインフラストラクチャー Pod をオフラインとしてマークし、残りのノードが受信リクエストを処理するようになります。
5 分後、次のコマンドを実行してホストの電源をオンにします。
```
$ oc patch bmh <hostname> --type merge -p '{"spec": {"online": true}}'
```
サービス操作が開始し、Bare Metal Operator (BMO) が BareMetalHost の operationalStatus パラメーターを servicing に設定します。BMO は、リソースを更新した後、operationalStatus パラメーターを OK に更新します。エラーが発生した場合、BMO は operationalStatus パラメーターを error に更新し、操作を再試行します。
次のコマンドを実行してノードをスケジューリング対象に戻します。
```
$ oc uncordon <node_name>
```

4.6.19. HostUpdatePolicy リソースについて
リンクのコピー

HostUpdatePolicy リソースを使用すると、各ベアメタルホストのファームウェア設定、BMC 設定、またはファームウェア設定へのライブ更新の適用を有効または無効にできます。デフォルトでは、すでにプロビジョニングされたベアメタルホストへのライブ更新は、Operator によって無効にされます。

HostUpdatePolicy 仕様

HostUpdatePolicy リソースの spec セクションには、次の 2 つの設定があります。

firmwareSettings: この設定は、HostFirmwareSettings リソースに対応するものです。
firmwareUpdates: この設定は、HostFirmwareComponents リソースに対応するものです。

値を onPreparing に設定すると、ホストを更新できるのがプロビジョニング中だけになります。これがデフォルト設定です。値を onReboot に設定すると、リソースを適用してベアメタルホストを再起動することで、プロビジョニング済みホストを更新できます。その後、HostFirmwareSettings または HostFirmwareComponents リソースを編集する手順に従います。

HostUpdatePolicy リソースの例

apiVersion: metal3.io/v1alpha1
kind: HostUpdatePolicy
metadata:
  name: <hostname>


  namespace: openshift-machine-api
spec:
  firmwareSettings: <setting>


  firmwareUpdates: <setting>

1: ベアメタルホストの名前。
2: 更新ポリシーの設定。ライブ更新を無効にするには、onPreparing を指定します。ライブ更新を有効にするには、onReboot を指定します。

4.6.20. HostUpdatePolicy リソースの設定
リンクのコピー

デフォルトでは、HostUpdatePolicy はライブ更新を無効にします。ライブ更新を有効にするには、次の手順に従います。

重要

HostUpdatePolicy リソースの設定はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、以下のリンクを参照してください。

テクノロジープレビュー機能のサポート範囲

手順

次のコマンドを実行して、HostUpdatePolicy リソースを作成します。
```
$ vim hup.yaml
```
任意のテキストエディターを使用できます。
HostUpdatePolicy リソースの例
```
apiVersion: metal3.io/v1alpha1
kind: HostUpdatePolicy
metadata:
  name: <hostname> 
```
1
```
  namespace: openshift-machine-api
spec:
  firmwareSettings: onReboot
  firmwareUpdates: onReboot
```
1
<hostname> はホスト名に置き換えます。
hup.yaml ファイルへの変更を保存します。
以下のコマンドを実行してポリシーを適用します。
```
$ oc apply -f hup.yaml
```

4.6. Bare Metal Operator を使用した設定

4.6.1. Bare Metal Operator のアーキテクチャー
リンクのコピー

4.6.2. BareMetalHost リソースについて
リンクのコピー

4.6.2.1. BareMetalHost spec
リンクのコピー

4.6.2.2. BareMetalHost status
リンクのコピー

4.6.3. BareMetalHost リソースの取得
リンクのコピー

4.6.4. BareMetalHost リソースの編集
リンクのコピー

4.6.5. BareMetalHost リソースを削除する際の遅延のトラブルシューティング
リンクのコピー

4.6.6. ブータブルでない ISO をベアメタルノードにアタッチする
リンクのコピー

4.6.7. 共有 NIC の NC-SI と DisablePowerOff の設定
リンクのコピー

4.6.8. HostFirmwareSettings リソースについて
リンクのコピー

4.6.8.1. HostFirmwareSettings spec
リンクのコピー

4.6.8.2. HostFirmwareSettings status
リンクのコピー

4.6.9. HostFirmwareSettings リソースの取得
リンクのコピー

4.6.10. プロビジョニング済みホストの HostFirmwareSettings リソースの編集
リンクのコピー

4.6.11. HostFirmwareSettings リソースへのライブ更新の実行
リンクのコピー

4.6.12. HostFirmware Settings リソースが有効であることの確認
リンクのコピー

4.6.13. FirmwareSchema リソースについて
リンクのコピー

4.6.14. FirmwareSchema リソースの取得
リンクのコピー

4.6.15. HostFirmwareComponents リソースについて
リンクのコピー

4.6.15.1. HostFirmwareComponents spec
リンクのコピー

4.6.15.2. HostFirmwareComponents status
リンクのコピー

4.6.16. HostFirmwareComponents リソースの取得
リンクのコピー

4.6.17. プロビジョニング済みホストの HostFirmwareComponents リソースの編集
リンクのコピー

4.6.18. HostFirmwareComponents リソースへのライブ更新の実行
リンクのコピー

4.6.19. HostUpdatePolicy リソースについて
リンクのコピー

4.6.20. HostUpdatePolicy リソースの設定
リンクのコピー

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

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

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

4.6. Bare Metal Operator を使用した設定

4.6.1. Bare Metal Operator のアーキテクチャーリンクのコピーリンクがクリップボードにコピーされました!

4.6.2. BareMetalHost リソースについてリンクのコピーリンクがクリップボードにコピーされました!

4.6.2.1. BareMetalHost specリンクのコピーリンクがクリップボードにコピーされました!

4.6.2.2. BareMetalHost statusリンクのコピーリンクがクリップボードにコピーされました!

4.6.3. BareMetalHost リソースの取得リンクのコピーリンクがクリップボードにコピーされました!

4.6.4. BareMetalHost リソースの編集リンクのコピーリンクがクリップボードにコピーされました!

4.6.5. BareMetalHost リソースを削除する際の遅延のトラブルシューティングリンクのコピーリンクがクリップボードにコピーされました!

4.6.6. ブータブルでない ISO をベアメタルノードにアタッチするリンクのコピーリンクがクリップボードにコピーされました!

4.6.7. 共有 NIC の NC-SI と DisablePowerOff の設定リンクのコピーリンクがクリップボードにコピーされました!

4.6.8. HostFirmwareSettings リソースについてリンクのコピーリンクがクリップボードにコピーされました!

4.6.8.1. HostFirmwareSettings specリンクのコピーリンクがクリップボードにコピーされました!

4.6.8.2. HostFirmwareSettings statusリンクのコピーリンクがクリップボードにコピーされました!

4.6.9. HostFirmwareSettings リソースの取得リンクのコピーリンクがクリップボードにコピーされました!

4.6.10. プロビジョニング済みホストの HostFirmwareSettings リソースの編集リンクのコピーリンクがクリップボードにコピーされました!

4.6.11. HostFirmwareSettings リソースへのライブ更新の実行リンクのコピーリンクがクリップボードにコピーされました!

4.6.12. HostFirmware Settings リソースが有効であることの確認リンクのコピーリンクがクリップボードにコピーされました!

4.6.13. FirmwareSchema リソースについてリンクのコピーリンクがクリップボードにコピーされました!

4.6.14. FirmwareSchema リソースの取得リンクのコピーリンクがクリップボードにコピーされました!

4.6.15. HostFirmwareComponents リソースについてリンクのコピーリンクがクリップボードにコピーされました!

4.6.15.1. HostFirmwareComponents specリンクのコピーリンクがクリップボードにコピーされました!

4.6.15.2. HostFirmwareComponents statusリンクのコピーリンクがクリップボードにコピーされました!

4.6.16. HostFirmwareComponents リソースの取得リンクのコピーリンクがクリップボードにコピーされました!

4.6.17. プロビジョニング済みホストの HostFirmwareComponents リソースの編集リンクのコピーリンクがクリップボードにコピーされました!

4.6.18. HostFirmwareComponents リソースへのライブ更新の実行リンクのコピーリンクがクリップボードにコピーされました!

4.6.19. HostUpdatePolicy リソースについてリンクのコピーリンクがクリップボードにコピーされました!

4.6.20. HostUpdatePolicy リソースの設定リンクのコピーリンクがクリップボードにコピーされました!

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

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

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

4.6.1. Bare Metal Operator のアーキテクチャー
リンクのコピー

4.6.2. BareMetalHost リソースについて
リンクのコピー

4.6.2.1. BareMetalHost spec
リンクのコピー

4.6.2.2. BareMetalHost status
リンクのコピー

4.6.3. BareMetalHost リソースの取得
リンクのコピー

4.6.4. BareMetalHost リソースの編集
リンクのコピー

4.6.5. BareMetalHost リソースを削除する際の遅延のトラブルシューティング
リンクのコピー

4.6.6. ブータブルでない ISO をベアメタルノードにアタッチする
リンクのコピー

4.6.7. 共有 NIC の NC-SI と DisablePowerOff の設定
リンクのコピー

4.6.8. HostFirmwareSettings リソースについて
リンクのコピー

4.6.8.1. HostFirmwareSettings spec
リンクのコピー

4.6.8.2. HostFirmwareSettings status
リンクのコピー

4.6.9. HostFirmwareSettings リソースの取得
リンクのコピー

4.6.10. プロビジョニング済みホストの HostFirmwareSettings リソースの編集
リンクのコピー

4.6.11. HostFirmwareSettings リソースへのライブ更新の実行
リンクのコピー

4.6.12. HostFirmware Settings リソースが有効であることの確認
リンクのコピー

4.6.13. FirmwareSchema リソースについて
リンクのコピー

4.6.14. FirmwareSchema リソースの取得
リンクのコピー

4.6.15. HostFirmwareComponents リソースについて
リンクのコピー

4.6.15.1. HostFirmwareComponents spec
リンクのコピー

4.6.15.2. HostFirmwareComponents status
リンクのコピー

4.6.16. HostFirmwareComponents リソースの取得
リンクのコピー

4.6.17. プロビジョニング済みホストの HostFirmwareComponents リソースの編集
リンクのコピー

4.6.18. HostFirmwareComponents リソースへのライブ更新の実行
リンクのコピー

4.6.19. HostUpdatePolicy リソースについて
リンクのコピー

4.6.20. HostUpdatePolicy リソースの設定
リンクのコピー