検索

7.18. 仮想マシンディスク

download PDF

7.18.1. ストレージ機能

以下の表を使用して、OpenShift Virtualization のローカルおよび共有の永続ストレージ機能の可用性を確認できます。

7.18.1.1. OpenShift Virtualization ストレージ機能マトリクス

表7.6 OpenShift Virtualization ストレージ機能マトリクス
 仮想マシンのライブマイグレーションホスト支援型仮想マシンディスクのクローン作成ストレージ支援型仮想マシンディスクのクローン作成仮想マシンのスナップショット

OpenShift Container Storage: RBD ブロックモードボリューム

Yes

はい

はい

はい

OpenShift Virtualization ホストパスプロビジョナー

いいえ

はい

いいえ

いいえ

他の複数ノードの書き込み可能なストレージ

はい [1]

はい

はい [2]

はい [2]

他の単一ノードの書き込み可能なストレージ

いいえ

はい

はい [2]

はい [2]

  1. PVC は ReadWriteMany アクセスモードを要求する必要があります。
  2. ストレージプロバイダーが Kubernetes および CSI スナップショット API の両方をサポートする必要があります。
注記

以下を使用する仮想マシンのライブマイグレーションを行うことはできません。

  • ReadWriteOnce (RWO) アクセスモードのストレージクラス
  • SR-IOV や GPU などのパススルー機能

それらの仮想マシンの evictionStrategy フィールドを LiveMigrate に設定しないでください。

7.18.2. 仮想マシンのローカルストレージの設定

ホストパスプロビジョナー機能を使用して、仮想マシンのローカルストレージを設定できます。

7.18.2.1. ホストパスプロビジョナーについて

ホストパスプロビジョナーは、OpenShift Virtualization 用に設計されたローカルストレージプロビジョナーです。仮想マシンのローカルストレージを設定する必要がある場合、まずホストパスプロビジョナーを有効にする必要があります。

OpenShift Virtualization Operator のインストール時に、ホストパスプロビジョナー Operator は自動的にインストールされます。これを使用するには、以下を実行する必要があります。

  • SELinux を設定します。

    • Red Hat Enterprise Linux CoreOS (RHCOS) 8 ワーカーを使用する場合は、各ノードに MachineConfig オブジェクトを作成する必要があります。
    • それ以外の場合には、SELinux ラベル container_file_t を各ノードの永続ボリューム (PV) バッキングディレクトリーに適用します。
  • HostPathProvisioner カスタムリソースを作成します。
  • ホストパスプロビジョナーの StorageClass オブジェクトを作成します。

ホストパスプロビジョナー Operator は、カスタムリソースの作成時にプロビジョナーを各ノードに DaemonSet としてデプロイします。カスタムリソースファイルでは、ホストパスプロビジョナーが作成する永続ボリュームのバッキングディレクトリーを指定します。

7.18.2.2. Red Hat Enterprise Linux CoreOS (RHCOS) 8 でのホストパスプロビジョナー用の SELinux の設定

HostPathProvisioner カスタムリソースを作成する前に、SELinux を設定する必要があります。Red Hat Enterprise Linux CoreOS (RHCOS) 8 ワーカーで SELinux を設定するには、各ノードに MachineConfig オブジェクトを作成する必要があります。

前提条件

  • ホストパスプロビジョナーが作成する永続ボリューム (PV) 用に、各ノードにバッキングディレクトリーを作成すること。

    重要

    / パーティションは RHCOS で読み取り専用であるため、バッキングディレクトリーをファイルシステムの root ディレクトリーに置かないでください。たとえば、/var/<directory_name> は使用できますが、/<directory_name> は使用できません。

手順

  1. MachineConfig ファイルを作成します。以下に例を示します。

    $ touch machineconfig.yaml
  2. ファイルを編集し、ホストパスプロビジョナーが PV を作成するディレクトリーを組み込みます。以下に例を示します。

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      name: 50-set-selinux-for-hostpath-provisioner
      labels:
        machineconfiguration.openshift.io/role: worker
    spec:
      config:
        ignition:
          version: 3.2.0
        systemd:
          units:
            - contents: |
                [Unit]
                Description=Set SELinux chcon for hostpath provisioner
                Before=kubelet.service
    
                [Service]
                ExecStart=/usr/bin/chcon -Rt container_file_t <backing_directory_path> 1
    
                [Install]
                WantedBy=multi-user.target
              enabled: true
              name: hostpath-provisioner.service
    1
    プロビジョナーが PV を作成するバッキングディレクトリーを指定します。このディレクトリーは、ファイルシステムの root ディレクトリー (/) に置かないでください。
  3. MachineConfig オブジェクトを作成します。

    $ oc create -f machineconfig.yaml -n <namespace>

7.18.2.3. ホストパスプロビジョナーを使用したローカルストレージの有効化

ホストパスプロビジョナーをデプロイし、仮想マシンがローカルストレージを使用できるようにするには、最初に HostPathProvisioner カスタムリソースを作成します。

前提条件

  • ホストパスプロビジョナーが作成する永続ボリューム (PV) 用に、各ノードにバッキングディレクトリーを作成すること。

    重要

    / パーティションは Red Hat Enterprise Linux CoreOS (RHCOS) で読み取り専用であるため、バッキングディレクトリーをファイルシステムの root ディレクトリーに置かないでください。たとえば、/var/<directory_name> は使用できますが、/<directory_name> は使用できません。

  • SELinux コンテキスト container_file_t を各ノードの PV バッキングディレクトリーに適用すること。以下に例を示します。

    $ sudo chcon -t container_file_t -R <backing_directory_path>
    注記

    Red Hat Enterprise Linux CoreOS 8 (RHCOS) ワーカーを使用する場合は、代わりに MachineConfig マニフェストを使用して SELinux を設定する必要があります。

手順

  1. HostPathProvisioner カスタムリソースファイルを作成します。以下に例を示します。

    $ touch hostpathprovisioner_cr.yaml
  2. ファイルを編集し、spec.pathConfig.path の値がホストパスプロビジョナーが PV を作成するディレクトリーであることを確認します。以下に例を示します。

    apiVersion: hostpathprovisioner.kubevirt.io/v1beta1
    kind: HostPathProvisioner
    metadata:
      name: hostpath-provisioner
    spec:
      imagePullPolicy: IfNotPresent
      pathConfig:
        path: "<backing_directory_path>" 1
        useNamingPrefix: false 2
      workload: 3
    1
    プロビジョナーが PV を作成するバッキングディレクトリーを指定します。このディレクトリーは、ファイルシステムの root ディレクトリー (/) に置かないでください。
    2
    作成された PV にバインドされる永続ボリューム要求 (PVC) の名前をディレクトリー名の接頭辞として使用する場合には、この値を true に変更します。
    3
    オプション: spec.workload フィールドを使用して、ホストパスプロビジョナーのノードの配置ルールを設定できます。
    注記

    バッキングディレクトリーを作成していない場合、プロビジョナーはこの作成を試行します。container_file_t SELinux コンテキストを適用していない場合、これにより Permission denied エラーが生じる可能性があります。

  3. openshift-cnv namespace にカスタムリソースを作成します。

    $ oc create -f hostpathprovisioner_cr.yaml -n openshift-cnv

7.18.2.4. ストレージクラスの作成

ストレージクラスの作成時に、ストレージクラスに属する永続ボリューム (PV) の動的プロビジョニングに影響するパラメーターを設定します。StorageClass オブジェクトの作成後には、このオブジェクトのパラメーターを更新できません。

重要

OpenShift Container Platform Container Storage と共に OpenShift Virtualization を使用する場合、仮想マシンディスクの作成時に RBD ブロックモードの永続ボリューム要求 (PVC) を指定します。仮想マシンディスクの場合、RBD ブロックモードのボリュームは効率的で、Ceph FS または RBD ファイルシステムモードの PVC よりも優れたパフォーマンスを提供します。

RBD ブロックモードの PVC を指定するには、'ocs-storagecluster-ceph-rbd' ストレージクラスおよび VolumeMode: Block を使用します。

手順

  1. ストレージクラスを定義する YAML ファイルを作成します。以下に例を示します。

    $ touch storageclass.yaml
  2. ファイルを編集します。以下に例を示します。

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: hostpath-provisioner 1
    provisioner: kubevirt.io/hostpath-provisioner
    reclaimPolicy: Delete 2
    volumeBindingMode: WaitForFirstConsumer 3
    1
    この値を変更することで、オプションでストレージクラスの名前を変更できます。
    2
    reclaimPolicy には、Delete および Retain の 2 つの値があります。値を指定しない場合、ストレージクラスはデフォルトで Delete に設定されます。
    3
    volumeBindingMode 値は、動的プロビジョニングおよびボリュームバインディングが実行されるタイミングを決定します。WaitForFirstConsumer を指定して、永続ボリューム要求 (PVC) を使用する Pod が作成されるまで PV のバインディングおよびプロビジョニングを遅延させます。これにより、PV が Pod のスケジュール要件を満たすようになります。
    注記

    仮想マシンは、ローカル PV に基づくデータボリュームを使用します。ローカル PV は特定のノードにバインドされます。ディスクイメージは仮想マシンで使用するために準備されますが、ローカルストレージ PV がすでに固定されたノードに仮想マシンをスケジュールすることができない可能性があります。

    この問題を解決するには、Kubernetes Pod スケジューラーを使用して PVC を正しいノード上の PV にバインドします。volumeBindingModeWaitForFirstConsumer に設定された StorageClass を使用すると、PV のバインディングおよびプロビジョニングは、Pod が PVC を使用して作成されるまで遅延します。

  3. StorageClass オブジェクトを作成します。

    $ oc create -f storageclass.yaml

7.18.3. ファイルシステムオーバーヘッドの PVC 領域の確保

デフォルトで、Containerized Data Importer (CDI) は、Filesystem ボリュームモードを使用する永続ボリューム要求 (PVC) のファイルシステムのオーバーヘッドデータ用に領域を確保します。CDI がこの目的で予約する割合をクローバルに設定し、また特定のストレージクラス用に設定できます。

