6.12. 仮想マシンディスク

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

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

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

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

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

  • SELinux を設定します。

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

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

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

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

注記

Red Hat Enterprise Linux CoreOS ワーカーを使用しない場合は、この手順を省略します。

前提条件

  • ホストパスプロビジョナーが作成する PersistentVolume (PV) 用に、各ノードにバッキングディレクトリーを作成します。
警告

オペレーティングシステムと領域を共有するディレクトリーを選択すると、パーティションの領域を使い切ってしまう可能性があり、ノードが機能しなくなる可能性があります。この問題を回避するには、個別のパーティションを作成し、そのディレクトリーに hostpath プロビジョナーをポイントします。

手順

  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: 2.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 <path/to/backing/directory> 1
    
                [Install]
                WantedBy=multi-user.target
              enabled: true
              name: hostpath-provisioner.service
    1
    プロビジョナーが PV を作成するバッキングディレクトリーを指定します。
  3. MachineConfig オブジェクトを作成します。

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

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

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

前提条件

  • ホストパスプロビジョナーが作成する PersistentVolume (PV) 用に、各ノードにバッキングディレクトリーを作成します。
警告

オペレーティングシステムと領域を共有するディレクトリーを選択すると、パーティションの領域を使い切ってしまう可能性があり、ノードが機能しなくなる可能性があります。この問題を回避するには、個別のパーティションを作成し、そのディレクトリーに hostpath プロビジョナーをポイントします。

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

    $ sudo chcon -t container_file_t -R </path/to/backing/directory>
    注記

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

手順

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

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

    apiVersion: hostpathprovisioner.kubevirt.io/v1alpha1
    kind: HostPathProvisioner
    metadata:
      name: hostpath-provisioner
    spec:
      imagePullPolicy: IfNotPresent
      pathConfig:
        path: "</path/to/backing/directory>" 1
        useNamingPrefix: "false" 2
    1
    プロビジョナーが PV を作成するバッキングディレクトリーを指定します。
    2
    作成された PV にバインドされる PersistentVolumeClaim (PVC) の名前をディレクトリー名のプレフィックスとして使用する場合には、この値を true に変更します。
    注記

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

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

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

6.12.1.4. StorageClass オブジェクトの作成

StorageClass オブジェクトの作成時に、ストレージクラスに属する PersistentVolume (PV) の動的プロビジョニングに影響するパラメーターを設定します。

注記

StorageClass オブジェクトの作成後には、StorageClass オブジェクトのパラメーターを更新できません。

手順

  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 を指定して、PersistentVolumeClaim (PVC) を使用する Pod が作成されるまで PV のバインディングおよびプロビジョニングを遅延させます。これにより、PV が Pod のスケジュール要件を満たすようになります。
  3. StorageClass オブジェクトを作成します。

    $ oc create -f storageclass.yaml

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

virtctl コマンドラインユーティリティーを使用して、ローカルに保存されるディスクイメージをアップロードできます。

6.12.2.1. 前提条件

6.12.2.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*

Archive+

✓ TAR

✓ TAR

✓ TAR

□ TAR

□ TAR

✓ サポートされる操作

□ サポートされない操作

* スクラッチ領域が必要

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

+ アーカイブはブロックモード DV をサポートしません。

6.12.2.3. ローカルディスクイメージの新規 PersistentVolumeClaim へのアップロード

virtctl CLI ユーティリティーを使用し、仮想マシンディスクイメージをクライアントマシンからクラスターにアップロードできます。ディスクイメージをアップロードすることにより、仮想マシンに関連付けることのできる PersistentVolumeClaim (PVC) が作成されます。

前提条件

  • RAW、ISO、または QCOW2 形式の仮想マシンディスクイメージ (オプションで xz または gz を使用して圧縮される)
  • kubevirt-virtctl パッケージがクライアントマシンにインストールされていること。
  • クライアントマシンが OpenShift Container Platform ルーターの証明書を信頼するように設定されていること。

