第7章 高度な仮想マシンの作成
7.1. Red Hat イメージからの仮想マシンの作成 リンクのコピーリンクがクリップボードにコピーされました!
7.1.1. Red Hat イメージから仮想マシンを作成する リンクのコピーリンクがクリップボードにコピーされました!
Red Hat イメージは ゴールデンイメージ です。これらは、セキュアなレジストリー内のコンテナーディスクとして公開されます。Containerized Data Importer (CDI) は、コンテナーディスクをポーリングしてクラスターにインポートし、スナップショットまたは永続ボリュームクレーム (PVC) として openshift-virtualization-os-images プロジェクトに保存します。オプションで、ゴールデンイメージにカスタム namespace を使用できます。カスタム名前空間の使用の詳細は、次を参照してください。
Red Hat イメージは自動的に更新されます。これらのイメージの自動更新を無効にして再度有効にすることができます。Red Hat ブートソースの更新の管理 を参照してください。
クラスター管理者は、OpenShift Virtualization Web コンソール で Red Hat Enterprise Linux (RHEL) 仮想マシンの自動サブスクリプションを有効にできるようになりました。
次のいずれかの方法を使用して、Red Hat が提供するオペレーティングシステムイメージから仮想マシンを作成できます。
デフォルトの openshift-* namespace に仮想マシンを作成しないでください。代わりに、openshift 接頭辞なしの新規 namespace を作成するか、既存 namespace を使用します。
7.1.1.1. ゴールデンイメージについて リンクのコピーリンクがクリップボードにコピーされました!
ゴールデンイメージは、新しい仮想マシンをデプロイメントするためのリソースとして使用できる、仮想マシンの事前設定されたスナップショットです。たとえば、ゴールデンイメージを使用すると、同じシステム環境を一貫してプロビジョニングし、システムをより迅速かつ効率的にデプロイメントできます。
7.1.1.1.1. ゴールデンイメージはどのように機能しますか? リンクのコピーリンクがクリップボードにコピーされました!
ゴールデンイメージは、リファレンスマシンまたは仮想マシンにオペレーティングシステムとソフトウェアアプリケーションをインストールして設定することによって作成されます。これには、システムのセットアップ、必要なドライバーのインストール、パッチと更新の適用、特定のオプションと設定の指定が含まれます。
ゴールデンイメージは、作成後、複数のクラスターに複製してデプロイできるテンプレートまたはイメージファイルとして保存されます。ゴールデンイメージは、メンテナーによって定期的に更新されて、必要なソフトウェア更新とパッチが組み込まれるため、イメージが最新かつセキュアな状態に保たれ、新しく作成された仮想マシンはこの更新されたイメージに基づいています。
7.1.1.1.2. Red Hat のゴールデンイメージの実装 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat は、Red Hat Enterprise Linux (RHEL) のバージョンのレジストリー内のコンテナーディスクとしてゴールデンイメージを公開します。コンテナーディスクは、コンテナーイメージレジストリーにコンテナーイメージとして保存される仮想マシンイメージです。公開されたイメージは、OpenShift Virtualization のインストール後に、接続されたクラスターで自動的に使用できるようになります。イメージがクラスター内で使用可能になると、仮想マシンの作成に使用できるようになります。
7.1.1.2. 仮想マシンブートソースについて リンクのコピーリンクがクリップボードにコピーされました!
仮想マシンは、仮想マシン定義と、データボリュームによってバックアップされる 1 つ以上のディスクで構成されます。仮想マシンテンプレートを使用すると、事前定義された仕様を使用して仮想マシンを作成できます。
すべてのテンプレートにはブートソースが必要です。ブートソースは、設定されたドライバーを含む完全に設定されたディスクイメージです。各テンプレートには、ブートソースへのポインターを含む仮想マシン定義が含まれています。各ブートソースには、事前に定義された名前および namespace があります。オペレーティングシステムによっては、ブートソースは自動的に提供されます。これが提供されない場合、管理者はカスタムブートソースを準備する必要があります。
提供されたブートソースは、オペレーティングシステムの最新バージョンに自動的に更新されます。自動更新されるブートソースの場合、永続ボリュームクレーム (PVC) とボリュームスナップショットはクラスターのデフォルトストレージクラスで作成されます。設定後に別のデフォルトストレージクラスを選択した場合は、以前のデフォルトストレージクラスで設定されたクラスター namespace 内の既存のブートソースを削除する必要があります。
7.1.1.3. Web コンソールを使用したゴールデンイメージのカスタム namespace の設定 リンクのコピーリンクがクリップボードにコピーされました!
Red Hat OpenShift Service on AWS Web コンソールを使用して、クラスター内のゴールデンイメージのカスタム namespace を設定できます。
手順
-
Web コンソールで、Virtualization
Overview を選択します。 - Settings タブを選択します。
-
Cluster タブで、General settings
Bootable volumes project を選択します。 ゴールデンイメージに使用する namespace を選択します。
- すでに namespace を作成している場合は、Project リストから選択します。
namespace を作成していない場合は、リストの一番下までスクロールして Create project をクリックします。
- Create project ダイアログの Name フィールドに新しい namespace の名前を入力します。
- Create をクリックします。
7.1.1.4. CLI を使用したゴールデンイメージのカスタム namespace の設定 リンクのコピーリンクがクリップボードにコピーされました!
HyperConverged カスタムリソース (CR) の spec.commonBootImageNamespace フィールドを設定することで、クラスター内のゴールデンイメージのカスタム namespace を設定できます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。 - ゴールデンイメージに使用する namespace を作成した。
手順
以下のコマンドを実行して、デフォルトのエディターで
HyperConvergedCR を開きます。oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvCopy to Clipboard Copied! Toggle word wrap Toggle overflow spec.commonBootImageNamespaceフィールドの値を更新して、カスタム namespace を設定します。設定ファイルの例:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- ゴールデンイメージに使用する namespace。
- 変更を保存し、エディターを終了します。
7.1.2. 異種クラスターのサポート リンクのコピーリンクがクリップボードにコピーされました!
異種クラスターのゴールデンイメージのサポートは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
異種クラスターとは、ノードが異なるアーキテクチャーを持つクラスターのことです。異種クラスターは、1 つのクラスター内に異なるタイプのハードウェアを混在させることにより、コンピュートリソースの最適な使用を促進します。これにより、汎用コンピュートプラットフォームではなく、ワークロードタスク用のハードウェアにワークロードをより適切に適合させることができます。たとえば、異種クラスターでは、GPU と汎用コンピュートリソースを組み合わせて、ワークロードを適切なハードウェアに割り当てることができます。
ゴールデンイメージのサポートが異種クラスターで無効になっていると、ノードとイメージアーキテクチャー間で不整合が生じる可能性があります。これは、ノードアーキテクチャーと一致しないイメージが仮想マシンの作成に使用された場合に発生します。これにより、仮想マシンの起動が失敗したり、仮想マシンが期待どおりに実行されなくなったりする可能性があります。異種クラスターでこの機能が有効になっていない場合、警告レベルのアラート HCOMultiArchGoldenImagesDisabled が生成されます。
異種クラスターを使用していても、複数アーキテクチャーのサポートを有効にする必要がない場合は、異種クラスター内のワークロードノードの配置を変更する で、ノードの配置を特定のアーキテクチャーに制限する手順を参照してください。
異種クラスターのゴールデンイメージサポートは、次のエリアでゴールデンイメージサポートを拡張します。
- 仮想マシン作成者が、特定のアーキテクチャーで永続的な仮想マシンをデプロイできるようにします。
- 仮想マシン作成者が、異種クラスターをサポートするカスタムのゴールデンイメージを定義できるようにします。
ブートイメージが必要なアーキテクチャーをサポートしている場合は、同じゴールデンイメージを異なるアーキテクチャーのノードで使用できます。たとえば、ARM アーキテクチャーと AMD アーキテクチャーの両方をサポートするゴールデンイメージは、両方のタイプのノードで使用できます。
異種クラスターのゴールデンイメージサポートは、デフォルトでは有効になっていません。この機能を有効にする手順は、異種クラスターサポートの有効化 を参照してください。
7.1.2.1. 異種クラスターサポートの有効化 リンクのコピーリンクがクリップボードにコピーされました!
HyperConverged カスタムリソース (CR) で enableMultiArchBootImageImport フィーチャーゲートを true に設定することで、異種クラスターのゴールデンイメージサポートを有効にできます。
異種クラスターのゴールデンイメージのサポートは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
前提条件
-
cluster-admin権限を持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc) がインストールされている。
手順
次のコマンドを実行して、
enableMultiArchBootImageImportフィーチャーゲートを有効にします。oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv \ --type json -p '[{"op":"replace","path":"/spec/featureGates/enableMultiArchBootImageImport", "value": true}]'$ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv \ --type json -p '[{"op":"replace","path":"/spec/featureGates/enableMultiArchBootImageImport", "value": true}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.1.2.2. 異種クラスター内の共通のゴールデンイメージソースを変更する リンクのコピーリンクがクリップボードにコピーされました!
HyperConverged カスタムリソース (CR) の ssp.kubevirt.io/dict.architectures アノテーションでサポートされているアーキテクチャーを指定することにより、異種クラスター内の共通ゴールデンイメージのイメージソースを変更できます。
異種クラスターのゴールデンイメージのサポートは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
前提条件
-
OpenShift CLI (
oc) がインストールされている。
手順
以下のコマンドを実行して、デフォルトのエディターで
HyperConvergedCR を開きます。oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvCopy to Clipboard Copied! Toggle word wrap Toggle overflow HyperConvergedCR を編集し、dataImportCronTemplatesセクションのssp.kubevirt.io/dict.architecturesアノテーションに適切な値を追加します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- このイメージでサポートされているアーキテクチャーのコンマ区切りリスト。たとえば、イメージが
amd64およびarm64アーキテクチャーをサポートしている場合、値は"amd64,arm64"になります。
-
エディターを保存して終了し、
HyperConvergedCR を更新します。
7.1.2.3. 異種クラスターにカスタムゴールデンイメージを追加する リンクのコピーリンクがクリップボードにコピーされました!
異種クラスターのゴールデンイメージのサポートは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
HyperConverged カスタムリソース (CR) の spec.dataImportCronTemplates.metadata.annotations スタンザに ssp.kubevirt.io/dict.architectures アノテーションを設定して、異種クラスターにカスタムゴールデンイメージを追加します。このアノテーションには、イメージでサポートされているアーキテクチャーがリストされます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。
手順
以下のコマンドを実行して、デフォルトのエディターで
HyperConvergedCR を開きます。oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvCopy to Clipboard Copied! Toggle word wrap Toggle overflow HyperConvergedCR を編集して、カスタムゴールデンイメージを追加します。dataImportCronTemplatesセクションにssp.kubevirt.io/dict.architecturesアノテーションに適切な値を追加する必要があります。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- このイメージでサポートされているアーキテクチャーのコンマ区切りリスト。たとえば、イメージが
amd64およびarm64アーキテクチャーをサポートしている場合、値は"amd64,arm64"になります。
注記イメージは、クラスターで使用するよりも多くのアーキテクチャーをサポートしている場合があります。イメージがサポートするすべてのアーキテクチャーをリストする必要はなく、ブートソースを作成するアーキテクチャーのみをリストします。
-
エディターを保存して終了し、
HyperConvergedCR を更新します。
7.1.2.4. 異種クラスター内のワークロードノードの配置を変更する リンクのコピーリンクがクリップボードにコピーされました!
異種クラスターのゴールデンイメージのサポートは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
異機種混合クラスターがあり、複数のアーキテクチャーのサポートを有効にしたくない場合は、HyperConverged カスタムリソース (CR) 内のワークロードノードの配置を変更して、特定のアーキテクチャーのノードのみを含めることができます。
前提条件
-
OpenShift CLI (
oc) がインストールされている。
手順
以下のコマンドを実行して、デフォルトのエディターで
HyperConvergedCR を開きます。oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnvCopy to Clipboard Copied! Toggle word wrap Toggle overflow HyperConvergedCR を編集してワークロードのノードの配置を変更し、特定のアーキテクチャーを持つノードのみを含めます。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<node_architecture>は、ターゲットアーキテクチャーに置き換えます。たとえば、配置を AMD ノードに制限するには、amd64を使用します。
-
エディターを保存して終了し、
HyperConvergedCR を更新します。