7.18.3.1. ファイルシステムのオーバーヘッドが仮想マシンディスクの領域に影響を与える仕組み

仮想マシンディスクを Filesystem ボリュームモードを使用する永続ボリューム要求 (PVC) に追加する場合、PVC で十分な容量があることを確認する必要があります。

  • 仮想マシンディスク。
  • Containerized Data Importer (CDI) が、メタデータなどのファイルシステムのオーバーヘッドに予約する領域。

デフォルトで、CDI はオーバーヘッド用に PVC 領域の 5.5% を予約し、その分、仮想マシンディスクに利用可能な領域を縮小します。

特定のユースケースに異なる値を使用する方が良い場合は、CDI オブジェクトを編集してオーバーヘッドの値を設定できます。値はグローバルに変更でき、特定のストレージクラスの値を指定できます。

7.18.3.2. デフォルトのファイルシステムオーバーヘッド値の上書き

CDI オブジェクトの spec.config.filesystemOverhead 属性を編集し、Containerized Data Importer (CDI) がファイルシステムのオーバーヘッド用に予約する永続ボリューム要求 (PVC) 領域の量を変更します。

前提条件

  • OpenShift CLI (oc) をインストールしている。

手順

  1. 以下のコマンドを実行して、編集するために CDI オブジェクトを開きます。

    $ oc edit cdi
  2. spec.config.filesystemOverhead フィールドを編集して、選択した値でデータを設定します。

    ...
    spec:
      config:
        filesystemOverhead:
          global: "<new_global_value>" 1
          storageClass:
            <storage_class_name>: "<new_value_for_this_storage_class>" 2
    1
    CDI がクラスター全体で使用するファイルシステムのオーバーヘッドの割合 (パーセント)。たとえば、global: "0.07" は、ファイルシステムのオーバーヘッド用に PVC の 7% を確保します。
    2
    指定されたストレージクラスのファイルシステムのオーバーヘッドの割合 (パーセンテージ)。たとえば、mystorageclass: "0.04" は、mystorageclass ストレージクラスの PVC のデフォルトオーバーヘッド値を 4% に変更します。
  3. エディターを保存し、終了して CDI オブジェクトを更新します。

検証

  • 以下のコマンドを実行して CDI ステータスを表示し、変更を確認します。

    $ oc get cdi -o yaml

7.18.4. コンピュートリソースクォータを持つ namespace で機能する CDI の設定

Containerized Data Importer (CDI) を使用して、CPU およびメモリーリソースの制限が適用される namespace に仮想マシンディスクをインポートし、アップロードし、そのクローンを作成できるようになりました。

7.18.4.1. namespace の CPU およびメモリークォータについて

ResourceQuota オブジェクトで定義される リソースクォータ は、その namespace 内のリソースが消費できるコンピュートリソースの全体量を制限する制限を namespace に課します。

CDI オブジェクトは Containerized Data Importer (CDI) のユーザー設定を定義します。CDI オブジェクトの CPU およびメモリーの要求および制限の値はデフォルト値の 0 に設定されます。これにより、コンピュートリソース要件を指定しない CDI によって作成される Pod にデフォルト値が付与され、クォータで制限される namespace での実行が許可されます。

7.18.4.2. CPU およびメモリーのデフォルトを上書きするための CDI オブジェクトの編集

CDI オブジェクトの spec.config.podResourceRequirements フィールドを編集して、ユースケースに応じて CPU およびメモリーの要求および制限のデフォルト設定を変更します。

前提条件

  • OpenShift CLI (oc) をインストールしている。

手順

  1. 以下のコマンドを実行して CDI オブジェクトを編集します。

    $ oc edit cdi
  2. CDI オブジェクトの spec: podResourceRequirements フィールドを編集して、デフォルトの CPU およびメモリーの要求および制限を変更します。

    apiVersion: cdi.kubevirt.io/v1beta1
    kind: CDI
    ...
    spec:
      config:
        podResourceRequirements:
          limits:
            cpu: "4"
            memory: "1Gi"
          requests:
            cpu: "1"
            memory: "250Mi"
    ...
  3. エディターを保存し、終了して CDI オブジェクトを更新します。

検証

  • CDI オブジェクトの status フィールドを表示して変更を確認します。

    $ oc get cdi -o yaml

7.18.4.3. 関連情報

7.18.5. データボリュームの事前割り当ての使用

Containerized Data Importer は、データボリュームの作成時に書き込みパフォーマンスを向上させるために、ディスク領域を事前に割り当てることができます。

クラスターまたは特定のデータボリュームに対して、事前割り当てをグローバルに有効にできます。

7.18.5.1. 事前割り当てについて

Containerized Data Importer (CDI) は、データボリュームに QEMU 事前割り当てモードを使用し、書き込みパフォーマンスを向上できます。操作のインポートおよびアップロードには、事前割り当てモードを使用できます。また、空のデータボリュームを作成する際にも使用できます。

事前割り当てが有効化されている場合、CDI は基礎となるファイルシステムおよびデバイスタイプに応じて、より適切な事前割り当て方法を使用します。

fallocate
ファイルシステムがこれをサポートする場合、CDI は posix_fallocate 関数を使って領域を事前に割り当てるためにオペレーティングシステムの fallocate 呼び出しを使用します。これは、ブロックを割り当て、それらを未初期化としてマークします。
full
fallocate モードを使用できない場合は、基礎となるストレージにデータを書き込むことで、full モードがイメージの領域を割り当てます。ストレージの場所によっては、空の割り当て領域がすべてゼロになる場合があります。

7.18.5.2. 事前割り当てグローバルに有効にする

prellocation フィールドを CDI オブジェクトに追加して、Containerized Data Importer (CDI) のクラスター全体の事前割り当てモードを有効にすることができます。

前提条件

  • OpenShift CLI (oc) をインストールすること。

手順

  1. oc クライアントを使用して CDI オブジェクトを編集します。

    $ oc edit cdi
  2. spec.config.preallocation フィールドを true の値で設定します。

    apiVersion: cdi.kubevirt.io/v1beta1
    kind: CDI
    metadata:
    ...
    spec:
      config:
        preallocation: true 1
    1
    preallocation フィールドは、デフォルトで false に設定されるブール値です。
  3. エディターを保存して終了し、CDI オブジェクトを更新して事前割り当てモードを有効にします。

7.18.5.3. データボリュームの事前割り当ての有効化

事前割り当てがクラスターに対してグローバルに有効化されていない場合、データボリュームマニフェストに spec.preallocation フィールドを追加して、特定のデータボリュームに対してこれを有効化することができます。Web コンソールで、または OpenShift クライアント (oc) を使用して、事前割り当てモードを有効化することができます。

事前割り当てモードは、すべての CDI ソースタイプでサポートされます。

手順

  • データボリュームマニフェストの spec.preallocation フィールドを指定します。

    apiVersion: cdi.kubevirt.io/v1beta1
    kind: DataVolume
    metadata:
      name: preallocated-datavolume
    spec:
      source: 1
        ...
      pvc:
        ...
      preallocation: true 2
    1
    すべての CDI ソースタイプは事前割り当てをサポートしますが、クローンの操作では事前割り当ては無視されます。
    2
    preallocation フィールドは、デフォルトで false に設定されるブール値です。

7.18.6. Web コンソールの使用によるローカルディスクイメージのアップロード

Web コンソールを使用して、ローカルに保存されたディスクイメージファイルをアップロードできます。

7.18.6.1. 前提条件

7.18.6.2. CDI がサポートする操作マトリックス

このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。

コンテンツタイプHTTPHTTPSHTTP Basic 認証レジストリーアップロード

kubevirt (QCOW2)

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2**
✓ GZ*
✓ XZ*

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2*
□ GZ
□ XZ

✓ QCOW2*
✓ GZ*
✓ XZ*

KubeVirt (RAW)

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW*
□ GZ
□ XZ

✓ RAW*
✓ GZ*
✓ XZ*

✓ サポートされる操作

□ サポートされない操作

* スクラッチ領域が必要

**カスタム認証局が必要な場合にスクラッチ領域が必要

7.18.6.3. Web コンソールを使用したイメージファイルのアップロード

Web コンソールを使用して、イメージファイルを新規の永続ボリューム要求 (PVC) にアップロードします。この PVC を後で使用して、イメージを新規の仮想マシンに割り当てることができます。

前提条件

  • 以下のいずれかが必要である。

    • ISO または IMG 形式のいずれかの raw 仮想マシンイメージファイル。
    • QCOW2 形式の仮想マシンのイメージファイル。
  • 最善の結果を得るには、アップロードする前にイメージファイルを以下のガイドラインに従って圧縮すること。

    • xz または gzip を使用して raw イメージファイルを圧縮します。

      注記

      圧縮された raw イメージファイルを使用すると、最も効率的にアップロードできます。

    • クライアントについて推奨される方法を使用して、QCOW2 イメージファイルを圧縮します。

      • Linux クライアントを使用する場合は、virt-sparsify ツールを使用して、QCOW2 ファイルをスパース化 (sparsify) します。
      • Windows クライアントを使用する場合は、xz または gzip を使用して QCOW2 ファイルを圧縮します。

手順

  1. Web コンソールのサイドメニューから、Storage Persistent Volume Claims をクリックします。
  2. Create Persistent Volume Claim ドロップダウンリストをクリックし、これを拡張します。
  3. With Data Upload Form をクリックし、Upload Data to Persistent Volume Claim ページを開きます。
  4. Browse をクリックし、ファイルマネージャーを開き、アップロードするイメージを選択するか、ファイルを Drag a file here or browse to upload フィールドにドラッグします。
  5. オプション: 特定のオペレーティングシステムのデフォルトイメージとしてこのイメージを設定します。

    1. Attach this data to a virtual machine operating system チェックボックスを選択します。
    2. 一覧からオペレーティングシステムを選択します。
  6. Persistent Volume Claim Name フィールドには、一意の名前が自動的に入力され、これを編集することはできません。PVC に割り当てられた名前をメモし、必要に応じてこれを後で特定できるようにします。
  7. Storage Class 一覧からストレージクラスを選択します。
  8. Size フィールドに PVC のサイズ値を入力します。ドロップダウンリストから、対応する測定単位を選択します。

    警告

    PVC サイズは圧縮解除された仮想ディスクのサイズよりも大きくなければなりません。

  9. 選択したストレージクラスに一致する Access Mode を選択します。
  10. Upload をクリックします。