手順

  1. 以下を特定します。

    • アップロードする VM ディスクイメージのファイルの場所
    • 結果として生成される PVC の名前およびこれに必要なサイズ
  2. virtctl image-upload コマンドを実行して仮想マシンイメージをアップロードします。PVC 名、PVC サイズ、およびファイルの場所を指定する必要があります。以下は例になります。

    $ virtctl image-upload --pvc-name=<upload-fedora-pvc> --pvc-size=<2Gi> --image-path=</images/fedora.qcow2>
    警告

    HTTPS を使用したセキュアでないサーバー接続を許可するには、--insecure パラメーターを使用します。--insecure フラグを使用する際に、アップロードエンドポイントの信頼性は検証 されない 点に注意してください。

  3. PVC が作成されていることを確認するには、すべての PVC オブジェクトを表示します。

    $ oc get pvc

6.12.3. ブロックストレージ DataVolume へのローカルディスクイメージのアップロード

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

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

6.12.3.1. 前提条件

6.12.3.2. DataVolume について

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

6.12.3.3. ブロック PersistentVolume について

ブロック PersistentVolume (PV) は、raw ブロックデバイスによってサポートされる PV です。これらのボリュームにはファイルシステムがなく、ディスクに直接書き込む仮想マシンや、独自のストレージサービスを実装する仮想マシンにはパフォーマンス上の利点があります。

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

6.12.3.4. ローカルブロック PersistentVolume の作成

