検索

9.20. 仮想マシンディスク

download PDF

9.20.1. ストレージ機能

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

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

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

OpenShift Data Foundation: RBD ブロックモードボリューム

はい

はい

はい

はい

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

いいえ

はい

いいえ

いいえ

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

はい [1]

はい

はい [2]

はい [2]

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

いいえ

はい

はい [2]

はい [2]

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

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

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

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

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

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

OpenShift Virtualization Operator のインストール時に、Hostpath Provisioner (HPP) Operator は自動的にインストールされます。HPP は、Hostpath Provisioner Operator によって作成される OpenShift Virtualization 用に設計されたローカルストレージプロビジョナーです。HPP を使用するには、HPP カスタムリソース (CR) を作成する必要があります。

9.20.2.1. 基本ストレージ プールを使用したホストパスプロビジョナーの作成

storagePools スタンザを使用して HPP カスタムリソース (CR) を作成することにより、基本ストレージプールを使用してホストパスプロビジョナー (HPP) を設定します。ストレージプールは、CSI ドライバーが使用する名前とパスを指定します。

前提条件

  • spec.storagePools.path で指定されたディレクトリーには、読み取り/書き込みアクセス権が必要です。
  • ストレージプールは、オペレーティングシステムと同じパーティションにあってはなりません。そうしないと、オペレーティングシステムのパーティションがいっぱいになり、パフォーマンスに影響を与えたり、ノードが不安定になったり、使用できなくなったりする可能性があります。

手順

  1. 次の例のように、storagePools スタンザを含む hpp_cr.yaml ファイルを作成します。

    apiVersion: hostpathprovisioner.kubevirt.io/v1beta1
    kind: HostPathProvisioner
    metadata:
      name: hostpath-provisioner
    spec:
      imagePullPolicy: IfNotPresent
      storagePools: 1
      - name: any_name
        path: "/var/myvolumes" 2
    workload:
      nodeSelector:
        kubernetes.io/os: linux
    1
    storagePools スタンザは、複数のエントリーを追加できる配列です。
    2
    このノードパスの下にストレージプールディレクトリーを指定します。
  2. ファイルを保存して終了します。
  3. 次のコマンドを実行して HPP を作成します。

    $ oc create -f hpp_cr.yaml
9.20.2.1.1. ストレージクラスの作成について

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

ホストパスプロビジョナー (HPP) を使用するには、storagePools スタンザで CSI ドライバーの関連付けられたストレージクラスを作成する必要があります。

注記

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

この問題を解決するには、Kubernetes Pod スケジューラーを使用して、永続ボリューム要求 (PVC) を正しいノードの PV にバインドします。volumeBindingMode パラメーターが WaitForFirstConsumer に設定された StorageClass 値を使用することにより、PV のバインディングおよびプロビジョニングは、Pod が PVC を使用して作成されるまで遅延します。

9.20.2.1.2. storagePools スタンザを使用した CSI ドライバーのストレージクラスの作成

ホストパス プロビジョナー (HPP) CSI ドライバー用のストレージクラスカスタムリソース (CR) を作成します。

手順

  1. storageclass_csi.yaml ファイルを作成して、ストレージクラスを定義します。

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: hostpath-csi
    provisioner: kubevirt.io.hostpath-provisioner
    reclaimPolicy: Delete 1
    volumeBindingMode: WaitForFirstConsumer 2
    parameters:
      storagePool: my-storage-pool 3
1
reclaimPolicy には、Delete および Retain の 2 つの値があります。値を指定しない場合、デフォルト値は Delete です。
2
volumeBindingMode パラメーターは、動的プロビジョニングとボリュームのバインディングが実行されるタイミングを決定します。WaitForFirstConsumer を指定して、永続ボリューム要求 (PVC) を使用する Pod が作成されるまで PV のバインディングおよびプロビジョニングを遅延させます。これにより、PV が Pod のスケジュール要件を満たすようになります。
3
HPP CR で定義されているストレージプールの名前を指定します。
  1. ファイルを保存して終了します。
  2. 次のコマンドを実行して、StorageClass オブジェクトを作成します。

    $ oc create -f storageclass_csi.yaml

9.20.2.2. PVC テンプレートで作成されたストレージプールについて

単一の大きな永続ボリューム (PV) がある場合は、ホストパスプロビジョナー (HPP) カスタムリソース (CR) で PVC テンプレートを定義することにより、ストレージプールを作成できます。

PVC テンプレートで作成されたストレージプールには、複数の HPP ボリュームを含めることができます。PV を小さなボリュームに分割すると、データ割り当ての柔軟性が向上します。

PVC テンプレートは、PersistentVolumeClaim オブジェクトの spec スタンザに基づいています。

PersistentVolumeClaim オブジェクトの例

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: iso-pvc
spec:
  volumeMode: Block 1
  storageClassName: my-storage-class
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

1
この値は、ブロックボリュームモードの PV にのみ必要です。

HPP CR の pvcTemplate 仕様を使用してストレージプールを定義します。Operator は、HPP CSI ドライバーを含む各ノードの pvcTemplate 仕様から PVC を作成します。PVC テンプレートから作成される PVC は単一の大きな PV を消費するため、HPP は小規模な動的ボリュームを作成できます。

基本的なストレージプールを、PVC テンプレートから作成されたストレージプールと組み合わせることができます。

9.20.2.2.1. PVC テンプレートを使用したストレージプールの作成

HPP カスタムリソース (CR) で PVC テンプレートを指定することにより、複数のホストパスプロビジョナー (HPP) ボリューム用のストレージプールを作成できます。

前提条件

  • spec.storagePools.path で指定されたディレクトリーには、読み取り/書き込みアクセス権が必要です。
  • ストレージプールは、オペレーティングシステムと同じパーティションにあってはなりません。そうしないと、オペレーティングシステムのパーティションがいっぱいになり、パフォーマンスに影響を与えたり、ノードが不安定になったり、使用できなくなったりする可能性があります。

手順

  1. 次の例に従って、storagePools スタンザで永続ボリューム (PVC) テンプレートを指定する HPP CR の hpp_pvc_template_pool.yaml ファイルを作成します。

    apiVersion: hostpathprovisioner.kubevirt.io/v1beta1
    kind: HostPathProvisioner
    metadata:
      name: hostpath-provisioner
    spec:
      imagePullPolicy: IfNotPresent
      storagePools: 1
      - name: my-storage-pool
        path: "/var/myvolumes" 2
        pvcTemplate:
          volumeMode: Block 3
          storageClassName: my-storage-class 4
          accessModes:
          - ReadWriteOnce
          resources:
            requests:
              storage: 5Gi 5
      workload:
        nodeSelector:
          kubernetes.io/os: linux
    1
    storagePools スタンザは、基本ストレージプールと PVC テンプレートストレージプールの両方を含むことができるアレイです。
    2
    このノードパスの下にストレージプールディレクトリーを指定します。
    3
    オプション: volumeMode パラメーターは、プロビジョニングされたボリューム形式と一致する限り、Block または Filesystem のいずれかにすることができます。値が指定されていない場合、デフォルトは Filesystem です。volumeModeBlock の場合、Pod をマウントする前にブロックボリュームに XFS ファイルシステムが作成されます。
    4
    storageClassName パラメーターを省略すると、デフォルトのストレージクラスを使用して PVC を作成します。storageClassName を省略する場合、HPP ストレージクラスがデフォルトのストレージクラスではないことを確認してください。
    5
    静的または動的にプロビジョニングされるストレージを指定できます。いずれの場合も、要求されたストレージサイズが仮想的に分割する必要のあるボリュームに対して適切になるようにしてください。そうしないと、PVC を大規模な PV にバインドすることができません。使用しているストレージクラスが動的にプロビジョニングされるストレージを使用する場合、典型的な要求のサイズに一致する割り当てサイズを選択します。
  2. ファイルを保存して終了します。
  3. 次のコマンドを実行して、ストレージ プールを使用して HPP を作成します。

    $ oc create -f hpp_pvc_template_pool.yaml

9.20.3. データボリュームの作成

データボリュームの作成時に、Containerized Data Importer (CDI) は永続ボリューム要求 (PVC) を作成し、PVC にデータを入力します。データボリュームは、スタンドアロンリソースとして、または仮想マシン仕様で dataVolumeTemplate リソースを使用することで、作成できます。PVC API またはストレージ API のいずれかを使用して、データボリュームを作成します。

重要

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

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

ヒント

可能な限り、ストレージ API を使用して、スペースの割り当てを最適化し、パフォーマンスを最大化します。

ストレージプロファイル は、CDI が管理するカスタムリソースです。関連付けられたストレージクラスに基づく推奨ストレージ設定を提供します。ストレージクラスごとにストレージクラスが割り当てられます。

ストレージプロファイルを使用すると、コーディングを減らし、潜在的なエラーを最小限に抑えながら、データボリュームをすばやく作成できます。

認識されたストレージタイプの場合、CDI は PVC の作成を最適化する値を提供します。ただし、ストレージプロファイルをカスタマイズする場合は、ストレージクラスの自動設定を行うことができます。

9.20.3.1. ストレージ API を使用したデータボリュームの作成

ストレージ API を使用してデータボリュームを作成する場合、Containerized Data Interface (CDI) は、選択したストレージクラスでサポートされるストレージのタイプに基づいて、永続ボリューム要求 (PVC) の割り当てを最適化します。データボリューム名、namespace、および割り当てるストレージの量のみを指定する必要があります。

以下に例を示します。

  • Ceph RBD を使用する場合、accessModesReadWriteMany に自動設定され、ライブマイグレーションが可能になります。volumeMode は、パフォーマンスを最大化するために Block に設定されています。
  • volumeMode: Filesystem を使用する場合、ファイルシステムのオーバーヘッドに対応する必要がある場合は、CDI が追加の領域を自動的に要求します。

以下の YAML では、ストレージ API を使用して、2 ギガバイトの使用可能な領域を持つデータボリュームを要求します。ユーザーは、必要な永続ボリューム要求 (PVC) のサイズを適切に予測するために volumeMode を把握する必要はありません。CDI は accessModes 属性と volumeMode 属性の最適な組み合わせを自動的に選択します。これらの最適値は、ストレージのタイプまたはストレージプロファイルで定義するデフォルトに基づいています。カスタム値を指定する場合は、システムで計算された値を上書きします。

DataVolume 定義の例

apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
  name: <datavolume> 1
spec:
  source:
    pvc: 2
      namespace: "<source_namespace>" 3
      name: "<my_vm_disk>" 4
  storage: 5
    resources:
      requests:
        storage: 2Gi 6
    storageClassName: <storage_class> 7

1
新規データボリュームの名前。
2
インポートのソースが既存の永続ボリューム要求 (PVC) であることを示しています。
3
ソース PVC が存在する namespace。
4
ソース PVC の名前。
5
ストレージ API を使用した割り当てを示します。
6
PVC に要求する利用可能な領域のサイズを指定します。
7
オプション: ストレージクラスの名前。ストレージクラスが指定されていない場合、システムデフォルトのストレージクラスが使用されます。

9.20.3.2. PVC API を使用したデータボリュームの作成

PVC API を使用してデータボリュームを作成する場合、Containerized Data Interface (CDI) は、以下のフィールドに指定する内容に基づいてデータボリュームを作成します。

  • accessModes (ReadWriteOnceReadWrtieMany、または ReadOnlyMany)
  • volumeMode (Filesystem または Block)
  • storagecapacity (例: 5Gi)

以下の YAML では、PVC API を使用して、2 ギガバイトのストレージ容量を持つデータボリュームを割り当てます。ReadWriteMany のアクセスモードを指定して、ライブマイグレーションを有効にします。システムがサポートできる値がわかっているので、デフォルトの Filesystem の代わりに Block ストレージを指定します。

DataVolume 定義の例

apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
  name: <datavolume> 1
spec:
  source:
    pvc: 2
      namespace: "<source_namespace>" 3
      name: "<my_vm_disk>" 4
  pvc: 5
    accessModes: 6
      - ReadWriteMany
    resources:
      requests:
        storage: 2Gi 7
    volumeMode: Block 8
    storageClassName: <storage_class> 9