7.18.6.4. 関連情報

7.18.7. virtctl ツールの使用によるローカルディスクイメージのアップロード

virtctl コマンドラインユーティリティーを使用して、ローカルに保存されたディスクイメージを新規または既存のデータボリュームにアップロードできます。

7.18.7.1. 前提条件

7.18.7.2. データボリュームについて

DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは OpenShift Virtualization に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。

7.18.7.3. アップロードデータボリュームの作成

ローカルディスクイメージのアップロードに使用する upload データソースでデータボリュームを手動で作成できます。

手順

  1. spec: source: upload{} を指定するデータボリューム設定を作成します。

    apiVersion: cdi.kubevirt.io/v1beta1
    kind: DataVolume
    metadata:
      name: <upload-datavolume> 1
    spec:
      source:
          upload: {}
      pvc:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: <2Gi> 2
    1
    データボリュームの名前。
    2
    データボリュームのサイズ。この値がアップロードするディスクのサイズ以上であることを確認します。
  2. 以下のコマンドを実行してデータボリュームを作成します。

    $ oc create -f <upload-datavolume>.yaml

7.18.7.4. ローカルディスクイメージのデータボリュームへのアップロード

virtctl CLI ユーティリティーを使用して、ローカルディスクイメージをクライアントマシンからクラスター内のデータボリューム (DV) にアップロードできます。この手順の実行時に、すでにクラスターに存在する DV を使用するか、または新規の DV を作成することができます。

注記

ローカルディスクイメージのアップロード後に、これを仮想マシンに追加できます。

前提条件

  • 以下のいずれかが必要である。

    • ISO または IMG 形式のいずれかの raw 仮想マシンイメージファイル。
    • QCOW2 形式の仮想マシンのイメージファイル。
  • 最善の結果を得るには、アップロードする前にイメージファイルを以下のガイドラインに従って圧縮すること。

    • xz または gzip を使用して raw イメージファイルを圧縮します。

      注記

      圧縮された raw イメージファイルを使用すると、最も効率的にアップロードできます。

    • クライアントについて推奨される方法を使用して、QCOW2 イメージファイルを圧縮します。

      • Linux クライアントを使用する場合は、virt-sparsify ツールを使用して、QCOW2 ファイルをスパース化 (sparsify) します。
      • Windows クライアントを使用する場合は、xz または gzip を使用して QCOW2 ファイルを圧縮します。
  • kubevirt-virtctl パッケージがクライアントマシンにインストールされていること。
  • クライアントマシンが OpenShift Container Platform ルーターの証明書を信頼するように設定されていること。

手順

  1. 以下を特定します。

    • 使用するアップロードデータボリュームの名前。このデータボリュームが存在しない場合、これは自動的に作成されます。
    • データボリュームのサイズ (アップロード手順の実行時に作成する必要がある場合)。サイズはディスクイメージのサイズ以上である必要があります。
    • アップロードする必要のある仮想マシンディスクイメージのファイルの場所。
  2. virtctl image-upload コマンドを実行してディスクイメージをアップロードします。直前の手順で特定したパラメーターを指定します。以下に例を示します。

    $ virtctl image-upload dv <datavolume_name> \ 1
    --size=<datavolume_size> \ 2
    --image-path=</path/to/image> \ 3
    1
    データボリュームの名前。
    2
    データボリュームのサイズ。例: --size=500Mi--size=1G
    3
    仮想マシンディスクイメージのファイルパス。
    注記
    • 新規データボリュームを作成する必要がない場合は、--size パラメーターを省略し、--no-create フラグを含めます。
    • ディスクイメージを PVC にアップロードする場合、PVC サイズは圧縮されていない仮想ディスクのサイズよりも大きくなければなりません。
    • HTTPS を使用したセキュアでないサーバー接続を許可するには、--insecure パラメーターを使用します。--insecure フラグを使用する際に、アップロードエンドポイントの信頼性は検証 されない 点に注意してください。
  3. オプション。データボリュームが作成されたことを確認するには、以下のコマンドを実行してすべてのデータボリュームを表示します。

    $ oc get dvs

7.18.7.5. CDI がサポートする操作マトリックス

このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。

コンテンツタイプHTTPHTTPSHTTP Basic 認証レジストリーアップロード

kubevirt (QCOW2)

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2**
✓ GZ*
✓ XZ*

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2*
□ GZ
□ XZ

✓ QCOW2*
✓ GZ*
✓ XZ*

KubeVirt (RAW)

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW*
□ GZ
□ XZ

✓ RAW*
✓ GZ*
✓ XZ*

✓ サポートされる操作

□ サポートされない操作

* スクラッチ領域が必要

**カスタム認証局が必要な場合にスクラッチ領域が必要

7.18.7.6. 関連情報

7.18.8. ブロックストレージデータボリュームへのローカルディスクイメージのアップロード

virtctl コマンドラインユーティリティーを使用して、ローカルのディスクイメージをブロックデータボリュームにアップロードできます。

このワークフローでは、ローカルブロックデバイスを使用して永続ボリュームを使用し、このブロックボリュームを upload データボリュームに関連付け、 virtctl を使用してローカルディスクイメージをデータボリュームにアップロードできます。

7.18.8.1. 前提条件

7.18.8.2. データボリュームについて

DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは OpenShift Virtualization に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。

7.18.8.3. ブロック永続ボリュームについて

ブロック永続ボリューム (PV) は、raw ブロックデバイスによってサポートされる PV です。これらのボリュームにはファイルシステムがなく、オーバーヘッドを削減することで、仮想マシンのパフォーマンス上の利点をもたらすことができます。

raw ブロックボリュームは、PV および永続ボリューム要求 (PVC) 仕様で volumeMode: Block を指定してプロビジョニングされます。

7.18.8.4. ローカルブロック永続ボリュームの作成

ファイルにデータを設定し、これをループデバイスとしてマウントすることにより、ノードでローカルブロック永続ボリューム (PV) を作成します。次に、このループデバイスを PV マニフェストで Block ボリュームとして参照し、これを仮想マシンイメージのブロックデバイスとして使用できます。

手順

  1. ローカル PV を作成するノードに root としてログインします。この手順では、node01 を例に使用します。
  2. ファイルを作成して、これを null 文字で設定し、ブロックデバイスとして使用できるようにします。以下の例では、2Gb (20 100Mb ブロック) のサイズのファイル loop10 を作成します。

    $ dd if=/dev/zero of=<loop10> bs=100M count=20
  3. loop10 ファイルをループデバイスとしてマウントします。

    $ losetup </dev/loop10>d3 <loop10> 1 2
    1
    ループデバイスがマウントされているファイルパスです。
    2
    前の手順で作成したファイルはループデバイスとしてマウントされます。
  4. マウントされたループデバイスを参照する PersistentVolume マニフェストを作成します。

    kind: PersistentVolume
    apiVersion: v1
    metadata:
      name: <local-block-pv10>
      annotations:
    spec:
      local:
        path: </dev/loop10> 1
      capacity:
        storage: <2Gi>
      volumeMode: Block 2
      storageClassName: local 3
      accessModes:
        - ReadWriteOnce
      persistentVolumeReclaimPolicy: Delete
      nodeAffinity:
        required:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - <node01> 4
    1
    ノード上のループデバイスのパス。
    2
    ブロック PV であることを指定します。
    3
    オプション: PV にストレージクラスを設定します。これを省略する場合、クラスターのデフォルトが使用されます。
    4
    ブロックデバイスがマウントされたノード。
  5. ブロック PV を作成します。

    # oc create -f <local-block-pv10.yaml>1
    1
    直前の手順で作成された永続ボリュームのファイル名。

7.18.8.5. アップロードデータボリュームの作成

ローカルディスクイメージのアップロードに使用する upload データソースでデータボリュームを手動で作成できます。

手順

  1. spec: source: upload{} を指定するデータボリューム設定を作成します。

    apiVersion: cdi.kubevirt.io/v1beta1
    kind: DataVolume
    metadata:
      name: <upload-datavolume> 1
    spec:
      source:
          upload: {}
      pvc:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: <2Gi> 2
    1
    データボリュームの名前。
    2
    データボリュームのサイズ。この値がアップロードするディスクのサイズ以上であることを確認します。
  2. 以下のコマンドを実行してデータボリュームを作成します。

    $ oc create -f <upload-datavolume>.yaml

7.18.8.6. ローカルディスクイメージのデータボリュームへのアップロード

virtctl CLI ユーティリティーを使用して、ローカルディスクイメージをクライアントマシンからクラスター内のデータボリューム (DV) にアップロードできます。この手順の実行時に、すでにクラスターに存在する DV を使用するか、または新規の DV を作成することができます。

注記

ローカルディスクイメージのアップロード後に、これを仮想マシンに追加できます。

前提条件

  • 以下のいずれかが必要である。

    • ISO または IMG 形式のいずれかの raw 仮想マシンイメージファイル。
    • QCOW2 形式の仮想マシンのイメージファイル。
  • 最善の結果を得るには、アップロードする前にイメージファイルを以下のガイドラインに従って圧縮すること。

    • xz または gzip を使用して raw イメージファイルを圧縮します。

      注記

      圧縮された raw イメージファイルを使用すると、最も効率的にアップロードできます。

    • クライアントについて推奨される方法を使用して、QCOW2 イメージファイルを圧縮します。

      • Linux クライアントを使用する場合は、virt-sparsify ツールを使用して、QCOW2 ファイルをスパース化 (sparsify) します。
      • Windows クライアントを使用する場合は、xz または gzip を使用して QCOW2 ファイルを圧縮します。
  • kubevirt-virtctl パッケージがクライアントマシンにインストールされていること。
  • クライアントマシンが OpenShift Container Platform ルーターの証明書を信頼するように設定されていること。