ファイルにデータを設定し、これをループデバイスとしてマウントすることにより、ノードでローカルブロック PersistentVolume (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 に StorageClass を設定します。これを省略する場合、クラスターのデフォルトが使用されます。
    4
    ブロックデバイスがマウントされたノード。
  5. ブロック PV を作成します。

    # oc create -f <local-block-pv10.yaml>1
    1
    直前の手順で作成された PersistentVolume のファイル名。

6.12.3.5. アップロード DataVolume の作成

ローカルディスクイメージのアップロードに使用する upload データソースで DataVolume を作成します。

手順

  1. spec: source: upload{} を指定する DataVolume 設定を作成します。

    apiVersion: cdi.kubevirt.io/v1alpha1
    kind: DataVolume
    metadata:
      name: <upload-datavolume> 1
    spec:
      source:
          upload: {}
      pvc:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: <2Gi> 2
    1
    DataVolume の名前
    2
    DataVolume のサイズ
  2. DataVolume を作成します。

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

6.12.3.6. ローカルディスクイメージの新規 DataVolume へのアップロード

virtctl CLI ユーティリティーを使用し、仮想マシンディスクイメージをクライアントマシンからクラスター内の DataVolume (DV) にアップロードします。イメージのアップロード後に、仮想マシンに追加できます。

前提条件

  • RAW、ISO、または QCOW2 形式の仮想マシンディスクイメージ (オプションで xz または gz を使用して圧縮される)
  • kubevirt-virtctl パッケージがクライアントマシンにインストールされていること。
  • クライアントマシンが OpenShift Container Platform ルーターの証明書を信頼するように設定されていること。
  • アップロードするディスクと同じか、これより大きいスペア DataVolume。

手順

  1. 以下を特定します。

    • アップロードする仮想マシンディスクイメージのファイルの場所
    • DataVolume の名前
  2. virtctl image-upload コマンドを実行してディスクイメージをアップロードします。DV 名とファイルの場所を指定する必要があります。以下は例になります。

    $ virtctl image-upload --dv-name=<upload-datavolume> --image-path=</images/fedora.qcow2> 1 2
    1
    作成する DataVolume の名前。
    2
    アップロードする仮想マシンディスクイメージのファイルパス。
    警告

    HTTPS を使用したセキュアでないサーバー接続を許可するには、--insecure パラメーターを使用します。--insecure フラグを使用する際に、アップロードエンドポイントの信頼性は検証 されない 点に注意してください。

  3. DV が作成されていることを確認するには、すべての DV オブジェクトを表示します。

    $ oc get dvs

6.12.3.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*

Archive+

✓ TAR

✓ TAR

✓ TAR

□ TAR

□ TAR

✓ サポートされる操作

□ サポートされない操作

* スクラッチ領域が必要

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

+ アーカイブはブロックモード DV をサポートしません。

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

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

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

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

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

注記

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

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

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

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

注記

宛先 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. 以下を参照する DataVolume マニフェストを作成します。

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

      apiVersion: cdi.kubevirt.io/v1alpha1
      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
      新規 DataVolume の名前。
      2
      ソース PVC の名前。PVC 名が分からない場合は、仮想マシン設定 spec.volumes.persistentVolumeClaim.claimName で確認できます。
      3
      ソース PVC が存在する namespace。
      4
      直前の手順で PV に追加したラベル。
      5
      宛先 PV のサイズ。
  4. DataVolume マニフェストをクラスターに適用してクローン作成の操作を開始します。

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

DataVolume は、仮想マシンの PVC のクローンを特定のノード上の PV に作成します。

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

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

6.12.5.1. DataVolume について

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

6.12.5.2. DataVolume を使用した空のディスクイメージの作成

DataVolume 設定ファイルをカスタマイズし、デプロイすることにより、新規の空のディスクイメージを PersistentVolumeClaim に作成することができます。

前提条件

  • 1 つ以上の利用可能な PersistentVolume
  • OpenShift CLI (oc) のインストール。

手順

  1. DataVolume 設定ファイルを編集します。

    apiVersion: cdi.kubevirt.io/v1alpha1
    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

6.12.5.3. テンプレート: 空のディスクイメージの DataVolume 設定ファイル

blank-image-datavolume.yaml

apiVersion: cdi.kubevirt.io/v1alpha1
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

6.12.6. DataVolume のストレージのデフォルト

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

6.12.6.1. DataVolume のストレージ設定について

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

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

注記

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

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

6.12.6.1.1. アクセスモード

DataVolume は以下のアクセスモードをサポートします。

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

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

6.12.6.1.2. ボリュームモード

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

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

6.12.6.2. Web コンソールでの kubevirt-storage-class-defaults ConfigMap の編集

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

注記

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

手順

  1. サイドメニューから、WorkloadsConfig 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 をクリックして ConfigMap を更新します。

6.12.6.3. CLI での kubevirt-storage-class-defaults ConfigMap の編集

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

注記

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

手順

  1. oc edit を使用して ConfigMap を編集します。

    $ oc edit configmap kubevirt-storage-class-defaults -n openshift-cnv
  2. ConfigMap の 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. エディターを保存し、終了して ConfigMap を更新します。

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

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

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

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

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

6.12.7.1. DataVolume について

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

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

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

CDIConfig オブジェクトにより、 scratchSpaceStorageClass を CDIConfig オブジェクトの spec: セクションに指定して、スクラッチ領域 PVC をバインドするために使用する StorageClass を定義することができます。

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

注記

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

手動プロビジョニング

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

6.12.7.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 に渡す前にイメージをスクラッチ領域にダウンロードします。

6.12.7.4. CDI 設定での StorageClass の定義

CDI 設定で StorageClass を定義し、CDI 操作のスクラッチ領域を動的にプロビジョニングします。

手順

  • oc クライアントを使用して cdiconfig/config を編集し、spec: scratchSpaceStorageClass を追加または編集してクラスターの StorageClass に一致させます。

    $ oc edit cdiconfig/config
    API Version:  cdi.kubevirt.io/v1alpha1
    kind: CDIConfig
    metadata:
      name: config
    ...
    spec:
      scratchSpaceStorageClass: "<storage_class>"
    ...

6.12.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*

Archive+

✓ TAR

✓ TAR

✓ TAR

□ TAR

□ TAR

✓ サポートされる操作

□ サポートされない操作

* スクラッチ領域が必要

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

+ アーカイブはブロックモード DV をサポートしません。

追加リソース

  • StorageClass およびこれらがクラスターで定義される方法についての詳細は、「Dynamic provisioning」セクションを参照してください。