8.3. ブートソースの自動更新の管理
次のブートソースの自動更新を管理できます。
ブートソースにより、ユーザーは仮想マシン (VM) をよりアクセスしやすく効率的に作成できるようになります。ブートソースの自動更新が有効になっている場合、コンテナー化データインポーター (CDI) はイメージをインポート、ポーリング、更新して、新しい仮想マシン用にクローンを作成できるようにします。デフォルトでは、CDI は Red Hat ブートソースを自動的に更新します。
8.3.1. Red Hat ブートソースの更新の管理
enableCommonBootImageImport
機能ゲートを無効にすることで、システム定義のすべてのブートソースの自動更新をオプトアウトできます。この機能ゲートを無効にすると、すべての DataImportCron
オブジェクトが削除されます。この場合、オペレーティングシステムイメージを保存する以前にインポートされたブートソースオブジェクトは削除されませんが、管理者はこれらのオブジェクトを手動で削除できます。
enableCommonBootImageImport
機能ゲートが無効になると、DataSource
オブジェクトがリセットされ、元のブートソースを指さなくなります。管理者は、DataSource
オブジェクトの永続ボリューム要求 (PVC) またはボリュームスナップショットを新規作成し、それにオペレーティングシステムイメージを追加することで、ブートソースを手動で提供できます。
8.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}]'
8.3.2. カスタムブートソースの更新の管理
OpenShift Virtualization によって提供されていない カスタム ブートソースは、機能ゲートによって制御されません。HyperConverged
カスタムリソース (CR) を編集して、それらを個別に管理する必要があります。
ストレージプロファイルを設定する必要があります。そうしないと、クラスターはカスタムブートソースの自動更新を受信できません。詳細は、ストレージプロファイルの設定 を参照してください。
8.3.2.1. カスタムブートソース更新用のストレージクラスの設定
HyperConverged
カスタムリソース (CR) を編集することで、デフォルトのストレージクラスをオーバーライドできます。
ブートソースは、デフォルトのストレージクラスを使用してストレージから作成されます。クラスターにデフォルトのストレージクラスがない場合は、カスタムブートソースの自動更新を設定する前に、デフォルトのストレージクラスを定義する必要があります。
手順
以下のコマンドを実行して、デフォルトのエディターで
HyperConverged
CR を開きます。$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
storageClassName
フィールドに値を入力して、新しいストレージクラスを定義します。apiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged spec: dataImportCronTemplates: - metadata: name: rhel8-image-cron spec: template: spec: storageClassName: <new_storage_class> 1 schedule: "0 */12 * * *" 2 managedDataSource: <data_source> 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.
現在のデフォルトのストレージクラスから
storageclass.kubernetes.io/is-default-class
アノテーションを削除します。次のコマンドを実行して、現在のデフォルトのストレージクラスの名前を取得します。
$ oc get storageclass
出力例
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE csi-manila-ceph manila.csi.openstack.org Delete Immediate false 11d hostpath-csi-basic (default) kubevirt.io.hostpath-provisioner Delete WaitForFirstConsumer false 11d 1
- 1
- この例では、現在のデフォルトのストレージクラスの名前は
hostpath-csi-basic
です。
次のコマンドを実行して、現在のデフォルトのストレージクラスからアノテーションを削除します。
$ oc patch storageclass <current_default_storage_class> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}' 1
- 1
<current_default_storage_class>
をデフォルトのストレージクラスのstorageClassName
値に置き換えます。
次のコマンドを実行して、新しいストレージクラスをデフォルトとして設定します。
$ oc patch storageclass <new_storage_class> -p '{"metadata":{"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}' 1
- 1
<new_storage_class>
をHyperConverged
CR に追加したstorageClassName
値に置き換えます。
8.3.2.2. カスタムブートソースの自動更新を有効にする
OpenShift Virtualization は、デフォルトでシステム定義のブートソースを自動的に更新しますが、カスタムブートソースは自動的に更新しません。HyperConverged
カスタムリソース (CR) を編集して、自動更新を手動で有効にする必要があります。
前提条件
- クラスターにはデフォルトのストレージクラスがあります。
手順
以下のコマンドを実行して、デフォルトのエディターで
HyperConverged
CR を開きます。$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
適切なテンプレートおよびブートソースを
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
- このアノテーションは、
volumeBindingMode
がWaitForFirstConsumer
に設定されたストレージクラスに必要です。 - 2
- cron 形式で指定されるジョブのスケジュール。
- 3
- レジストリーソースからデータボリュームを作成するのに使用します。
node
docker キャッシュに基づくデフォルトのnode
pullMethod
ではなく、デフォルトのpod
pullMethod
を使用します。node
docker キャッシュはレジストリーイメージがContainer.Image
で利用可能な場合に便利ですが、CDI インポーターはこれにアクセスすることは許可されていません。 - 4
- 利用可能なブートソースとして検出するカスタムイメージの場合、イメージの
managedDataSource
の名前が、仮想マシンテンプレート YAML ファイルのspec.dataVolumeTemplates.spec.sourceRef.name
にあるテンプレートのDataSource
の名前に一致する必要があります。
- ファイルを保存します。
8.3.2.3. ボリュームスナップショットのブートソースを有効にする
オペレーティングシステムのベースイメージを保存するストレージクラスに関連付けられた StorageProfile
のパラメーターを設定して、ボリュームスナップショットのブートソースを有効にします。DataImportCron
は、元々 PVC ソースのみを維持するように設計されていましたが、特定のストレージタイプでは VolumeSnapshot
ソースの方が PVC ソースよりも拡張性に優れています。
ストレージプロファイルでは、単一のスナップショットからクローンを作成する場合により適切に拡張できることが証明されているボリュームスナップショットを使用してください。
前提条件
- オペレーティングシステムイメージを含むボリュームスナップショットにアクセスできる。
- ストレージはスナップショットをサポートしている。
手順
次のコマンドを実行して、ブートソースのプロビジョニングに使用されるストレージクラスに対応するストレージプロファイルオブジェクトを開きます。
$ oc edit storageprofile <storage_class>
-
StorageProfile
のdataImportCronSourceFormat
仕様を確認して、仮想マシンがデフォルトで PVC またはボリュームスナップショットを使用しているか確認します。 必要に応じて、
dataImportCronSourceFormat
仕様をsnapshot
に更新して、ストレージプロファイルを編集します。ストレージプロファイルの例
apiVersion: cdi.kubevirt.io/v1beta1 kind: StorageProfile metadata: # ... spec: dataImportCronSourceFormat: snapshot
検証
ブートソースのプロビジョニングに使用されるストレージクラスに対応するストレージプロファイルオブジェクトを開きます。
$ oc get storageprofile <storage_class> -oyaml
-
StorageProfile
のdataImportCronSourceFormat
仕様が 'snapshot' に設定されていること、およびDataImportCron
が指すDataSource
オブジェクトがボリュームスナップショットを参照していることを確認します。
これで、これらのブートソースを使用して仮想マシンを作成できるようになりました。
8.3.3. 単一ブートソースの自動更新を無効にする
HyperConverged
カスタムリソース (CR) を編集することで、カスタムブートソースかシステム定義ブートソースかに関係なく、個々のブートソースの自動更新を無効にできます。
手順
以下のコマンドを実行して、デフォルトのエディターで
HyperConverged
CR を開きます。$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
spec.dataImportCronTemplates
フィールドを編集して、個々のブートソースの自動更新を無効にします。- カスタムブートソース
-
spec.dataImportCronTemplates
フィールドからブートソースを削除します。カスタムブートソースの自動更新はデフォルトで無効になっています。
-
- システム定義のブートソース
ブートソースを
spec.dataImportCronTemplates
に追加します。注記システム定義のブートソースの自動更新はデフォルトで有効になっていますが、これらのブートソースは追加しない限り CR にリストされません。
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 # ...
- ファイルを保存します。
8.3.4. ブートソースのステータスの確認
HyperConverged
カスタムリソース (CR) を表示することで、ブートソースがシステム定義であるかカスタムであるかを判断できます。
手順
次のコマンドを実行して、
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 # ...
status.dataImportCronTemplates.status
フィールドを確認して、ブートソースのステータスを確認します。-
フィールドに
commonTemplate: true
が含まれている場合、それはシステム定義のブートソースです。 -
status.dataImportCronTemplates.status
フィールドの値が{}
の場合、それはカスタムブートソースです。
-
フィールドに