手順

  1. 以下を特定します。

    • 使用するアップロードデータボリュームの名前。このデータボリュームが存在しない場合、これは自動的に作成されます。
    • データボリュームのサイズ (アップロード手順の実行時に作成する必要がある場合)。サイズはディスクイメージのサイズ以上である必要があります。
    • アップロードする必要のある仮想マシンディスクイメージのファイルの場所。
  2. virtctl image-upload コマンドを実行してディスクイメージをアップロードします。直前の手順で特定したパラメーターを指定します。以下に例を示します。

    $ virtctl image-upload dv <datavolume_name> \ 1
    --size=<datavolume_size> \ 2
    --image-path=</path/to/image> \ 3
    1
    データボリュームの名前。
    2
    データボリュームのサイズ。例: --size=500Mi--size=1G
    3
    仮想マシンディスクイメージのファイルパス。
    注記
    • 新規データボリュームを作成する必要がない場合は、--size パラメーターを省略し、--no-create フラグを含めます。
    • ディスクイメージを PVC にアップロードする場合、PVC サイズは圧縮されていない仮想ディスクのサイズよりも大きくなければなりません。
    • HTTPS を使用したセキュアでないサーバー接続を許可するには、--insecure パラメーターを使用します。--insecure フラグを使用する際に、アップロードエンドポイントの信頼性は検証 されない 点に注意してください。
  3. オプション。データボリュームが作成されたことを確認するには、以下のコマンドを実行してすべてのデータボリュームを表示します。

    $ oc get dvs

7.18.8.7. CDI がサポートする操作マトリックス

このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。

コンテンツタイプHTTPHTTPSHTTP Basic 認証レジストリーアップロード

kubevirt (QCOW2)

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2**
✓ GZ*
✓ XZ*

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2*
□ GZ
□ XZ

✓ QCOW2*
✓ GZ*
✓ XZ*

KubeVirt (RAW)

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW*
□ GZ
□ XZ

✓ RAW*
✓ GZ*
✓ XZ*

✓ サポートされる操作

□ サポートされない操作

* スクラッチ領域が必要

**カスタム認証局が必要な場合にスクラッチ領域が必要

7.18.8.8. 関連情報

7.18.9. オフラインの仮想マシンスナップショットの管理

オフ (オフライン) になっている仮想マシンの仮想マシン (VM) スナップショットを作成し、復元し、削除できます。OpenShift Virtualization は、以下でオフラインの仮想マシンスナップショットをサポートします。

  • Red Hat OpenShift Container Storage
  • Kubernetes Volume Snapshot API をサポートする Container Storage Interface (CSI) ドライバーを使用するその他のストレージプロバイダー

7.18.9.1. 仮想マシンスナップショットについて

スナップショット は、特定の時点における仮想マシン (VM) の状態およびデータを表します。スナップショットを使用して、バックアップおよび障害復旧のために既存の仮想マシンを (スナップショットで表される) 以前の状態に復元したり、以前の開発バージョンに迅速にロールバックしたりできます。

オフラインの仮想マシンのスナップショットは、電源がオフになった (停止状態の) 仮想マシンから作成されます。スナップショットは、仮想マシンに割り当てられた各 Container Storage Interface (CSI) ボリュームのコピーと、仮想マシンの仕様およびメタデータのコピーを保存します。スナップショットは作成後に変更できません。

オフラインの仮想マシンスナップショット機能を使用すると、クラスター管理者、およびアプリケーション開発者は以下を実行できます。

  • 新規 SCC の作成
  • 特定の仮想マシンに割り当てられているすべてのスナップショットの一覧表示
  • スナップショットからの仮想マシンの復元
  • 既存の仮想マシンスナップショットの削除
7.18.9.1.1. 仮想マシンスナップショットコントローラーおよびカスタムリソース定義 (CRD)

仮想マシンスナップショット機能では、スナップショットを管理するための CRD として定義された 3 つの新規 API オブジェクトが導入されました。

  • VirtualMachineSnapshot: スナップショットを作成するユーザー要求を表します。これには、仮想マシンの現在の状態に関する情報が含まれます。
  • VirtualMachineSnapshotContent: クラスター上のプロビジョニングされたリソース (スナップショット) を表します。これは、仮想マシンのスナップショットコントローラーによって作成され、仮想マシンの復元に必要なすべてのリソースへの参照が含まれます。
  • VirtualMachineRestore: スナップショットから仮想マシンを復元するユーザー要求を表します。

仮想マシンスナップショットコントローラーは、1 対 1 のマッピングで、VirtualMachineSnapshotContent オブジェクトを、この作成に使用した VirtualMachineSnapshot オブジェクトにバインドします。

7.18.9.2. Web コンソールでのオフライン仮想マシンスナップショットの作成

Web コンソールを使用して仮想マシン (VM) を作成することができます。

注記

仮想マシンスナップショットには、以下の要件を満たすディスクのみが含まれます。

  • データボリュームまたは永続ボリューム要求 (PVC) のいずれかでなければなりません。
  • Container Storage Interface (CSI) ボリュームスナップショットをサポートするストレージクラスに属している必要があります。

仮想マシンストレージにスナップショットをサポートしないディスクが含まれる場合、それらを編集するか、またはクラスター管理者にお問い合わせください。

手順

  1. サイドメニューから Workloads Virtualization をクリックします。
  2. Virtual Machines タブをクリックします。
  3. 仮想マシンを選択して、Virtual Machine Overview 画面を開きます。
  4. 仮想マシンが実行されている場合、Actions Stop Virtual Machine をクリックしてこの電源をオフにします。
  5. Snapshots タブをクリックしてから Take Snapshot をクリックします。
  6. Snapshot Name およびオプションの Description フィールドに入力します。
  7. Disks included in this Snapshot を拡張し、スナップショットに組み込むストレージボリュームを表示します。
  8. 仮想マシンにスナップショットに追加できないディスクがあり、それでも続行する場合は、I am aware of this warning and wish to proceed チェックボックスを選択します。
  9. Save をクリックします。

7.18.9.3. CLI でのオフライン仮想マシンスナップショットの作成

VirtualMachineSnapshot オブジェクトを作成し、オフライン仮想マシンの仮想マシン (VM) スナップショットを作成できます。

前提条件

  • 永続ボリューム要求 (PVC) が Container Storage Interface (CSI) ボリュームスナップショットをサポートするストレージクラスにあることを確認する。
  • OpenShift CLI (oc) をインストールしている。
  • スナップショットを作成する仮想マシンの電源を切ること。

手順

  1. YAML ファイルを作成し、新規の VirtualMachineSnapshot の名前およびソース仮想マシンの名前を指定する VirtualMachineSnapshot オブジェトを定義します。

    以下に例を示します。

    apiVersion: snapshot.kubevirt.io/v1alpha1
    kind: VirtualMachineSnapshot
    metadata:
      name: my-vmsnapshot 1
    spec:
      source:
        apiGroup: kubevirt.io
        kind: VirtualMachine
        name: my-vm 2
    1
    新規 VirtualMachineSnapshot オブジェクトの名前。
    2
    ソース仮想マシンの名前。
  2. VirtualMachineSnapshot リソースを作成します。スナップコントローラーは VirtualMachineSnapshotContent オブジェクトを作成し、これを VirtualMachineSnapshot にバインドし、 VirtualMachineSnapshot オブジェクトの status および readyToUse フィールドを更新します。

    $ oc create -f <my-vmsnapshot>.yaml

検証

  1. VirtualMachineSnapshot オブジェクトが作成されており、VirtualMachineSnapshotContent にバインドされていることを確認します。readyToUse フラグを true に設定する必要があります。

    $ oc describe vmsnapshot <my-vmsnapshot>

    出力例

    apiVersion: snapshot.kubevirt.io/v1alpha1
    kind: VirtualMachineSnapshot
    metadata:
    creationTimestamp: "2020-09-30T14:41:51Z"
    finalizers:
    - snapshot.kubevirt.io/vmsnapshot-protection
    generation: 5
    name: mysnap
    namespace: default
    resourceVersion: "3897"
    selfLink: /apis/snapshot.kubevirt.io/v1alpha1/namespaces/default/virtualmachinesnapshots/my-vmsnapshot
    uid: 28eedf08-5d6a-42c1-969c-2eda58e2a78d
    spec:
    source:
    apiGroup: kubevirt.io
    kind: VirtualMachine
    name: my-vm
    status:
    conditions:
      - lastProbeTime: null
      lastTransitionTime: "2020-09-30T14:42:03Z"
      reason: Operation complete
      status: "False" 1
      type: Progressing
      - lastProbeTime: null
      lastTransitionTime: "2020-09-30T14:42:03Z"
      reason: Operation complete
      status: "True" 2
      type: Ready
    creationTime: "2020-09-30T14:42:03Z"
    readyToUse: true 3
    sourceUID: 355897f3-73a0-4ec4-83d3-3c2df9486f4f
    virtualMachineSnapshotContentName: vmsnapshot-content-28eedf08-5d6a-42c1-969c-2eda58e2a78d 4

    1
    Progressing 状態の status フィールドは、スナップショットが作成中であるかどうかを指定します。
    2
    Ready 状態の status フィールドは、スナップショットの作成プロセスが完了しているかどうかを指定します。
    3
    スナップショットを使用する準備ができているかどうかを指定します。
    4
    スナップショットが、スナップショットコントローラーで作成される VirtualMachineSnapshotContent オブジェクトにバインドされるように指定します。
  2. VirtualMachineSnapshotContent リソースの spec:volumeBackups プロパティーをチェックし、予想される PVC がスナップショットに含まれることを確認します。

7.18.9.4. Web コンソールでのスナップショットからの仮想マシンの復元

仮想マシン (VM) は、Web コンソールのスナップショットで表される以前の設定に復元できます。

手順

  1. サイドメニューから Workloads Virtualization をクリックします。
  2. Virtual Machines タブをクリックします。
  3. 仮想マシンを選択して、Virtual Machine Overview 画面を開きます。
  4. 仮想マシンが実行されている場合、Actions Stop Virtual Machine をクリックしてこの電源をオフにします。
  5. Snapshots タブをクリックします。このページには、仮想マシンに関連付けられたスナップショットの一覧が表示されます。
  6. 仮想マシンのスナップショットを復元するには、以下のいずれかの方法を選択します。

    1. 仮想マシンを復元する際にソースとして使用するスナップショットの場合は、Restore をクリックします。
    2. スナップショットを選択して Snapshot Details 画面を開き、Actions Restore Virtual Machine Snapshot をクリックします。
  7. 確認のポップアップウィンドウで Restore をクリックし、仮想マシンをスナップショットで表される以前の設定に戻します。

7.18.9.5. CLI でのスナップショットからの仮想マシンの復元

仮想マシンスナップショットを使用して、既存の仮想マシン (VM) を以前の設定に復元できます。

前提条件

  • OpenShift CLI (oc) をインストールしている。
  • 以前の状態に復元する仮想マシンの電源を切ること。

手順

  1. 復元する仮想マシンの名前およびソースとして使用されるスナップショットの名前を指定する VirtualMachineRestore オブジェクトを定義するために YAML ファイルを作成します。

    以下に例を示します。

    apiVersion: snapshot.kubevirt.io/v1alpha1
    kind: VirtualMachineRestore
    metadata:
      name: my-vmrestore 1
    spec:
      target:
        apiGroup: kubevirt.io
        kind: VirtualMachine
        name: my-vm 2
      virtualMachineSnapshotName: my-vmsnapshot 3
    1
    新規 VirtualMachineRestore オブジェクトの名前。
    2
    復元するターゲット仮想マシンの名前。
    3
    ソースとして使用する VirtualMachineSnapshot オブジェクトの名前。
  2. VirtualMachineRestore リソースを作成します。スナップショットコントローラーは、VirtualMachineRestore オブジェクトのステータスフィールドを更新し、既存の仮想マシン設定をスナップショットのコンテンツに置き換えます。

    $ oc create -f <my-vmrestore>.yaml

検証

  • 仮想マシンがスナップショットで表される以前の状態に復元されていることを確認します。complete フラグは true に設定される必要があります。

    $ oc get vmrestore <my-vmrestore>

    出力例

    apiVersion: snapshot.kubevirt.io/v1alpha1
    kind: VirtualMachineRestore
    metadata:
    creationTimestamp: "2020-09-30T14:46:27Z"
    generation: 5
    name: my-vmrestore
    namespace: default
    ownerReferences:
    - apiVersion: kubevirt.io/v1alpha3
      blockOwnerDeletion: true
      controller: true
      kind: VirtualMachine
      name: my-vm
      uid: 355897f3-73a0-4ec4-83d3-3c2df9486f4f
      resourceVersion: "5512"
      selfLink: /apis/snapshot.kubevirt.io/v1alpha1/namespaces/default/virtualmachinerestores/my-vmrestore
      uid: 71c679a8-136e-46b0-b9b5-f57175a6a041
      spec:
        target:
          apiGroup: kubevirt.io
          kind: VirtualMachine
          name: my-vm
      virtualMachineSnapshotName: my-vmsnapshot
      status:
      complete: true 1
      conditions:
      - lastProbeTime: null
      lastTransitionTime: "2020-09-30T14:46:28Z"
      reason: Operation complete
      status: "False" 2
      type: Progressing
      - lastProbeTime: null
      lastTransitionTime: "2020-09-30T14:46:28Z"
      reason: Operation complete
      status: "True" 3
      type: Ready
      deletedDataVolumes:
      - test-dv1
      restoreTime: "2020-09-30T14:46:28Z"
      restores:
      - dataVolumeName: restore-71c679a8-136e-46b0-b9b5-f57175a6a041-datavolumedisk1
      persistentVolumeClaim: restore-71c679a8-136e-46b0-b9b5-f57175a6a041-datavolumedisk1
      volumeName: datavolumedisk1
      volumeSnapshotName: vmsnapshot-28eedf08-5d6a-42c1-969c-2eda58e2a78d-volume-datavolumedisk1

    1
    仮想マシンをスナップショットで表される状態に復元するプロセスが完了しているかどうかを指定します。
    2
    Progressing 状態の status フィールドは、仮想マシンが復元されているかどうかを指定します。
    3
    Ready 状態の status フィールドは、仮想マシンの復元プロセスが完了しているかどうかを指定します。

7.18.9.6. Web コンソールでの仮想マシンのスナップショットの削除

Web コンソールを使用して既存の仮想マシンスナップショットを削除できます。

手順

  1. サイドメニューから Workloads Virtualization をクリックします。
  2. Virtual Machines タブをクリックします。
  3. 仮想マシンを選択して、Virtual Machine Overview 画面を開きます。
  4. Snapshots タブをクリックします。このページには、仮想マシンに関連付けられたスナップショットの一覧が表示されます。
  5. 仮想マシンスナップショットを削除するには、以下のいずれかの方法を選択します。

    1. 削除する仮想マシンスナップショットの Options メニュー kebab をクリックして、 Delete Virtual Machine Snapshot を選択します。
    2. スナップショットを選択して Snapshot Details 画面を開き、Actions Delete Virtual Machine Snapshot をクリックします。
  6. 確認のポップアップウィンドウで、Delete をクリックしてスナップショットを削除します。

7.18.9.7. CLI での仮想マシンのスナップショットの削除

適切な VirtualMachineSnapshot オブジェクトを削除して、既存の仮想マシン (VM) スナップショットを削除できます。

前提条件

  • OpenShift CLI (oc) をインストールしている。

手順

  • VirtualMachineSnapshot オブジェクトを削除します。スナップショットコントローラーは、VirtualMachineSnapshot を、関連付けられた VirtualMachineSnapshotContent オブジェクトと共に削除します。

    $ oc delete vmsnapshot <my-vmsnapshot>

検証

  • スナップショットが削除され、この仮想マシンに割り当てられていないことを確認します。

    $ oc get vmsnapshot

7.18.9.8. 関連情報

7.18.10. ローカル仮想マシンディスクの別のノードへの移動

ローカルボリュームストレージを使用する仮想マシンは、特定のノードで実行されるように移動することができます。

以下の理由により、仮想マシンを特定のノードに移動する場合があります。

  • 現在のノードにローカルストレージ設定に関する制限がある。
  • 新規ノードがその仮想マシンのワークロードに対して最適化されている。

ローカルストレージを使用する仮想マシンを移行するには、データボリュームを使用して基礎となるボリュームのクローンを作成する必要があります。クローン操作が完了したら、新規データボリュームを使用できるように 仮想マシン設定を編集 するか、または 新規データボリュームを別の仮想マシンに追加 できます。

注記

cluster-admin ロールのないユーザーには、複数の namespace 間でボリュームのクローンを作成できるように 追加のユーザーパーミッション が必要になります。

7.18.10.1. ローカルボリュームの別のノードへのクローン作成

基礎となる永続ボリューム要求 (PVC) のクローンを作成して、仮想マシンディスクを特定のノードで実行するように移行することができます。

仮想マシンディスクのノードが適切なノードに作成されることを確認するには、新規の永続ボリューム (PV) を作成するか、または該当するノードでそれを特定します。一意のラベルを PV に適用し、これがデータボリュームで参照できるようにします。

注記

宛先 PV のサイズはソース PVC と同じか、またはそれよりも大きくなければなりません。宛先 PV がソース PVC よりも小さい場合、クローン作成操作は失敗します。

前提条件

  • 仮想マシンが実行されていないこと。仮想マシンディスクのクローンを作成する前に、仮想マシンの電源を切ります。

手順

  1. ノードに新規のローカル PV を作成するか、またはノードにすでに存在しているローカル PV を特定します。

    • nodeAffinity.nodeSelectorTerms パラメーターを含むローカル PV を作成します。以下のマニフェストは、node0110Gi のローカル PV を作成します。

      kind: PersistentVolume
      apiVersion: v1
      metadata:
        name: <destination-pv> 1
        annotations:
      spec:
        accessModes:
        - ReadWriteOnce
        capacity:
          storage: 10Gi 2
        local:
          path: /mnt/local-storage/local/disk1 3
        nodeAffinity:
          required:
            nodeSelectorTerms:
            - matchExpressions:
              - key: kubernetes.io/hostname
                operator: In
                values:
                - node01 4
        persistentVolumeReclaimPolicy: Delete
        storageClassName: local
        volumeMode: Filesystem
      1
      PV の名前。
      2
      PV のサイズ。十分な領域を割り当てる必要があります。そうでない場合には、クローン操作は失敗します。サイズはソース PVC と同じか、またはそれよりも大きくなければなりません。
      3
      ノードのマウントパス。
      4
      PV を作成するノードの名前。
    • ターゲットノードに存在する PV を特定します。設定の nodeAffinity フィールドを確認して、PV がプロビジョニングされるノードを特定することができます。

      $ oc get pv <destination-pv> -o yaml

      以下のスニペットは、PV が node01 にあることを示しています。

      出力例

      ...
      spec:
        nodeAffinity:
          required:
            nodeSelectorTerms:
            - matchExpressions:
              - key: kubernetes.io/hostname 1
                operator: In
                values:
                - node01 2
      ...

      1
      kubernetes.io/hostname キーでは、ノードを選択するためにノードホスト名を使用します。
      2
      ノードのホスト名。
  2. PV に一意のラベルを追加します。

    $ oc label pv <destination-pv> node=node01
  3. 以下を参照するデータボリュームマニフェストを作成します。

    • 仮想マシンの PVC 名と namespace。
    • 直前の手順で PV に適用されたラベル。
    • 宛先 PV のサイズ。

      apiVersion: cdi.kubevirt.io/v1beta1
      kind: DataVolume
      metadata:
        name: <clone-datavolume> 1
      spec:
        source:
          pvc:
            name: "<source-vm-disk>" 2
            namespace: "<source-namespace>" 3
        pvc:
          accessModes:
            - ReadWriteOnce
          selector:
            matchLabels:
              node: node01 4
          resources:
            requests:
              storage: <10Gi> 5
      1
      新規データボリュームの名前。
      2
      ソース PVC の名前。PVC 名が分からない場合は、仮想マシン設定 spec.volumes.persistentVolumeClaim.claimName で確認できます。
      3
      ソース PVC が存在する namespace。
      4
      直前の手順で PV に追加したラベル。
      5
      宛先 PV のサイズ。
  4. データボリュームマニフェストをクラスターに適用してクローン作成の操作を開始します。

    $ oc apply -f <clone-datavolume.yaml>

データボリュームは、仮想マシンの PVC のクローンを特定のノード上の PV に作成します。

7.18.11. 空のディスクイメージを追加して仮想ストレージを拡張する

空のディスクイメージを OpenShift Virtualization に追加することによって、ストレージ容量を拡張したり、新規のデータパーティションを作成したりできます。

7.18.11.1. データボリュームについて

DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは OpenShift Virtualization に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。

7.18.11.2. データボリュームを使用した空のディスクイメージの作成

データボリューム設定ファイルをカスタマイズし、デプロイすることにより、新規の空のディスクイメージを永続ボリューム要求 (PVC) に作成することができます。

前提条件

  • 1 つ以上の利用可能な永続ボリュームがあること。
  • OpenShift CLI (oc) をインストールしている。

手順

  1. データボリューム設定ファイルを編集します。

    apiVersion: cdi.kubevirt.io/v1beta1
    kind: DataVolume
    metadata:
      name: blank-image-datavolume
    spec:
      source:
          blank: {}
      pvc:
        # Optional: Set the storage class or omit to accept the default
        # storageClassName: "hostpath"
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 500Mi
  2. 以下のコマンドを実行して、空のディスクイメージを作成します。

    $ oc create -f <blank-image-datavolume>.yaml

7.18.11.3. テンプレート: 空のディスクイメージのデータボリューム設定ファイル

blank-image-datavolume.yaml

apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
  name: blank-image-datavolume
spec:
  source:
      blank: {}
  pvc:
    # Optional: Set the storage class or omit to accept the default
    # storageClassName: "hostpath"
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: 500Mi

7.18.11.4. 関連情報

7.18.12. smart-cloning を使用したデータボリュームのクローン作成

smart-cloning は OpenShift Container Platform Storage (OCS) のビルトイン機能であり、クローン作成プロセスのパフォーマンスを強化するように設計されています。smart-cloning で作成したクローンは、ホスト支援型のクローン作成よりも速く、効率的です。

smart-cloning を有効にするためにアクションを実行する必要はありませんが、この機能を使用するには、ストレージ環境が smart-cloning と互換性があることを確認する必要があります。

永続ボリューム要求 (PVC) ソースでデータボリュームを作成すると、クローン作成プロセスが自動的に開始します。お使いの環境で smart-cloning をサポートするかどうかにかかわらず、データボリュームのクローンは常に受信できます。ただし、ストレージプロバイダーが smart-cloning に対応している場合、smart-cloning によるパフォーマンス上のメリットが得られます。

7.18.12.1. smart-cloning について

データボリュームに smart-cloning が実行された場合、以下が発生します。

  1. ソースの永続ボリューム要求 (PVC) のスナップショットが作成されます。
  2. PVC はスナップショットから作成されます。
  3. スナップショットは削除されます。

7.18.12.2. データボリュームのクローン作成

前提条件

smart-cloning が実行されるには、以下の条件が必要です。

  • ストレージプロバイダーはスナップショットをサポートする必要がある。
  • ソースおよびターゲット PVC は、同じ namespace に定義される必要がある。
  • ソースおよびターゲット PVC は、同じストレージクラスに定義される必要がある。
  • VolumeSnapshotClass オブジェクトは、ソースおよびターゲット PVC の両方に定義されるストレージクラスを参照する必要がある。

これらの前提条件のいずれかが満たされない場合、PVC ソースでデータボリュームを作成すると、ホスト支援型クローンが自動的に実行されます。

手順

データボリュームのクローン作成を開始するには、以下を実行します。

  1. 新規データボリュームの名前、ソース PVC の名前および namespace、および新規データボリュームのサイズを指定する DataVolume オブジェクトの YAML ファイルを作成します。この例では、ソース PVC のクローンをブロックモードで作成し、volumeMode: Block が使用されます。

    apiVersion: cdi.kubevirt.io/v1beta1
    kind: DataVolume
    metadata:
      name: <cloner-datavolume> 1
    spec:
      source:
        pvc:
          namespace: "<source-namespace>" 2
          name: "<my-favorite-vm-disk>" 3
      pvc:
        accessModes:
          - ReadWriteMany
        resources:
          requests:
            storage: <2Gi> 4
        volumeMode: Block 5
    1
    新規データボリュームの名前。
    2
    ソース PVC が存在する namespace。
    3
    ソース PVC の名前。
    4
    新規データボリュームのサイズ。十分な領域を割り当てる必要があります。そうでない場合には、クローン操作は失敗します。サイズはソース PVC と同じか、またはそれよりも大きくなければなりません。
    5
    宛先がブロック PV であることを指定します。
  2. データボリュームを作成して PVC のクローン作成を開始します。

    $ oc create -f <cloner-datavolume>.yaml
    注記

    データボリュームは仮想マシンが PVC の作成前に起動することを防ぐため、PVC のクローン作成中に新規データボリュームを参照する仮想マシンを作成できます。

7.18.12.3. 関連情報

7.18.13. データボリュームのストレージのデフォルト

kubevirt-storage-class-defaults 設定マップはデータボリュームの アクセスモード および ボリュームモード のデフォルト設定を提供します。Web コンソールで、基礎となるストレージにより適したデータボリュームを作成するために、設定マップに対してストレージクラスのデフォルトを編集したり、追加したりできます。

7.18.13.1. データボリュームのストレージ設定について

データボリュームでは、定義された アクセスモードボリュームモード を Web コンソールで作成する必要があります。これらのストレージ設定は、デフォルトで ReadWriteOnce アクセスモードおよび Filesystem ボリュームモードで設定されます。

これらの設定は、openshift-cnv namespace で kubevirt-storage-class-defaults 設定マップを編集して変更できます。また、異なるストレージタイプについて Web コンソールでデータボリュームを作成するために、他のストレージクラスの設定を追加することもできます。

注記

基礎となるストレージでサポートされるストレージ設定を設定する必要があります。

Web コンソールで作成するすべてのデータボリュームは、設定マップにも定義されるストレージクラスを指定しない限り、デフォルトのストレージ設定を使用します。

7.18.13.1.1. アクセスモード

データボリュームは以下のアクセスモードをサポートします。

  • ReadWriteOnce: ボリュームは単一ノードで、read-write としてマウントできます。ReadWriteOnce にはより多様性があり、これはデフォルトの設定です。
  • ReadWriteMany: ボリュームは数多くのノードで、read-write としてマウントできます。ReadWriteMany は、ノード間の仮想マシンのライブマイグレーションなどの、一部の機能で必要になります。

ReadWriteMany は、基礎となるストレージがこれをサポートしている場合に推奨されます。

7.18.13.1.2. ボリュームモード

ボリュームモードは、ボリュームをフォーマットされたファイルシステムで使用するか、または raw ブロック状態のままにするかを定義します。データボリュームは以下のボリュームモードをサポートします。

  • Filesystem: データボリュームにファイルシステムを作成します。これはデフォルトの設定です。
  • Block: ブロックデータボリュームを作成します。基礎となるストレージがサポートしている場合は、 Block を使用します。

7.18.13.2. Web コンソールでの kubevirt-storage-class-defaults 設定マップの編集

データボリュームのストレージ設定を、openshift-cnv namespace の kubevirt-storage-class-defaults 設定マップを編集して変更します。また、異なるストレージタイプについて Web コンソールでデータボリュームを作成するために、他のストレージクラスの設定を追加することもできます。

注記

基礎となるストレージでサポートされるストレージ設定を設定する必要があります。

手順

  1. サイドメニューから、Workloads Config Maps をクリックします。
  2. Project 一覧で、openshift-cnv を選択します。
  3. kubevirt-storage-class-defaults をクリックして Config Map Overview を開きます。
  4. YAML タブをクリックして編集可能な設定を表示します。
  5. 基礎となるストレージに適したストレージ設定で data の値を更新します。

    ...
    data:
      accessMode: ReadWriteOnce 1
      volumeMode: Filesystem 2
      <new>.accessMode: ReadWriteMany 3
      <new>.volumeMode: Block 4
    1
    デフォルトの accessMode は ReadWriteOnce です。
    2
    デフォルトの volumeMode は Filesystem です。
    3
    ストレージクラスのアクセスモードを追加する場合は、パラメーターの <new> 部分をストレージクラス名に置き換えます。
    4
    ストレージクラスのボリュームモードを追加する場合は、パラメーターの <new> 部分をストレージクラス名に置き換えます。
  6. Save をクリックして設定マップを更新します。

7.18.13.3. CLI での kubevirt-storage-class-defaults 設定マップの編集

データボリュームのストレージ設定を、openshift-cnv namespace の kubevirt-storage-class-defaults 設定マップを編集して変更します。また、異なるストレージタイプについて Web コンソールでデータボリュームを作成するために、他のストレージクラスの設定を追加することもできます。

注記

基礎となるストレージでサポートされるストレージ設定を設定する必要があります。

手順

  1. 以下のコマンドを実行して設定マップを編集します。

    $ oc edit configmap kubevirt-storage-class-defaults -n openshift-cnv
  2. 設定マップの data 値を更新します。

    ...
    data:
      accessMode: ReadWriteOnce 1
      volumeMode: Filesystem 2
      <new>.accessMode: ReadWriteMany 3
      <new>.volumeMode: Block 4
    1
    デフォルトの accessMode は ReadWriteOnce です。
    2
    デフォルトの volumeMode は Filesystem です。
    3
    ストレージクラスのアクセスモードを追加する場合は、パラメーターの <new> 部分をストレージクラス名に置き換えます。
    4
    ストレージクラスのボリュームモードを追加する場合は、パラメーターの <new> 部分をストレージクラス名に置き換えます。
  3. エディターを保存し、終了して設定マップを更新します。

7.18.13.4. 複数のストレージクラスのデフォルト例

