第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 を設定できます。

手順

  1. Web コンソールで、Virtualization Overview を選択します。
  2. Settings タブを選択します。
  3. Cluster タブで、General settings Bootable volumes project を選択します。
  4. ゴールデンイメージに使用する namespace を選択します。

    1. すでに namespace を作成している場合は、Project リストから選択します。
    2. namespace を作成していない場合は、リストの一番下までスクロールして Create project をクリックします。

      1. Create project ダイアログの Name フィールドに新しい namespace の名前を入力します。
      2. Create をクリックします。

7.1.1.4. CLI を使用したゴールデンイメージのカスタム namespace の設定

HyperConverged カスタムリソース (CR) の spec.commonBootImageNamespace フィールドを設定することで、クラスター内のゴールデンイメージのカスタム namespace を設定できます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • ゴールデンイメージに使用する namespace を作成した。

手順

  1. 以下のコマンドを実行して、デフォルトのエディターで HyperConverged CR を開きます。

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
    Copy to Clipboard Toggle word wrap
  2. spec.commonBootImageNamespace フィールドの値を更新して、カスタム namespace を設定します。

    設定ファイルの例:

    apiVersion: hco.kubevirt.io/v1
    kind: HyperConverged
    metadata:
      name: kubevirt-hyperconverged
      namespace: openshift-cnv
    spec:
      commonBootImageNamespace: <custom_namespace> 
    1
    
    # ...
    Copy to Clipboard Toggle word wrap
    1
    ゴールデンイメージに使用する namespace。
  3. 変更を保存し、エディターを終了します。

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}]'
    Copy to Clipboard Toggle word wrap

7.1.2.2. 異種クラスター内の共通のゴールデンイメージソースを変更する

HyperConverged カスタムリソース (CR) の ssp.kubevirt.io/dict.architectures アノテーションでサポートされているアーキテクチャーを指定することにより、異種クラスター内の共通ゴールデンイメージのイメージソースを変更できます。

重要

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

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

前提条件

  • OpenShift CLI (oc) がインストールされている。

手順

  1. 以下のコマンドを実行して、デフォルトのエディターで HyperConverged CR を開きます。

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
    Copy to Clipboard Toggle word wrap
  2. HyperConverged CR を編集し、dataImportCronTemplates セクションの ssp.kubevirt.io/dict.architectures アノテーションに適切な値を追加します。以下に例を示します。

    #...
    spec:
      dataImportCronTemplates:
      - metadata:
          name: kubevirt-hyperconverged
          annotations:
            ssp.kubevirt.io/dict.architectures: "<architecture_list>" 
    1
    
        spec:
          schedule: "0 */12 * * *"
          template:
            spec:
              source:
                registry:
                    url: docker://my-private-registry/my-own-version-of-centos:8
          managedDataSource: centos-stream8
    #...
    Copy to Clipboard Toggle word wrap
    1
    このイメージでサポートされているアーキテクチャーのコンマ区切りリスト。たとえば、イメージが amd64 および arm64 アーキテクチャーをサポートしている場合、値は "amd64,arm64" になります。
  3. エディターを保存して終了し、HyperConverged CR を更新します。

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) がインストールされている。

手順

  1. 以下のコマンドを実行して、デフォルトのエディターで HyperConverged CR を開きます。

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
    Copy to Clipboard Toggle word wrap
  2. HyperConverged CR を編集して、カスタムゴールデンイメージを追加します。dataImportCronTemplates セクションに ssp.kubevirt.io/dict.architectures アノテーションに適切な値を追加する必要があります。以下に例を示します。

    apiVersion: hco.kubevirt.io/v1beta1
    kind: HyperConverged
    metadata:
      name: kubevirt-hyperconverged
    spec:
      dataImportCronTemplates:
      - metadata:
          name: custom-image1
          annotations:
            ssp.kubevirt.io/dict.architectures: "<architecture_list>" 
    1
    
        spec:
          schedule: "0 */12 * * *"
          template:
            spec:
              source:
                registry:
                  url: docker://myprivateregistry/custom1
          managedDataSource: custom1
          retentionPolicy: "All"
    #...
    Copy to Clipboard Toggle word wrap
    1
    このイメージでサポートされているアーキテクチャーのコンマ区切りリスト。たとえば、イメージが amd64 および arm64 アーキテクチャーをサポートしている場合、値は "amd64,arm64" になります。
    注記

    イメージは、クラスターで使用するよりも多くのアーキテクチャーをサポートしている場合があります。イメージがサポートするすべてのアーキテクチャーをリストする必要はなく、ブートソースを作成するアーキテクチャーのみをリストします。

  3. エディターを保存して終了し、HyperConverged CR を更新します。

7.1.2.4. 異種クラスター内のワークロードノードの配置を変更する

重要

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

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

異機種混合クラスターがあり、複数のアーキテクチャーのサポートを有効にしたくない場合は、HyperConverged カスタムリソース (CR) 内のワークロードノードの配置を変更して、特定のアーキテクチャーのノードのみを含めることができます。

前提条件

  • OpenShift CLI (oc) がインストールされている。

手順

  1. 以下のコマンドを実行して、デフォルトのエディターで HyperConverged CR を開きます。

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
    Copy to Clipboard Toggle word wrap
  2. HyperConverged CR を編集してワークロードのノードの配置を変更し、特定のアーキテクチャーを持つノードのみを含めます。以下に例を示します。

    apiVersion: hco.kubevirt.io/v1beta1
    kind: HyperConverged
    metadata:
      name: kubevirt-hyperconverged
    spec:
    #...
      workloads:
        nodePlacement:
          affinity:
            nodeAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                nodeSelectorTerms:
                  - matchExpressions:
                      - key: kubernetes.io/arch
                        operator: In
                        values:
                          - <node_architecture> 
    1
    Copy to Clipboard Toggle word wrap
    1
    <node_architecture> は、ターゲットアーキテクチャーに置き換えます。たとえば、配置を AMD ノードに制限するには、amd64 を使用します。
  3. エディターを保存して終了し、HyperConverged CR を更新します。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

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

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat