9.20. 仮想マシンディスク

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

手順

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

手順

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 要素に表示されます。

手順

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 オブジェクトを更新します。

手順

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 を更新します。

手順

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

手順

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

手順

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

手順

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

   直前の手順で作成された永続ボリュームのファイル名。

手順

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

手順

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

手順

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

2. QEMU ゲストエージェントを仮想マシンにインストールします。

   $ yum install -y qemu-guest-agent

3. サービスに永続性があることを確認し、これを起動します。

   $ systemctl enable --now qemu-guest-agent

手順

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

手順

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

手順

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

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

2. オンライン仮想マシンのスナップショットのステータスを確認します。

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

手順

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

5. 仮想マシンのスナップショットを復元するには、以下のいずれかの方法を選択します。

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

手順

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

手順

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

手順

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

   • nodeAffinity.nodeSelectorTerms パラメーターを含むローカル PV を作成します。以下のマニフェストは、node01 に 10Gi のローカル 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>

手順

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

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

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 のクローン作成中に新規データボリュームを参照する仮想マシンを作成できます。

手順

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

手順

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

手順

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

手順

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

手順

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

手順

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

手順

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 を更新します。

手順

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

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

      $ oc get pv <pv_name> -o yaml | grep 'persistentVolumeReclaimPolicy'

   2. persistentVolumeReclaimPolicy が Retain に設定されていない場合、以下のコマンドで回収ポリシーを編集します。

      $ 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

手順

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

   拡張できる仮想マシンのディスクサイズ