以下の YAML ファイルは、kubevirt-storage-class-defaults 設定マップの例です。これには、migration および block の 2 つのストレージクラスについてストレージが設定されます。

設定マップを更新する前に、すべての設定が基礎となるストレージでサポートされていることを確認してください。

kind: ConfigMap
apiVersion: v1
metadata:
  name: kubevirt-storage-class-defaults
  namespace: openshift-cnv
...
data:
  accessMode: ReadWriteOnce
  volumeMode: Filesystem
  nfs-sc.accessMode: ReadWriteMany
  nfs-sc.volumeMode: Filesystem
  block-sc.accessMode: ReadWriteMany
  block-sc.volumeMode: Block

7.18.14. ブートソースの作成および使用

ブートソース には、ブート可能なオペレーティングシステム (OS) とドライバーなどの OS のすべての設定が含まれます。

ブートソースを使用して、特定の設定で仮想マシンテンプレートを作成します。これらのテンプレートを使用して、利用可能な仮想マシンを多数作成することができます。

カスタムブートソースの作成、ブートソースのアップロード、およびその他のタスクを支援するために、OpenShift Container Platform Web コンソールでクイックスタートツアーを利用できます。Help メニューから Quick Starts を選択して、クイックスタートツアーを表示します。

前提条件

  • ブートソースを追加するには、os-images.kubevirt.io:edit RBAC ロールを持つユーザー、または管理者としてログインしていること。ブートソースが割り当てられたテンプレートから仮想マシンを作成するには、特別な権限は必要ありません。
注記

Microsoft Windows の要件の詳細は、Creating installation media for Windows boot sources を参照してください。

7.18.14.1. 仮想マシンテンプレートのブートソースの追加

ブートソースは、仮想マシンの作成に使用するすべての仮想マシンテンプレートまたはカスタムテンプレートに設定できます。仮想マシンテンプレートがブートソースを使用して設定されている場合、それらには Templates タブで Available というラベルが付けられます。ブートソースをテンプレートに追加した後に、テンプレートから新規仮想マシンを作成できます。

Web コンソールでブートソースを選択および追加する方法は 4 つあります。

  • ローカルファイルのアップロード (PVC の作成)
  • URL を使用したインポート (PVC の作成)
  • 既存の PVC のクローン作成 (PVC の作成)
  • レジストリーを使用したインポート (PVC の作成)

前提条件

  • ブートソースを追加するには、os-images.kubevirt.io:edit RBAC ロールを持つユーザー、または管理者としてログインしていること。ブートソースが追加されたテンプレートから仮想マシンを作成するには、特別な権限は必要ありません。
  • ローカルファイルをアップロードするには、オペレーティングシステムのイメージファイルがローカルマシンに存在している必要がある。
  • URL を使用してインポートするには、オペレーティングシステムイメージのある Web サーバーへのアクセスが必要である。例: イメージが含まれる Red Hat Enterprise Linux Web ページ。
  • 既存の PVC のクローンを作成するには、PVC を含むプロジェクトへのアクセスが必要である。
  • レジストリーを使用してインポートするには、コンテナーレジストリーへのアクセスが必要である。

手順

  1. OpenShift Virtualization コンソールのサイドメニューから Workloads Virtualization をクリックします。
  2. Templates タブをクリックします。
  3. ブートソースを設定する仮想マシンテンプレートを特定し、Add source をクリックします。
  4. Add boot source to template ウィンドウで、 Select boot source をクリックし、永続ボリューム要求 (PVC) を作成するための方法を選択します: ローカルファイルのアップロードURL を使用したインポート既存 PVC のクローン作成、またはレジストリーを使用したインポート
  5. オプション:This is a CD-ROM boot source をクリックして CD-ROM をマウントし、これを使用してオペレーティングシステムを空のディスクにインストールします。追加の空のディスクは OpenShift Virtualization で自動作成およびマウントされます。追加のディスクが必要ない場合には、仮想マシンの作成時に削除できます。
  6. Persistent Volume Claim size の値を入力し、圧縮解除されたイメージおよび必要な追加の領域に十分な PVC サイズを指定します。

    1. オプション: このテンプレートに名前を関連付けるために Source provider の名前を入力します。
    2. Advanced: Storage class をクリックし、ディスクを作成するために使用されるストレージクラスを選択します。
    3. Advanced: Access mode をクリックし、永続ボリュームのアクセスモードを選択します。サポートされるアクセスモード: Single User (RWO)Shared Access (RWX)、および Read Only (ROX)
    4. Advanced: デフォルト値の Filesystem の代わりに Block を選択する場合は、Volume mode をクリックします。
  7. ブートソースを保存する適切な方法を選択します。

    1. ローカルファイルをアップロードしている場合に、Save and upload をクリックします。
    2. URL またはレジストリーからコンテンツをインポートしている場合は、Save and import をクリックします。
    3. 既存の PVC のクローンを作成している場合は、Save and clone をクリックします。

ブートソースが含まれるカスタム仮想マシンテンプレートは Templates タブに一覧表示され、このテンプレートを使用して仮想マシンを作成できます。

7.18.14.2. ブートソースが割り当てられたテンプレートからの仮想マシンの作成

ブートソースをテンプレートに追加した後に、テンプレートから新規仮想マシンを作成できます。

手順

  1. OpenShift Container Platform Web コンソールで、サイドメニューの Workloads > Virtualization をクリックします。
  2. Virtual Machines タブまたは Templates タブで、Create をクリックし、Virtual Machine with Wizard を選択します。
  3. General ステップで、OS およびバージョン名の横にある (Source available) ラベルのあるオペレーティングシステムの一覧から OS を選択します。(Source available) ラベルは、この OS でブートソースが利用可能であることを示します。
  4. Select a template ステップで、OS およびバージョン名の横にある (Source available) ラベルのあるオペレーティングシステムの一覧から OS を選択します。(Source available) ラベルは、この OS でブートソースが利用可能であることを示します。
  5. Review and Confirm をクリックします。
  6. 必要に応じて、仮想マシンの設定を確認し、これを編集します。
  7. Create Virtual Machine をクリックし、仮想マシンを作成します。Successfully created virtual machine ページが表示されます。

7.18.14.3. 関連情報

7.18.15. 仮想マシンでのコンテナーディスクの使用

仮想マシンイメージをコンテナーディスクにビルドし、これをコンテナーレジストリーに保存することができます。次に、コンテナーディスクを仮想マシンの永続ストレージにインポートしたり、一時ストレージの仮想マシンに直接割り当てたりすることができます。

重要

大規模なコンテナーディスクを使用する場合、I/O トラフィックが増え、ワーカーノードに影響を与える可能性があります。これにより、ノードが利用できなくなる可能性があります。この問題を解決するには、以下を実行します。

7.18.15.1. コンテナーディスクについて

コンテナーディスクは、コンテナーイメージレジストリーにコンテナーイメージとして保存される仮想マシンのイメージです。コンテナーディスクを使用して、同じディスクイメージを複数の仮想マシンに配信し、多数の仮想マシンのクローンを作成することができます。

コンテナーディスクは、仮想マシンに割り当てられるデータボリュームを使用して永続ボリューム要求 (PVC) にインポートするか、または一時 containerDisk ボリュームとして仮想マシンに直接割り当てることができます。

7.18.15.1.1. データボリュームの使用によるコンテナーディスクの PVC へのインポート

Containerized Data Importer (CDI) を使用し、データボリュームを使用してコンテナーディスクを PVC にインポートします。次に、データボリュームを永続ストレージの仮想マシンに割り当てることができます。

7.18.15.1.2. コンテナーディスクの containerDisk ボリュームとしての仮想マシンへの割り当て

containerDisk ボリュームは一時的なボリュームです。これは、仮想マシンが停止されるか、再起動するか、または削除される際に破棄されます。containerDisk ボリュームを持つ仮想マシンが起動すると、コンテナーイメージはレジストリーからプルされ、仮想マシンをホストするノードでホストされます。

containerDisk ボリュームは、CD-ROM などの読み取り専用ファイルシステム用に、または破棄可能な仮想マシン用に使用します。

重要

データはホストノードのローカルストレージに一時的に書き込まれるため、読み取り/書き込みファイルシステムに containerDisk ボリュームを使用することは推奨されません。これにより、データを移行先ノードに移行する必要があるため、ノードのメンテナンス時など、仮想マシンのライブマイグレーションが遅くなります。さらに、ノードの電源が切れた場合や、予期せずにシャットダウンする場合にすべてのデータが失われます。

7.18.15.2. 仮想マシン用のコンテナーディスクの準備

仮想マシンイメージでコンテナーディスクをビルドし、これを仮想マシンで使用する前にこれをコンテナーレジストリーにプッシュする必要があります。次に、データボリュームを使用してコンテナーディスクを PVC にインポートし、これを仮想マシンに割り当てるか、またはコンテナーディスクを一時的な containerDisk ボリュームとして仮想マシンに直接割り当てることができます。

コンテナーディスク内のディスクイメージのサイズは、コンテナーディスクがホストされるレジストリーの最大レイヤーサイズによって制限されます。

注記

Red Hat Quay の場合、Red Hat Quay の初回デプロイ時に作成される YAML 設定ファイルを編集して、最大レイヤーサイズを変更できます。

前提条件

  • podman がインストールされていない場合はインストールすること。
  • 仮想マシンイメージは QCOW2 または RAW 形式のいずれかであること。

