10.3. ブートソースの自動更新の管理


次のブートソースの自動更新を管理できます。

ブートソースにより、ユーザーは仮想マシン (VM) をよりアクセスしやすく効率的に作成できるようになります。ブートソースの自動更新が有効になっている場合、コンテナー化データインポーター (CDI) はイメージをインポート、ポーリング、更新して、新しい仮想マシン用にクローンを作成できるようにします。デフォルトでは、CDI は Red Hat ブートソースを自動的に更新します。

10.3.1. Red Hat ブートソースの更新の管理

enableCommonBootImageImport 機能ゲートを無効にすることで、システム定義のすべてのブートソースの自動更新をオプトアウトできます。この機能ゲートを無効にすると、すべての DataImportCron オブジェクトが削除されます。この場合、オペレーティングシステムイメージを保存する以前にインポートされたブートソースオブジェクトは削除されませんが、管理者はこれらのオブジェクトを手動で削除できます。

enableCommonBootImageImport 機能ゲートが無効になると、DataSource オブジェクトがリセットされ、元のブートソースを指さなくなります。管理者は、DataSource オブジェクトの永続ボリューム要求 (PVC) またはボリュームスナップショットを新規作成し、それにオペレーティングシステムイメージを追加することで、ブートソースを手動で提供できます。

10.3.1.1. すべてのシステム定義のブートソースの自動更新の管理

ブートソースの自動インポートと更新を無効にすると、リソースの使用量が削減される可能性があります。切断された環境では、ブートソースの自動更新を無効にすると、CDIDataImportCronOutdated アラートがログをいっぱいにするのを防ぎます。

すべてのシステム定義のブートソースの自動更新を無効にするには、値を false に設定して、enableCommonBootImageImport 機能ゲートをオフにします。この値を true に設定すると、機能ゲートが再度有効になり、自動更新が再びオンになります。

注記

カスタムブートソースは、この設定の影響を受けません。

手順

  • HyperConverged カスタムリソース (CR) を編集して、ブートソースの自動更新の機能ゲートを切り替えます。

    • ブートソースの自動更新を無効にするには、HyperConverged CR の spec.featureGates.enableCommonBootImageImport フィールドを false に設定します。以下に例を示します。

      $ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv \
        --type json -p '[{"op": "replace", "path": \
        "/spec/featureGates/enableCommonBootImageImport", \
        "value": false}]'
    • ブートソースの自動更新を再び有効にするには、HyperConverged CR の spec.featureGates.enableCommonBootImageImport フィールドを true に設定します。以下に例を示します。

      $ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv \
        --type json -p '[{"op": "replace", "path": \
        "/spec/featureGates/enableCommonBootImageImport", \
        "value": true}]'

10.3.2. カスタムブートソースの更新の管理

OpenShift Virtualization によって提供されていない カスタム ブートソースは、機能ゲートによって制御されません。HyperConverged カスタムリソース (CR) を編集して、それらを個別に管理する必要があります。

重要

ストレージプロファイルを設定する必要があります。そうしないと、クラスターはカスタムブートソースの自動更新を受信できません。詳細は、ストレージプロファイルの設定 を参照してください。

10.3.2.1. デフォルトおよび virt-default ストレージクラスの設定

ストレージクラスは、ワークロードに対して永続ストレージをプロビジョニングする方法を決定します。OpenShift Virtualization では、virt-default ストレージクラスがクラスターのデフォルトストレージクラスよりも優先され、仮想化ワークロード専用に使用されます。virt-default またはクラスターのデフォルトとして一度に設定できるストレージクラスは 1 つだけです。複数のストレージクラスがデフォルトとしてマークされている場合、virt-default ストレージクラスがクラスターのデフォルトをオーバーライドします。一貫した動作を確保するには、仮想化ワークロードのデフォルトとして 1 つのストレージクラスのみを設定します。

重要

ブートソースは、デフォルトのストレージクラスを使用して作成されます。デフォルトのストレージクラスが変更されると、古いブートソースは新しいデフォルトのストレージクラスを使用して自動的に更新されます。クラスターにデフォルトのストレージクラスがない場合は、定義する必要があります。

ブートソースイメージがボリュームスナップショットとして保存され、クラスターのデフォルトと virt-default ストレージクラスの両方が設定解除されている場合、ボリュームスナップショットはクリーンアップされ、新しいデータボリュームが作成されます。ただし、新しく作成されたデータボリュームは、デフォルトのストレージクラスが設定されるまでインポートを開始しません。

手順

  1. 現在の virt-default またはクラスターのデフォルトストレージクラスを false にパッチします。

    1. 次のコマンドを実行して、現在 virt-default としてマークされているすべてのストレージクラスを識別します。

      $ oc get sc -o json| jq '.items[].metadata|select(.annotations."storageclass.kubevirt.io/is-default-virt-class"=="true")|.name'
    2. 返されたストレージクラスごとに、次のコマンドを実行して virt-default アノテーションを削除します。

      $ oc patch storageclass <storage_class_name> -p '{"metadata": {"annotations": {"storageclass.kubevirt.io/is-default-virt-class": "false"}}}'
    3. 次のコマンドを実行して、現在クラスターのデフォルトとしてマークされているすべてのストレージクラスを識別します。

      $ oc get sc -o json| jq '.items[].metadata|select(.annotations."storageclass.kubernetes.io/is-default-class"=="true")|.name'
    4. 返されたストレージクラスごとに、次のコマンドを実行してクラスターのデフォルトアノテーションを削除します。

      $ oc patch storageclass <storage_class_name> -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "false"}}}'
  2. 新しいデフォルトのストレージクラスを設定します。

    1. 次のコマンドを実行して、virt-default ロールをストレージクラスに割り当てます。

      $ oc patch storageclass <storage_class_name> -p '{"metadata": {"annotations": {"storageclass.kubevirt.io/is-default-virt-class": "true"}}}'
    2. または、次のコマンドを実行して、クラスターのデフォルトロールをストレージクラスに割り当てます。

      $ oc patch storageclass <storage_class_name> -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "true"}}}'

10.3.2.2. ブートソースイメージのストレージクラスの設定

HyperConverged リソースで特定のストレージクラスを設定できます。

重要

安定した動作を確保し、不要な再インポートを回避するには、HyperConverged リソースの dataImportCronTemplates セクションで storageClassName を指定します。

手順

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

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
  2. HyperConverged リソースの spec セクションに dataImportCronTemplate を追加し、storageClassName を設定します。

    apiVersion: hco.kubevirt.io/v1beta1
    kind: HyperConverged
    metadata:
      name: kubevirt-hyperconverged
    spec:
      dataImportCronTemplates:
      - metadata:
          name: rhel9-image-cron
        spec:
          template:
            spec:
              storage:
                storageClassName: <storage_class> 1
          schedule: "0 */12 * * *" 2
          managedDataSource: <data_source> 3
    # ...
    1
    ストレージクラスを定義します。
    2
    必須: cron 形式で指定したジョブのスケジュール。
    3
    必須: 使用するデータソース。
    For the custom image to be detected as an available boot source, the value of the `spec.dataVolumeTemplates.spec.sourceRef.name` parameter in the VM template must match this value.
  3. HyperConverged Operator (HCO) と Scheduling、Scale、および Performance (SSP) リソースの調整が完了するまで待ちます。
  4. 次のコマンドを実行して、openshift-virtualization-os-images namespace から古くなった DataVolume および VolumeSnapshot オブジェクトを削除します。

    $ oc delete DataVolume,VolumeSnapshot -n openshift-virtualization-os-images --selector=cdi.kubevirt.io/dataImportCron
  5. すべての DataSource オブジェクトが "Ready - True" ステータスに達するまで待機します。データソースは、PersistentVolumeClaim (PVC) または VolumeSnapshot のいずれかを参照できます。予想されるソース形式を確認するには、次のコマンドを実行します。

    $ oc get storageprofile <storage_class_name> -o json | jq .status.dataImportCronSourceFormat

10.3.2.3. カスタムブートソースの自動更新を有効にする

OpenShift Virtualization は、デフォルトでシステム定義のブートソースを自動的に更新しますが、カスタムブートソースは自動的に更新しません。HyperConverged カスタムリソース (CR) を編集して、自動更新を手動で有効にする必要があります。

前提条件

  • クラスターにはデフォルトのストレージクラスがあります。

手順

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

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
  2. 適切なテンプレートおよびブートソースを dataImportCronTemplates セクションで追加して、HyperConverged CR を編集します。以下に例を示します。

    カスタムリソースの例

    apiVersion: hco.kubevirt.io/v1beta1
    kind: HyperConverged
    metadata:
      name: kubevirt-hyperconverged
    spec:
      dataImportCronTemplates:
      - metadata:
          name: centos-stream9-image-cron
          annotations:
            cdi.kubevirt.io/storage.bind.immediate.requested: "true" 1
        spec:
          schedule: "0 */12 * * *" 2
          template:
            spec:
              source:
                registry: 3
                  url: docker://quay.io/containerdisks/centos-stream:9
              storage:
                resources:
                  requests:
                    storage: 30Gi
          garbageCollect: Outdated
          managedDataSource: centos-stream9 4

    1
    このアノテーションは、volumeBindingModeWaitForFirstConsumer に設定されたストレージクラスに必要です。
    2
    cron 形式で指定されるジョブのスケジュール。
    3
    レジストリーソースからデータボリュームを作成するのに使用します。node docker キャッシュに基づくデフォルトの node pullMethod ではなく、デフォルトの pod pullMethod を使用します。node docker キャッシュはレジストリーイメージがContainer.Image で利用可能な場合に便利ですが、CDI インポーターはこれにアクセスすることは許可されていません。
    4
    利用可能なブートソースとして検出するカスタムイメージの場合、イメージの managedDataSource の名前が、仮想マシンテンプレート YAML ファイルの spec.dataVolumeTemplates.spec.sourceRef.name にあるテンプレートの DataSource の名前に一致する必要があります。
  3. ファイルを保存します。

10.3.2.4. ボリュームスナップショットのブートソースを有効にする