1
新規データボリュームの名前。
2
source セクションでは、pvc はインポートのソースが既存の永続ボリューム要求 (PVC) であることを示しています。
3
ソース PVC が存在する namespace。
4
ソース PVC の名前。
5
PVC API を使用した割り当てを示します。
6
PVC API を使用する場合は accessModes が必要です。
7
データボリュームに要求する領域のサイズを指定します。
8
宛先がブロック PVC であることを指定します。
9
オプションで、ストレージクラスを指定します。ストレージクラスが指定されていない場合、システムデフォルトのストレージクラスが使用されます。
重要

PVC API を使用してデータボリュームを明示的に割り当て、volumeMode: Block を使用していない場合は、ファイルシステムのオーバーヘッドを考慮してください。

ファイルシステムのオーバーヘッドは、ファイルシステムのメタデータを維持するために必要な領域のサイズです。ファイルシステムメタデータに必要な領域のサイズは、ファイルシステムに依存します。ストレージ容量要求でファイルシステムのオーバーヘッドに対応できない場合は、基礎となる永続ボリューム要求 (PVC) が仮想マシンディスクに十分に対応できない大きさとなる可能性があります。

ストレージ API を使用する場合、CDI はファイルシステムのオーバーヘッドを考慮し、割り当て要求が正常に実行されるように大きな永続ボリューム要求 (PVC) を要求します。

9.20.3.3. ストレージプロファイルのカスタマイズ

プロビジョナーのストレージクラスの StorageProfile オブジェクトを編集してデフォルトパラメーターを指定できます。これらのデフォルトパラメーターは、DataVolume オブジェクトで設定されていない場合にのみ永続ボリューム要求 (PVC) に適用されます。

前提条件

  • 計画した設定がストレージクラスとそのプロバイダーでサポートされていることを確認してください。ストレージプロファイルに互換性のない設定を指定すると、ボリュームのプロビジョニングに失敗します。
注記

ストレージプロファイルの空の status セクションは、ストレージプロビジョナーが Containerized Data Interface (CDI) によって認識されないことを示します。CDI で認識されないストレージプロビジョナーがある場合、ストレージプロファイルをカスタマイズする必要があります。この場合、管理者はストレージプロファイルに適切な値を設定し、割り当てが正常に実行されるようにします。

警告

データボリュームを作成し、YAML 属性を省略し、これらの属性がストレージプロファイルで定義されていない場合は、要求されたストレージは割り当てられず、基礎となる永続ボリューム要求 (PVC) は作成されません。

手順

  1. ストレージプロファイルを編集します。この例では、プロビジョナーは CDI によって認識されません。

    $ oc edit -n openshift-cnv storageprofile <storage_class>

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

    apiVersion: cdi.kubevirt.io/v1beta1
    kind: StorageProfile
    metadata:
      name: <unknown_provisioner_class>
    #   ...
    spec: {}
    status:
      provisioner: <unknown_provisioner>
      storageClass: <unknown_provisioner_class>

  2. ストレージプロファイルに必要な属性値を指定します。

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

    apiVersion: cdi.kubevirt.io/v1beta1
    kind: StorageProfile
    metadata:
      name: <unknown_provisioner_class>
    #   ...
    spec:
      claimPropertySets:
      - accessModes:
        - ReadWriteOnce 1
        volumeMode:
          Filesystem 2
    status:
      provisioner: <unknown_provisioner>
      storageClass: <unknown_provisioner_class>

    1
    選択する accessModes
    2
    選択する volumeMode

    変更を保存した後、選択した値がストレージプロファイルの status 要素に表示されます。

9.20.3.3.1. ストレージプロファイルを使用したデフォルトのクローンストラテジーの設定

ストレージプロファイルを使用してストレージクラスのデフォルトクローンメソッドを設定し、クローンストラテジー を作成できます。ストレージベンダーが特定のクローン作成方法のみをサポートする場合などに、クローンストラテジーを設定すると便利です。また、リソースの使用の制限やパフォーマンスの最大化を実現する手法を選択することもできます。

クローン作成ストラテジーは、ストレージプロファイルの cloneStrategy 属性を以下の値のいずれかに設定して指定できます。

  • snapshot: この方法は、スナップショットが設定されている場合にデフォルトで使用されます。このクローン作成ストラテジーは、一時的なボリュームスナップショットを使用してボリュームのクローンを作成します。ストレージプロビジョナーは CSI スナップショットをサポートする必要があります。
  • Copy: この方法では、ソース Pod およびターゲット Pod を使用して、ソースボリュームからターゲットボリュームにデータをコピーします。ホスト支援型でのクローン作成は、最も効率的な方法です。
  • csi-clone: この方法は、CSI クローン API を使用して、中間ボリュームスナップショットを使用せずに既存ボリュームのクローンを効率的に作成します。ストレージプロファイルが定義されていない場合にデフォルトで使用される snapshot または copy とは異なり、CSI ボリュームのクローンは、プロビジョナーのストレージクラスの StorageProfile オブジェクトに指定した場合にだけ使用されます。
注記

YAML spec セクションのデフォルトの claimPropertySets を変更せずに、CLI でクローンストラテジーを設定することもできます。

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

apiVersion: cdi.kubevirt.io/v1beta1
kind: StorageProfile
metadata:
  name: <provisioner_class>
#   ...
spec:
  claimPropertySets:
  - accessModes:
    - ReadWriteOnce 1
    volumeMode:
      Filesystem 2
  cloneStrategy:
  csi-clone 3
status:
  provisioner: <provisioner>
  storageClass: <provisioner_class>

1
選択する accessModes
2
選択する volumeMode
3
選択するデフォルトのクローン作成方法。この例では、CSI ボリュームのクローン作成が指定されています。

9.20.3.4. 関連情報

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

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

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

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

  • 仮想マシンディスク。
  • メタデータなどのファイルシステムオーバーヘッド用に予約された領域

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

HCO オブジェクトを編集して、別のオーバーヘッド値を設定できます。値はグローバルに変更でき、特定のストレージクラスの値を指定できます。

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

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

前提条件

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

手順

  1. 次のコマンドを実行して、HCO オブジェクトを編集用に開きます。

    $ oc edit hco -n openshift-cnv kubevirt-hyperconverged
  2. spec.filesystemOverhead フィールドを編集して、選択した値でデータを設定します。

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

検証

  • 次のいずれかのコマンドを実行して、CDIConfig ステータスを表示し、変更を確認します。

    一般的に CDIConfig への変更を確認するには以下を実行します。

    $ oc get cdiconfig -o yaml

    CDIConfig に対する 特定の変更を表示するには以下を実行します。

    $ oc get cdiconfig -o jsonpath='{.items..status.filesystemOverhead}'

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

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

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

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

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

9.20.5.2. CPU およびメモリーのデフォルトの上書き

HyperConverged カスタムリソース (CR) に spec.resourceRequirements.storageWorkloads スタンザを追加して、CPU およびメモリー要求のデフォルト設定とユースケースの制限を変更します。

前提条件

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

手順

  1. 以下のコマンドを実行して、HyperConverged CR を編集します。

    $ oc edit hco -n openshift-cnv kubevirt-hyperconverged
  2. spec.resourceRequirements.storageWorkloads スタンザを CR に追加し、ユースケースに基づいて値を設定します。以下に例を示します。

    apiVersion: hco.kubevirt.io/v1beta1
    kind: HyperConverged
    metadata:
      name: kubevirt-hyperconverged
    spec:
      resourceRequirements:
        storageWorkloads:
          limits:
            cpu: "500m"
            memory: "2Gi"
          requests:
            cpu: "250m"
            memory: "1Gi"
  3. エディターを保存して終了し、HyperConverged CR を更新します。

9.20.5.3. 関連情報

9.20.6. データボリュームアノテーションの管理

データボリューム (DV) アノテーションを使用して Pod の動作を管理できます。1 つ以上のアノテーションをデータボリュームに追加してから、作成されたインポーター Pod に伝播できます。

9.20.6.1. 例: データボリュームアノテーション

以下の例は、インポーター Pod が使用するネットワークを制御するためにデータボリューム (DV) アノテーションを設定する方法を示しています。v1.multus-cni.io/default-network: bridge-network アノテーションにより、Pod は bridge-network という名前の multus ネットワークをデフォルトネットワークとして使用します。インポーター Pod にクラスターからのデフォルトネットワークとセカンダリー multus ネットワークの両方を使用させる必要がある場合は、k8s.v1.cni.cncf.io/networks: <network_name> アノテーションを使用します。

Multus ネットワークアノテーションの例

apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
  name: dv-ann
  annotations:
      v1.multus-cni.io/default-network: bridge-network 1
spec:
  source:
      http:
         url: "example.exampleurl.com"
  pvc:
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: 1Gi

1
Multus ネットワークアノテーション

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

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

特定のデータボリュームの事前割り当てを有効にできます。

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

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

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

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

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