手順

  1. Dockerfile を作成して、仮想マシンイメージをコンテナーイメージにビルドします。仮想マシンイメージは、UID が 107 の QEMU で所有され、コンテナー内の /disk/ ディレクトリーに置かれる必要があります。次に、/disk/ ディレクトリーのパーミッションは 0440 に設定する必要があります。

    以下の例では、Red Hat Universal Base Image (UBI) を使用して最初の段階でこれらの設定変更を処理し、2 番目の段階で最小の scratch イメージを使用して結果を保存します。

    $ cat > Dockerfile << EOF
    FROM registry.access.redhat.com/ubi8/ubi:latest AS builder
    ADD --chown=107:107 <vm_image>.qcow2 /disk/ 1
    RUN chmod 0440 /disk/*
    
    FROM scratch
    COPY --from=builder /disk/* /disk/
    EOF
    1
    ここで、<vm_image> は QCOW2 または RAW 形式の仮想マシンイメージです。
    リモートの仮想マシンイメージを使用するには、<vm_image>.qcow2 をリモートイメージの完全な URL に置き換えます。
  2. コンテナーをビルドし、これにタグ付けします。

    $ podman build -t <registry>/<container_disk_name>:latest .
  3. コンテナーイメージをレジストリーにプッシュします。

    $ podman push <registry>/<container_disk_name>:latest

コンテナーレジストリーに TLS がない場合は、コンテナーディスクを永続ストレージにインポートする前に非セキュアなレジストリーとしてこれを追加する必要があります。

7.18.15.3. 非セキュアなレジストリーとして使用するコンテナーレジストリーの TLS の無効化

レジストリーを cdi-insecure-registries 設定マップに追加することで、コンテナーレジストリーの TLS (トランスポート層セキュリティー) を無効にできます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにログインすること。

手順

  • openshift-cnv namespace の cdi-insecure-registries 設定マップにレジストリーを追加します。

    $ oc patch configmap cdi-insecure-registries -n openshift-cnv \
      --type merge -p '{"data":{"mykey": "<insecure-registry-host>:5000"}}' 1
    1
    <insecure-registry-host> をレジストリーのホスト名に置き換えます。

7.18.15.4. 次のステップ

7.18.16. CDI のスクラッチ領域の用意

7.18.16.1. データボリュームについて

DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは OpenShift Virtualization に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。

7.18.16.2. スクラッチ領域について

Containerized Data Importer (CDI) では、仮想マシンイメージのインポートやアップロードなどの、一部の操作を実行するためにスクラッチ領域 (一時ストレージ) が必要になります。このプロセスで、CDI は、宛先データボリューム (DV) をサポートする PVC のサイズと同じサイズのスクラッチ領域 PVC をプロビジョニングします。スクラッチ領域 PVC は操作の完了または中止後に削除されます。

CDI オブジェクトの spec.config.scratchSpaceStorageClass フィールドでスクラッチ領域 PVC をバインドするために使用されるストレージクラスを定義できます。

定義されたストレージクラスがクラスターのストレージクラスに一致しない場合、クラスターに定義されたデフォルトのストレージクラス が使用されます。クラスターで定義されたデフォルトのストレージクラスがない場合、元の DV または PVC のプロビジョニングに使用されるストレージクラスが使用されます。

注記

CDI では、元のデータボリュームをサポートする PVC の種類を問わず、file ボリュームモードが設定されているスクラッチ領域が必要です。元の PVC が block ボリュームモードでサポートされる場合、 file ボリュームモード PVC をプロビジョニングできるストレージクラスを定義する必要があります。

手動プロビジョニング

ストレージクラスがない場合、CDI はイメージのサイズ要件に一致するプロジェクトの PVC を使用します。これらの要件に一致する PVC がない場合、CDI インポート Pod は適切な PVC が利用可能になるまで、またはタイムアウト機能が Pod を強制終了するまで Pending 状態になります。

7.18.16.3. スクラッチ領域を必要とする CDI 操作

Type理由

レジストリーのインポート

CDI はイメージをスクラッチ領域にダウンロードし、イメージファイルを見つけるためにレイヤーを抽出する必要があります。その後、raw ディスクに変換するためにイメージファイルが QEMU-img に渡されます。

イメージのアップロード

QEMU-IMG は STDIN の入力を受け入れません。代わりに、アップロードするイメージは、変換のために QEMU-IMG に渡される前にスクラッチ領域に保存されます。

アーカイブされたイメージの HTTP インポート

QEMU-IMG は、CDI がサポートするアーカイブ形式の処理方法を認識しません。イメージが QEMU-IMG に渡される前にアーカイブは解除され、スクラッチ領域に保存されます。

認証されたイメージの HTTP インポート

QEMU-IMG が認証を適切に処理しません。イメージが QEMU-IMG に渡される前にスクラッチ領域に保存され、認証されます。

カスタム証明書の HTTP インポート

QEMU-IMG は HTTPS エンドポイントのカスタム証明書を適切に処理しません。代わりに CDI は、ファイルを QEMU-IMG に渡す前にイメージをスクラッチ領域にダウンロードします。

7.18.16.4. CDI オブジェクトでのストレージクラスの定義

CDI オブジェクトでストレージクラスを定義し、CDI 操作のスクラッチ領域を動的にプロビジョニングします。

前提条件

  • OpenShift CLI (oc) をインストールすること。

手順

  1. oc クライアントを使用して CDI オブジェクトを編集します。

    $ oc edit cdi
  2. spec.config.scratchSpaceStorageClass フィールドを、クラスターのストレージクラスに一致するように編集します。

    apiVersion: cdi.kubevirt.io/v1beta1
    kind: CDI
    ...
    spec:
      config:
        scratchSpaceStorageClass: "<storage_class>" 1
    ...
    1
    <storage_class> を、クラスター内の CDI 操作のスクラッチ領域をプロビジョニングするために使用するストレージクラスに置き換えます。
  3. デフォルトエディターを保存し、終了して CDI オブジェクトを更新します。

7.18.16.5. CDI がサポートする操作マトリックス

このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。

コンテンツタイプHTTPHTTPSHTTP Basic 認証レジストリーアップロード

kubevirt (QCOW2)

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2**
✓ GZ*
✓ XZ*

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2*
□ GZ
□ XZ

✓ QCOW2*
✓ GZ*
✓ XZ*

KubeVirt (RAW)

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW*
□ GZ
□ XZ

✓ RAW*
✓ GZ*
✓ XZ*

✓ サポートされる操作

□ サポートされない操作

* スクラッチ領域が必要

**カスタム認証局が必要な場合にスクラッチ領域が必要

関連情報

  • ストレージクラスおよびこれらがクラスターで定義される方法についての詳細は、動的プロビジョニング セクションを参照してください。

7.18.17. 永続ボリュームの再利用

静的にプロビジョニングされた永続ボリューム (PV) を再利用するには、まずボリュームを回収する必要があります。これには、ストレージ設定を再利用できるように PV を削除する必要があります。

7.18.17.1. 静的にプロビジョニングされた永続ボリュームの回収について

永続ボリューム (PV) を回収する場合、PV のバインドを永続ボリューム要求 (PVC) から解除し、PV を削除します。基礎となるストレージによっては、共有ストレージを手動で削除する必要がある場合があります。

次に、PV 設定を再利用し、異なる名前の PV を作成できます。

静的にプロビジョニングされる PV には、回収に Retain の回収 (reclaim) ポリシーが必要です。これがない場合、PV は PVC が PV からのバインド解除時に failed 状態になります。

重要

Recycle 回収ポリシーは OpenShift Container Platform 4 では非推奨となっています。

7.18.17.2. 静的にプロビジョニングされた永続ボリュームの回収

永続ボリューム要求 (PVC) のバインドを解除し、PV を削除して静的にプロビジョニングされた永続ボリューム (PV) を回収します。共有ストレージを手動で削除する必要がある場合もあります。

静的にプロビジョニングされる PV の回収方法は、基礎となるストレージによって異なります。この手順では、ストレージに応じてカスタマイズする必要がある可能性のある一般的な方法を示します。

手順

  1. PV の回収ポリシーが Retain に設定されていることを確認します。

    1. PV の回収ポリシーを確認します。

      $ oc get pv <pv_name> -o yaml | grep 'persistentVolumeReclaimPolicy'
    2. persistentVolumeReclaimPolicyRetain に設定されていない場合、以下のコマンドで回収ポリシーを編集します。

      $ oc patch pv <pv_name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
  2. PV を使用しているリソースがないことを確認します。

    $ oc describe pvc <pvc_name> | grep 'Mounted By:'

    PVC を使用するリソースをすべて削除してから継続します。

  3. PVC を削除して PV を解放します。

    $ oc delete pvc <pvc_name>
  4. オプション: PV 設定を YAML ファイルにエクスポートします。この手順の後半で共有ストレージを手動で削除する場合は、この設定を参照してください。このファイルで spec パラメーターをベースとして使用し、PV の回収後に同じストレージ設定で新規 PV を作成することもできます。

    $ oc get pv <pv_name> -o yaml > <file_name>.yaml
  5. PV を削除します。

    $ oc delete pv <pv_name>
  6. オプション: ストレージタイプによっては、共有ストレージフォルダーの内容を削除する必要がある場合があります。

    $ rm -rf <path_to_share_storage>
  7. オプション: 削除された PV と同じストレージ設定を使用する PV を作成します。回収された PV 設定をすでにエクスポートしている場合、そのファイルの spec パラメーターを新規 PV マニフェストのベースとして使用することができます。

    注記

    競合の可能性を回避するには、新規 PV オブジェクトに削除されたものとは異なる名前を割り当てることが推奨されます。

    $ oc create -f <new_pv_name>.yaml

関連情報

7.18.18. データボリュームの削除

oc コマンドラインインターフェイスを使用して、データボリュームを手動で削除できます。

注記

仮想マシンを削除する際に、これが使用するデータボリュームは自動的に削除されます。

7.18.18.1. データボリュームについて

DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは OpenShift Virtualization に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。

7.18.18.2. すべてのデータボリュームの一覧表示

oc コマンドラインインターフェイスを使用して、クラスターのデータボリュームを一覧表示できます。

手順

  • 以下のコマンドを実行して、データボリュームを一覧表示します。

    $ oc get dvs

7.18.18.3. データボリュームの削除

oc コマンドラインインターフェイス (CLI) を使用してデータボリュームを削除できます。

前提条件

  • 削除する必要のあるデータボリュームの名前を特定すること。

手順

  • 以下のコマンドを実行し、データボリューム を削除します。

    $ oc delete dv <datavolume_name>
    注記

    このコマンドは、現在のプロジェクトに存在するオブジェクトのみを削除します。削除する必要のあるオブジェクトが別のプロジェクトまたは namespace にある場合、-n <project_name> オプションを指定します。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.