オペレーティングシステムのベースイメージを保存するストレージクラスに関連付けられた StorageProfile のパラメーターを設定して、ボリュームスナップショットのブートソースを有効にします。DataImportCron は、元々 PVC ソースのみを維持するように設計されていましたが、特定のストレージタイプでは VolumeSnapshot ソースの方が PVC ソースよりも拡張性に優れています。

注記

ストレージプロファイルでは、単一のスナップショットからクローンを作成する場合により適切に拡張できることが証明されているボリュームスナップショットを使用してください。

前提条件

  • オペレーティングシステムイメージを含むボリュームスナップショットにアクセスできる。
  • ストレージはスナップショットをサポートしている。

手順

  1. 次のコマンドを実行して、ブートソースのプロビジョニングに使用されるストレージクラスに対応するストレージプロファイルオブジェクトを開きます。

    $ oc edit storageprofile <storage_class>
  2. StorageProfiledataImportCronSourceFormat 仕様を確認して、仮想マシンがデフォルトで PVC またはボリュームスナップショットを使用しているか確認します。
  3. 必要に応じて、dataImportCronSourceFormat 仕様を snapshot に更新して、ストレージプロファイルを編集します。

    ストレージプロファイルの例

    apiVersion: cdi.kubevirt.io/v1beta1
    kind: StorageProfile
    metadata:
    # ...
    spec:
      dataImportCronSourceFormat: snapshot

検証

  1. ブートソースのプロビジョニングに使用されるストレージクラスに対応するストレージプロファイルオブジェクトを開きます。

    $ oc get storageprofile <storage_class>  -oyaml
  2. StorageProfiledataImportCronSourceFormat 仕様が 'snapshot' に設定されていること、および DataImportCron が指す DataSource オブジェクトがボリュームスナップショットを参照していることを確認します。

これで、これらのブートソースを使用して仮想マシンを作成できるようになりました。

10.3.3. 単一ブートソースの自動更新を無効にする

HyperConverged カスタムリソース (CR) を編集することで、カスタムブートソースかシステム定義ブートソースかに関係なく、個々のブートソースの自動更新を無効にできます。

手順

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

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
  2. spec.dataImportCronTemplates フィールドを編集して、個々のブートソースの自動更新を無効にします。

    カスタムブートソース
    • spec.dataImportCronTemplates フィールドからブートソースを削除します。カスタムブートソースの自動更新はデフォルトで無効になっています。
    システム定義のブートソース
    1. ブートソースを spec.dataImportCronTemplates に追加します。

      注記

      システム定義のブートソースの自動更新はデフォルトで有効になっていますが、これらのブートソースは追加しない限り CR にリストされません。

    2. dataimportcrontemplate.kubevirt.io/enable アノテーションの値を 'false' に設定します。

      以下に例を示します。

      apiVersion: hco.kubevirt.io/v1beta1
      kind: HyperConverged
      metadata:
        name: kubevirt-hyperconverged
      spec:
        dataImportCronTemplates:
        - metadata:
            annotations:
              dataimportcrontemplate.kubevirt.io/enable: 'false'
            name: rhel8-image-cron
      # ...
  3. ファイルを保存します。

10.3.4. ブートソースのステータスの確認

HyperConverged カスタムリソース (CR) を表示することで、ブートソースがシステム定義であるかカスタムであるかを判断できます。

手順

  1. 次のコマンドを実行して、HyperConverged CR の内容を表示します。

    $ oc get hyperconverged kubevirt-hyperconverged -n openshift-cnv -o yaml

    出力例

    apiVersion: hco.kubevirt.io/v1beta1
    kind: HyperConverged
    metadata:
      name: kubevirt-hyperconverged
    spec:
    # ...
    status:
    # ...
      dataImportCronTemplates:
      - metadata:
          annotations:
            cdi.kubevirt.io/storage.bind.immediate.requested: "true"
          name: centos-9-image-cron
        spec:
          garbageCollect: Outdated
          managedDataSource: centos-stream9
          schedule: 55 8/12 * * *
          template:
            metadata: {}
            spec:
              source:
                registry:
                  url: docker://quay.io/containerdisks/centos-stream:9
              storage:
                resources:
                  requests:
                    storage: 30Gi
            status: {}
        status:
          commonTemplate: true 1
    # ...
      - metadata:
          annotations:
            cdi.kubevirt.io/storage.bind.immediate.requested: "true"
          name: user-defined-dic
        spec:
          garbageCollect: Outdated
          managedDataSource: user-defined-centos-stream9
          schedule: 55 8/12 * * *
          template:
            metadata: {}
            spec:
              source:
                registry:
                  pullMethod: node
                  url: docker://quay.io/containerdisks/centos-stream:9
              storage:
                resources:
                  requests:
                    storage: 30Gi
            status: {}
        status: {} 2
    # ...

    1
    システム定義のブートソースを示します。
    2
    カスタムブートソースを示します。
  2. status.dataImportCronTemplates.status フィールドを確認して、ブートソースのステータスを確認します。

    • フィールドに commonTemplate: true が含まれている場合、それはシステム定義のブートソースです。
    • status.dataImportCronTemplates.status フィールドの値が {} の場合、それはカスタムブートソースです。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.