データボリュームマニフェストに spec.preallocation フィールドを含めることにより、特定のデータボリュームの事前割り当てを有効にできます。Web コンソールで、または OpenShift CLI (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 に設定されるブール値です。

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

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

9.20.8.1. 前提条件

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

✓ サポートされる操作

□ サポートされない操作

* スクラッチ領域が必要

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

9.20.8.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 をクリックします。

9.20.8.4. 関連情報

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

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

9.20.9.1. 前提条件

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

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

9.20.9.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

9.20.9.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

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

✓ サポートされる操作

□ サポートされない操作

* スクラッチ領域が必要

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

9.20.9.6. 関連情報

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

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

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

9.20.10.1. 前提条件

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

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

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

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

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

9.20.10.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
    直前の手順で作成された永続ボリュームのファイル名。

9.20.10.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

9.20.10.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

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

✓ サポートされる操作

□ サポートされない操作

* スクラッチ領域が必要

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

9.20.10.8. 関連情報

9.20.11. 仮想マシンスナップショットの管理

仮想マシンの電源がオフ (オフライン) またはオン (オンライン) であるかに拘らず、仮想マシンの仮想マシン (VM) スナップショットを作成および削除できます。電源オフ (オフライン) 状態の仮想マシンに対してのみ復元が可能です。OpenShift Virtualization は、以下にある仮想マシンのスナップショットをサポートします。

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

オンラインスナップショットのデフォルト期限は 5 分 (5m) で、必要に応じて変更できます。

重要

オンラインスナップショットは、ホットプラグされた仮想ディスクを持つ仮想マシンでサポートされます。ただし、仮想マシンの仕様に含まれていないホットプラグされたディスクは、スナップショットに含まれません。

注記

整合性が最も高いオンライン (実行状態) の仮想マシンのスナップショットを作成するには、QEMU ゲストエージェントをインストールします。

QEMU ゲストエージェントは、システムのワークロードに応じて、可能な限り仮想マシンのファイルシステムの休止しようとすることで一貫性のあるスナップショットを取得します。これにより、スナップショットの作成前にインフライトの I/O がディスクに書き込まれるようになります。ゲストエージェントが存在しない場合は、休止はできず、ベストエフォートスナップショットが作成されます。スナップショットの作成条件は、Web コンソールまたは CLI に表示されるスナップショットの指示に反映されます。

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

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

仮想マシンのスナップショットは、電源がオフ (停止状態) またはオン (実行状態) の仮想マシンから作成されます。

実行中の仮想マシンのスナップショットを作成する場合には、コントローラーは QEMU ゲストエージェントがインストールされ、実行中であることを確認します。そのような場合には、スナップショットの作成前に仮想マシンファイルシステムをフリーズして、スナップショットの作成後にファイルシステムをロールアウトします。

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

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

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

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

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

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

9.20.11.2. QEMU ゲストエージェントの Linux 仮想マシンへのインストール

qemu-guest-agent は広く利用されており、Red Hat 仮想マシンでデフォルトで利用できます。このエージェントをインストールし、サービスを起動します。

仮想マシン (VM) に QEMU ゲストエージェントがインストールされ、実行されているかどうかを確認するには、AgentConnected が VM 仕様に表示されていることを確認します。

注記

整合性が最も高いオンライン (実行状態) の仮想マシンのスナップショットを作成するには、QEMU ゲストエージェントをインストールします。

QEMU ゲストエージェントは、システムのワークロードに応じて、可能な限り仮想マシンのファイルシステムの休止しようとすることで一貫性のあるスナップショットを取得します。これにより、スナップショットの作成前にインフライトの I/O がディスクに書き込まれるようになります。ゲストエージェントが存在しない場合は、休止はできず、ベストエフォートスナップショットが作成されます。スナップショットの作成条件は、Web コンソールまたは CLI に表示されるスナップショットの指示に反映されます。

手順

  1. コンソールのいずれか、SSH を使用して仮想マシンのコマンドラインにアクセスします。
  2. QEMU ゲストエージェントを仮想マシンにインストールします。

    $ yum install -y qemu-guest-agent
  3. サービスに永続性があることを確認し、これを起動します。

    $ systemctl enable --now qemu-guest-agent

9.20.11.3. QEMU ゲストエージェントの Windows 仮想マシンへのインストール

Windows 仮想マシンの場合には、QEMU ゲストエージェントは VirtIO ドライバーに含まれます。既存または新規の Windows インストールにドライバーをインストールします。

仮想マシン (VM) に QEMU ゲストエージェントがインストールされ、実行されているかどうかを確認するには、AgentConnected が VM 仕様に表示されていることを確認します。

注記

整合性が最も高いオンライン (実行状態) の仮想マシンのスナップショットを作成するには、QEMU ゲストエージェントをインストールします。

QEMU ゲストエージェントは、システムのワークロードに応じて、可能な限り仮想マシンのファイルシステムの休止しようとすることで一貫性のあるスナップショットを取得します。これにより、スナップショットの作成前にインフライトの I/O がディスクに書き込まれるようになります。ゲストエージェントが存在しない場合は、休止はできず、ベストエフォートスナップショットが作成されます。スナップショットの作成条件は、Web コンソールまたは CLI に表示されるスナップショットの指示に反映されます。

9.20.11.3.1. VirtIO ドライバーの既存 Windows 仮想マシンへのインストール

VirtIO ドライバーを、割り当てられた SATA CD ドライブから既存の Windows 仮想マシンにインストールします。

注記

この手順では、ドライバーを Windows に追加するための汎用的なアプローチを使用しています。このプロセスは Windows のバージョンごとに若干異なる可能性があります。特定のインストール手順については、お使いの Windows バージョンについてのインストールドキュメントを参照してください。

手順

  1. 仮想マシンを起動し、グラフィカルコンソールに接続します。
  2. Windows ユーザーセッションにログインします。
  3. Device Manager を開き、Other devices を拡張して、Unknown device をリスト表示します。

    1. Device Properties を開いて、不明なデバイスを特定します。デバイスを右クリックし、Properties を選択します。
    2. Details タブをクリックし、Property リストで Hardware Ids を選択します。
    3. Hardware IdsValue をサポートされる VirtIO ドライバーと比較します。
  4. デバイスを右クリックし、Update Driver Software を選択します。
  5. Browse my computer for driver software をクリックし、VirtIO ドライバーが置かれている割り当て済みの SATA CD ドライブの場所に移動します。ドライバーは、ドライバーのタイプ、オペレーティングシステム、および CPU アーキテクチャー別に階層的に編成されます。
  6. Next をクリックしてドライバーをインストールします。
  7. 必要なすべての VirtIO ドライバーに対してこのプロセスを繰り返します。
  8. ドライバーのインストール後に、Close をクリックしてウィンドウを閉じます。
  9. 仮想マシンを再起動してドライバーのインストールを完了します。
9.20.11.3.2. Windows インストール時の VirtIO ドライバーのインストール

Windows のインストール時に割り当てられた SATA CD ドライバーから VirtIO ドライバーをインストールします。

注記

この手順では、Windows インストールの汎用的なアプローチを使用しますが、インストール方法は Windows のバージョンごとに異なる可能性があります。インストールする Windows のバージョンについてのドキュメントを参照してください。

手順

  1. 仮想マシンを起動し、グラフィカルコンソールに接続します。
  2. Windows インストールプロセスを開始します。
  3. Advanced インストールを選択します。
  4. ストレージの宛先は、ドライバーがロードされるまで認識されません。Load driver をクリックします。
  5. ドライバーは SATA CD ドライブとして割り当てられます。OK をクリックし、CD ドライバーでロードするストレージドライバーを参照します。ドライバーは、ドライバーのタイプ、オペレーティングシステム、および CPU アーキテクチャー別に階層的に編成されます。
  6. 必要なすべてのドライバーについて直前の 2 つの手順を繰り返します。
  7. Windows インストールを完了します。

9.20.11.4. Web コンソールでの仮想マシンのスナップショットの作成

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

注記

整合性が最も高いオンライン (実行状態) の仮想マシンのスナップショットを作成するには、QEMU ゲストエージェントをインストールします。

QEMU ゲストエージェントは、システムのワークロードに応じて、可能な限り仮想マシンのファイルシステムの休止しようとすることで一貫性のあるスナップショットを取得します。これにより、スナップショットの作成前にインフライトの I/O がディスクに書き込まれるようになります。ゲストエージェントが存在しない場合は、休止はできず、ベストエフォートスナップショットが作成されます。スナップショットの作成条件は、Web コンソールまたは CLI に表示されるスナップショットの指示に反映されます。

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

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

手順

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

9.20.11.5. CLI での仮想マシンのスナップショットの作成

VirtualMachineSnapshot オブジェクトを作成し、オフラインまたはオンラインの仮想マシンの仮想マシン (VM) スナップショットを作成できます。KubeVirt は QEMU ゲストエージェントと連携し、オンライン仮想マシンのスナップショットを作成します。

注記

整合性が最も高いオンライン (実行状態) の仮想マシンのスナップショットを作成するには、QEMU ゲストエージェントをインストールします。

QEMU ゲストエージェントは、システムのワークロードに応じて、可能な限り仮想マシンのファイルシステムの休止しようとすることで一貫性のあるスナップショットを取得します。これにより、スナップショットの作成前にインフライトの I/O がディスクに書き込まれるようになります。ゲストエージェントが存在しない場合は、休止はできず、ベストエフォートスナップショットが作成されます。スナップショットの作成条件は、Web コンソールまたは CLI に表示されるスナップショットの指示に反映されます。

前提条件

  • 永続ボリューム要求 (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
  3. オプション: オンラインスナップショットを作成している場合は、wait コマンドを使用して、スナップショットのステータスを監視できます。

    1. 以下のコマンドを入力します。

      $ oc wait my-vm my-vmsnapshot --for condition=Ready
    2. スナップショットのステータスを確認します。

      • InProgress: オンラインスナップショットの操作が進行中です。
      • Succeeded: オンラインスナップショット操作が正常に完了しました。
      • Failed: オンラインスナップショットの操作に失敗しました。

        注記

        オンラインスナップショットのデフォルト期限は 5 分 (5m) です。スナップショットが 5 分後に正常に完了しない場合には、ステータスが failed に設定されます。その後、ファイルシステムと仮想マシンのフリーズが解除され、失敗したスナップショットイメージが削除されるまで、ステータスは failed のままになります。

        デフォルトの期限を変更するには、仮想マシンスナップショット仕様に FailureDeadline 属性を追加して、スナップショット操作がタイムアウトするまでの時間を分単位 (m) または秒単位 (s) で指定します。

        期限を指定しない場合は、0 を指定できますが、仮想マシンが応答しなくなる可能性があるため、通常は推奨していません。

        m または sなどの時間の単位を指定しない場合、デフォルトは秒 (s) です。

検証

  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 がスナップショットに含まれることを確認します。

9.20.11.6. スナップショット指示を使用したオンラインスナップショット作成の確認

スナップショットの表示は、オンライン仮想マシン (VM) スナップショット操作に関するコンテキスト情報です。オフラインの仮想マシン (VM) スナップショット操作では、指示は利用できません。イベントは、オンラインスナップショット作成の詳説する際に役立ちます。

前提条件

  • 指示を表示するには、CLI または Web コンソールを使用してオンライン仮想マシンスナップショットの作成を試行する必要があります。

手順

  1. 以下のいずれかを実行して、スナップショット指示からの出力を表示します。

    • CLI で作成されたスナップショットの場合には、status フィールドの VirtualMachineSnapshot オブジェクト YAML にあるインジケーターの出力を確認します。
    • Web コンソールを使用して作成されたスナップショットの場合には、Snapshot details 画面で VirtualMachineSnapshot > Status をクリックします。
  2. オンライン仮想マシンのスナップショットのステータスを確認します。

    • Online は、仮想マシンがオンラインスナップショットの作成時に実行されていることを示します。
    • NoGuestAgent は、QEMU ゲストエージェントがオンラインのスナップショットの作成時に実行されていないことを示します。QEMU ゲストエージェントがインストールされていないか、実行されていないか、別のエラーが原因で、QEMU ゲストエージェントを使用してファイルシステムをフリーズしてフリーズを解除できませんでした。

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

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

手順

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

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

9.20.11.8. 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/v1
      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 フィールドは、仮想マシンの復元プロセスが完了しているかどうかを指定します。

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

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

手順

  1. サイドメニューから Virtualization VirtualMachines をクリックします。
  2. 仮想マシンを選択して、VirtualMachine details ページを開きます。
  3. Snapshots タブをクリックします。このページには、仮想マシンに関連付けられたスナップショットの一覧が表示されます。
  4. 削除する仮想マシンスナップショットの Options メニュー kebab をクリックして、Delete VirtualMachineSnapshot を選択します。
  5. 確認のポップアップウィンドウで、Delete をクリックしてスナップショットを削除します。

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

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

前提条件

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

手順

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

    $ oc delete vmsnapshot <my-vmsnapshot>

検証

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

    $ oc get vmsnapshot

9.20.11.11. 関連情報

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

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

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

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

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

ヒント

事前割り当てをグローバルに有効にする場合や、単一データボリュームについて、Containerized Data Importer (CDI) はクローン時にディスク領域を事前に割り当てます。事前割り当てにより、書き込みパフォーマンスが向上します。詳細は、データボリュームについての事前割り当ての使用 について参照してください。

注記

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

9.20.12.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 に作成します。

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

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

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

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

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

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

前提条件

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

手順

  1. DataVolume マニフェストを編集します。

    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

9.20.13.3. 関連情報

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

スマートクローニングは、Red Hat OpenShift Data Foundation の組み込み機能です。スマートクローニングは、ホストアシストクローニングよりも高速で効率的です。

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

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

9.20.14.1. smart-cloning について

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

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

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

前提条件

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

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

手順

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

  1. 新規データボリュームの名前およびソース PVC の名前と namespace 指定する DataVolume オブジェクトの YAML ファイルを作成します。この例では、ストレージ API を指定しているため、accessModes または volumeMode を指定する必要はありません。最適な値は、自動的に計算されます。

    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
      storage: 4
        resources:
          requests:
            storage: <2Gi> 5
    1
    新規データボリュームの名前。
    2
    ソース PVC が存在する namespace。
    3
    ソース PVC の名前。
    4
    ストレージ API を使用して割り当てを指定します。
    5
    新規データボリュームのサイズ。
  2. データボリュームを作成して PVC のクローン作成を開始します。

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

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

9.20.14.3. 関連情報

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

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

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

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

9.20.15.1. 仮想マシンおよびブートソースについて

仮想マシンは、仮想マシン定義と、データボリュームでサポートされる 1 つ以上のディスクで設定されます。仮想マシンテンプレートを使用すると、事前定義された仮想マシン仕様を使用して仮想マシンを作成できます。

すべての仮想マシンテンプレートには、設定されたドライバーを含む完全に設定された仮想マシンディスクイメージであるブートソースが必要です。それぞれの仮想マシンテンプレートには、ブートソースへのポインターを含む仮想マシン定義が含まれます。各ブートソースには、事前に定義された名前および namespace があります。オペレーティングシステムによっては、ブートソースは自動的に提供されます。これが提供されない場合、管理者はカスタムブートソースを準備する必要があります。

提供されたブート ソースは、オペレーティングシステムの最新バージョンに自動的に更新されます。自動更新されたブートソースの場合、クラスターのデフォルトのストレージクラスを使用して、永続ボリューム要求 (PVC) が作成されます。設定後に別のデフォルトのストレージクラスを選択した場合は、以前のデフォルトのストレージクラスで設定されたクラスター namespace 内の既存のデータボリュームを削除する必要があります。

ブートソース機能を使用するには、OpenShift Virtualization の最新リリースをインストールします。namespace の openshift-virtualization-os-images はこの機能を有効にし、OpenShift Virtualization Operator でインストールされます。ブートソース機能をインストールしたら、ブートソースを作成してそれらをテンプレートに割り当て、テンプレートから仮想マシンを作成できます。

ローカルファイルのアップロード、既存 PVC のクローン作成、レジストリーからのインポート、または URL を使用して設定される永続ボリューム要求 (PVC) を使用してブートソースを定義します。Web コンソールを使用して、ブートソースを仮想マシンテンプレートに割り当てます。ブートソースが仮想マシンテンプレートに割り当てられた後に、テンプレートを使用して任意の数の完全に設定済みの準備状態の仮想マシンを作成できます。

9.20.15.2. RHEL イメージをブート ソースとしてインポートする

イメージの URL を指定して、Red Hat Enterprise Linux (RHEL) イメージをブートソースとしてインポートできます。

前提条件

  • オペレーティングシステムイメージを含む Web ページにアクセスできる必要があります。例: イメージを含む Red Hat Enterprise Linux Web ページをダウンロードします。

手順

  1. OpenShift Container Platform コンソールで、サイドメニューから Virtualization Templates をクリックします。
  2. ブートソースを設定する必要のある仮想マシンテンプレートを特定し、Add source をクリックします。
  3. Add boot source to template ウィンドウで、Boot source type リストから URL (creates PVC) を選択します。
  4. RHEL download page をクリックして Red Hat カスタマーポータルにアクセスします。利用可能なインストーラーおよびイメージのリストは、Red Hat Enterprise Linux のダウンロードページに表示されます。
  5. ダウンロードする Red Hat Enterprise Linux KVM ゲストイメージを特定します。Download Now を右クリックして、イメージの URL をコピーします。
  6. Add boot source to template ウィンドウで、URL を Import URL フィールドに貼り付け、Save and import をクリックします。

検証

  1. テンプレートの テンプレート ページの ブートソース 列に緑色のチェックマークが表示されていることを確認します。

このテンプレートを使用して RHEL 仮想マシンを作成できます。

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

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

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

  • ローカルファイルのアップロード (PVC の作成)
  • URL (PVC を作成)
  • クローン (PVC を作成)
  • レジストリー (PVC を作成)

前提条件

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

手順

  1. OpenShift Container Platform コンソールで、サイドメニューから Virtualization Templates をクリックします。
  2. テンプレートの横にある Options メニューをクリックし、Edit boot source を選択します。
  3. ディスクの追加をクリックします。
  4. Add disk ウィンドウで、Use this disk as a boot source を選択します。
  5. ディスク名を入力し、Source を選択します。たとえば、Blank (creates PVC) または Use an existing PVC を選択します。
  6. Persistent Volume Claim size の値を入力し、圧縮解除されたイメージおよび必要な追加の領域に十分な PVC サイズを指定します。
  7. Type を選択します (Disk または CD-ROM など)。
  8. オプション: Storage class をクリックし、ディスクを作成するために使用されるストレージクラスを選択します。通常、このストレージクラスはすべての PVC で使用するために作成されるデフォルトのストレージクラスです。

    注記

    提供されたブート ソースは、オペレーティングシステムの最新バージョンに自動的に更新されます。自動更新されたブートソースの場合、クラスターのデフォルトのストレージクラスを使用して、永続ボリューム要求 (PVC) が作成されます。設定後に別のデフォルトのストレージクラスを選択した場合は、以前のデフォルトのストレージクラスで設定されたクラスター namespace 内の既存のデータボリュームを削除する必要があります。

  9. オプション: Apply optimized StorageProfile settings をオフにして、アクセスモードまたはボリュームモードを編集します。
  10. ブートソースを保存する適切な方法を選択します。

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

ブートソースを含むカスタム仮想マシンテンプレートが Catalog ページにリスト表示されています。このテンプレートを使用して仮想マシンを作成できます。

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

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

手順

  1. Open Shift Container Platform Web コンソールのサイドメニューで、Virtualization Catalog をクリックします。
  2. 更新されたテンプレートを選択し、Quick create VirtualMachine をクリックします。

VirtualMachine details が、Starting のステータスで表示されます。

9.20.15.5. 関連情報

9.20.16. 仮想ディスクのホットプラグ

仮想マシン (VM) または仮想マシンインスタンス (VMI) を停止することなく、仮想ディスクを追加または削除できます。

9.20.16.1. 仮想ディスクのホットプラグについて

仮想ディスクを ホットプラグ すると、仮想マシンの実行中に仮想ディスクを仮想マシンインスタンスに割り当てることができます。

仮想ディスクを ホットアンプラグ すると、仮想マシンの実行中に仮想ディスクの割り当てを仮想マシンインスタンスから解除できます。

データボリュームおよび永続ボリューム要求 (PVC) のみをホットプラグおよびホットアンプラグできます。コンテナーディスクのホットプラグおよびホットアンプラグはできません。

仮想ディスクをホットプラグした後は、仮想マシンを再起動しても、解除するまで接続されたままになります。

9.20.16.2. virtio-scsi について

OpenShift Virtualization では、ホットプラグされたディスクが SCSI バスを使用できるように、各仮想マシン (VM) に virtio-scsi コントローラーがあります。virtio-scsi コントローラーは、パフォーマンス上の利点を維持しながら、virtio の制限を克服します。スケーラビリティが高く、400 万台を超えるディスクのホットプラグをサポートします。

通常の virtio は、スケーラブルではないため、ホットプラグされたディスクでは使用できません。各 virtio ディスクは、VM 内の制限された PCI Express (PCIe) スロットの 1 つを使用します。PCIe スロットは他のデバイスでも使用され、事前に予約する必要があるため、オンデマンドでスロットを利用できない場合があります。

9.20.16.3. CLI を使用した仮想ディスクのホットプラグ

仮想マシンの実行中に仮想マシンインスタンス (VMI) に割り当てる必要のある仮想ディスクをホットプラグします。

前提条件

  • 仮想ディスクをホットプラグするために実行中の仮想マシンが必要です。
  • ホットプラグ用に 1 つ以上のデータボリュームまたは永続ボリューム要求 (PVC) が利用可能である必要があります。

手順

  • 以下のコマンドを実行して、仮想ディスクをホットプラグします。

    $ virtctl addvolume <virtual-machine|virtual-machine-instance> --volume-name=<datavolume|PVC> \
    [--persist] [--serial=<label-name>]
    • オプションの --persist フラグを使用して、ホットプラグされたディスクを、永続的にマウントされた仮想ディスクとして仮想マシン仕様に追加します。仮想ディスクを永続的にマウントするために、仮想マシンを停止、再開または再起動します。--persist フラグを指定しても、仮想ディスクをホットプラグしたり、ホットアンプラグしたりできなくなります。--persist フラグは仮想マシンに適用され、仮想マシンインスタンスには適用されません。
    • オプションの --serial フラグを使用すると、選択した英数字の文字列ラベルを追加できます。これは、ゲスト仮想マシンでホットプラグされたディスクを特定するのに役立ちます。このオプションを指定しない場合、ラベルはデフォルトでホットプラグされたデータボリュームまたは PVC の名前に設定されます。

9.20.16.4. CLI を使用した仮想ディスクのホットアンプラグ

仮想マシンの実行中に仮想マシンインスタンス (VMI) から割り当てを解除する必要のある仮想ディスクをホットアンプラグします。

前提条件

  • 仮想マシンが実行中である必要があります。
  • 1 つ以上のデータボリュームまたは永続ボリューム要求 (PVC) が利用可能であり、ホットプラグされている必要があります。

手順

  • 以下のコマンドを実行して、仮想ディスクをホットアンプラグします。

    $ virtctl removevolume <virtual-machine|virtual-machine-instance> --volume-name=<datavolume|PVC>

9.20.16.5. Web コンソールを使用した仮想ディスクのホットプラグ

仮想マシンの実行中に仮想マシンインスタンス (VMI) に割り当てる必要のある仮想ディスクをホットプラグします。仮想ディスクをホットプラグすると、ホットアンプラグするまで VMI に接続されたままになります。

前提条件

  • 仮想ディスクをホットプラグするために実行中の仮想マシンが必要です。

手順

  1. サイドメニューから Virtualization VirtualMachines をクリックします。
  2. 仮想ディスクをホットプラグする実行中の仮想マシンを選択します。
  3. VirtualMachine details ページで、Disks タブをクリックします。
  4. ディスクの追加をクリックします。
  5. Add disk (hot plugged) ウィンドウで、ホットプラグする仮想ディスクの情報を入力します。
  6. Save をクリックします。

9.20.16.6. Web コンソールを使用した仮想ディスクのホットアンプラグ

仮想マシンの実行中に仮想マシンインスタンス (VMI) から割り当てを解除する必要のある仮想ディスクをホットアンプラグします。

前提条件

  • 仮想マシンが実行中で、ホットプラグされたディスクが接続されている必要があります。

手順

  1. サイドメニューから Virtualization VirtualMachines をクリックします。
  2. ホットアンプラグするディスクを含む実行中の仮想マシンを選択して、VirtualMachine details ページを開きます。
  3. Disks タブで、ホットアンプラグする仮想ディスクの Options メニュー kebab をクリックします。
  4. Detach をクリックします。

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

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

重要

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

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

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

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

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

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

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

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

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

重要

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

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

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

HyperConverged カスタムリソースの insecureRegistries フィールドを編集して、1 つ以上のコンテナーレジストリーの TLS(トランスポート層セキュリティー) を無効にできます。

前提条件

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

手順

  • HyperConverged カスタムリソースを編集し、非セキュアなレジストリーの一覧を spec.storageImport.insecureRegistries フィールドに追加します。

    apiVersion: hco.kubevirt.io/v1beta1
    kind: HyperConverged
    metadata:
      name: kubevirt-hyperconverged
      namespace: openshift-cnv
    spec:
      storageImport:
        insecureRegistries: 1
          - "private-registry-example-1:5000"
          - "private-registry-example-2:5000"
    1
    このリストのサンプルを、有効なレジストリーホスト名に置き換えます。

9.20.17.4. 次のステップ

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

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

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

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

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

HyperConverged カスタムリソースの spec.scratchSpaceStorageClass フィールドで、スクラッチ領域 PVC をバインドするために使用されるストレージクラスを定義できます。

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

注記

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

手動プロビジョニング

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

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

タイプ理由

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

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

9.20.18.4. ストレージクラスの定義

spec.scratchSpaceStorageClass フィールドを HyperConverged カスタムリソース (CR) に追加することにより、スクラッチ領域を割り当てる際に、Containerized Data Importer (CDI) が使用するストレージクラスを定義できます。

前提条件

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

手順

  1. 以下のコマンドを実行して、HyperConverged CR を編集します。

    $ oc edit hco -n openshift-cnv kubevirt-hyperconverged
  2. spec.scratchSpaceStorageClass フィールドを CR に追加し、値をクラスターに存在するストレージクラスの名前に設定します。

    apiVersion: hco.kubevirt.io/v1beta1
    kind: HyperConverged
    metadata:
      name: kubevirt-hyperconverged
    spec:
      scratchSpaceStorageClass: "<storage_class>" 1
    1
    ストレージクラスを指定しない場合、CDI は設定されている永続ボリューム要求 (PVC) のストレージクラスを使用します。
  3. デフォルトのエディターを保存して終了し、HyperConverged CR を更新します。

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

✓ サポートされる操作

□ サポートされない操作

* スクラッチ領域が必要

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

9.20.18.6. 関連情報

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

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

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

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

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

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

重要

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

9.20.19.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

関連情報

9.20.20. 仮想マシンディスクの拡張

仮想マシン (VM) のディスクのサイズを拡大して、ストレージ容量を増やすには、ディスクの永続ボリューム要求 (PVC) のサイズを変更します。

ただし、仮想マシンディスクのサイズを縮小することはできません。

9.20.20.1. 仮想マシンディスクの拡張

仮想マシンディスクの拡大により、仮想マシンに対して追加の領域が利用可能になります。ただし、仮想マシンの所有者は、ストレージの使用方法を決定する必要があります。

ディスクが Filesystem PVC の場合、一致するファイルは、ファイルシステムのオーバーヘッド用に一部の領域を確保しながら残りのサイズに拡張します。

手順

  1. 拡張する必要のある仮想マシンディスクの PersistentVolumeClaim マニフェストを編集します。

    $ oc edit pvc <pvc_name>
  2. spec.resource.requests.storage 属性の値を大きなサイズに変更します。

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
       name: vm-disk-expand
    spec:
      accessModes:
         - ReadWriteMany
      resources:
        requests:
           storage: 3Gi 1
    ...
    1
    拡張できる仮想マシンのディスクサイズ

9.20.20.2. 関連情報

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

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

注記

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

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

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

9.20.21.2. すべてのデータボリュームのリスト表示

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

手順

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

    $ oc get dvs

9.20.21.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.