8.18. 仮想マシンディスク

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

手順

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

   $ touch machineconfig.yaml

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

   apiVersion: machineconfiguration.openshift.io/v1
   kind: MachineConfig
   metadata:
     name: 50-set-selinux-for-hostpath-provisioner
     labels:
       machineconfiguration.openshift.io/role: worker
   spec:
     config:
       ignition:
         version: 3.2.0
       systemd:
         units:
           - contents: |
               [Unit]
               Description=Set SELinux chcon for hostpath provisioner
               Before=kubelet.service
   
               [Service]
               ExecStart=/usr/bin/chcon -Rt container_file_t <backing_directory_path> 1
   
               [Install]
               WantedBy=multi-user.target
             enabled: true
             name: hostpath-provisioner.service

   1

   プロビジョナーが PV を作成するバッキングディレクトリーを指定します。このディレクトリーは、ファイルシステムの root ディレクトリー (/) に置かないでください。

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

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

手順

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

   $ touch hostpathprovisioner_cr.yaml

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

   apiVersion: hostpathprovisioner.kubevirt.io/v1beta1
   kind: HostPathProvisioner
   metadata:
     name: hostpath-provisioner
   spec:
     imagePullPolicy: IfNotPresent
     pathConfig:
       path: "<backing_directory_path>" 1
       useNamingPrefix: false 2
     workload: 3

   1

   プロビジョナーが PV を作成するバッキングディレクトリーを指定します。このディレクトリーは、ファイルシステムの root ディレクトリー (/) に置かないでください。

   2

   作成された PV にバインドされる永続ボリューム要求 (PVC) の名前をディレクトリー名の接頭辞として使用する場合には、この値を true に変更します。

   3

   オプション: spec.workload フィールドを使用して、ホストパスプロビジョナーのノードの配置ルールを設定できます。

   注記

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

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

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

手順

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

   $ touch storageclass.yaml

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

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: hostpath-provisioner 1
   provisioner: kubevirt.io/hostpath-provisioner
   reclaimPolicy: Delete 2
   volumeBindingMode: WaitForFirstConsumer 3

   1

   この値を変更することで、オプションでストレージクラスの名前を変更できます。

   2

   reclaimPolicy には、Delete および Retain の 2 つの値があります。値を指定しない場合、ストレージクラスはデフォルトで Delete に設定されます。

   3

   volumeBindingMode 値は、動的プロビジョニングおよびボリュームバインディングが実行されるタイミングを決定します。WaitForFirstConsumer を指定して、永続ボリューム要求 (PVC) を使用する Pod が作成されるまで PV のバインディングおよびプロビジョニングを遅延させます。これにより、PV が Pod のスケジュール要件を満たすようになります。

   注記

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

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

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

   $ oc create -f storageclass.yaml

手順

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

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

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

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

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

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

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

   1

   選択する accessModes

   2

   選択する volumeMode。

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

手順

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

   $ oc edit cdi

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

   ...
   spec:
     config:
       filesystemOverhead:
         global: "<new_global_value>" 1
         storageClass:
           <storage_class_name>: "<new_value_for_this_storage_class>" 2

   1

   CDI がクラスター全体で使用するファイルシステムのオーバーヘッドの割合 (パーセント)。たとえば、global: "0.07" は、ファイルシステムのオーバーヘッド用に PVC の 7% を確保します。

   2

   指定されたストレージクラスのファイルシステムのオーバーヘッドの割合 (パーセンテージ)。たとえば、mystorageclass: "0.04" は、mystorageclass ストレージクラスの PVC のデフォルトオーバーヘッド値を 4% に変更します。

3. エディターを保存し、終了して CDI オブジェクトを更新します。

手順

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

手順

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

   以下に例を示します。

   apiVersion: snapshot.kubevirt.io/v1alpha1
   kind: VirtualMachineSnapshot
   metadata:
     name: my-vmsnapshot 1
   spec:
     source:
       apiGroup: kubevirt.io
       kind: VirtualMachine
       name: my-vm 2

   1

   新規 VirtualMachineSnapshot オブジェクトの名前。

   2

   ソース仮想マシンの名前。

2. VirtualMachineSnapshot リソースを作成します。スナップコントローラーは VirtualMachineSnapshotContent オブジェクトを作成し、これを VirtualMachineSnapshot にバインドし、 VirtualMachineSnapshot オブジェクトの status および readyToUse フィールドを更新します。

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

検証

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

   $ oc describe vmsnapshot <my-vmsnapshot>

   出力例

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

   1

   Progressing 状態の status フィールドは、スナップショットが作成中であるかどうかを指定します。

   2

   Ready 状態の status フィールドは、スナップショットの作成プロセスが完了しているかどうかを指定します。

   3

   スナップショットを使用する準備ができているかどうかを指定します。

   4

   スナップショットが、スナップショットコントローラーで作成される VirtualMachineSnapshotContent オブジェクトにバインドされるように指定します。

2. VirtualMachineSnapshotContent リソースの spec:volumeBackups プロパティーをチェックし、予想される PVC がスナップショットに含まれることを確認します。

手順

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

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

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

手順

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. サイドメニューから Workloads Virtualization をクリックします。
2. Virtual Machines タブをクリックします。
3. 仮想マシンを選択して、Virtual Machine Overview 画面を開きます。
4. Snapshots タブをクリックします。このページには、仮想マシンに関連付けられたスナップショットの一覧が表示されます。

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

   1. 削除する仮想マシンスナップショットの Options メニュー をクリックして、 Delete Virtual Machine Snapshot を選択します。
   2. スナップショットを選択して Snapshot Details 画面を開き、Actions Delete Virtual Machine Snapshot をクリックします。
6. 確認のポップアップウィンドウで、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. データボリューム設定ファイルを編集します。

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

1. Templates タブをクリックします。
2. このテンプレートのタイルに緑色のチェックマークが表示されていることを確認します。

手順

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

6. Persistent Volume Claim size の値を入力し、圧縮解除されたイメージおよび必要な追加の領域に十分な PVC サイズを指定します。

   1. オプション: このテンプレートに名前を関連付けるために Source provider の名前を入力します。

   2. オプション: Advanced Storage settings: Storage class をクリックし、ディスクの作成に使用するストレージクラスを選択します。通常、このストレージクラスはすべての PVC で使用するために作成されるデフォルトのストレージクラスです。

      注記

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

   3. オプション: Advanced Storage settings: Access mode をクリックし、永続ボリュームのアクセスモードを選択します。

      • Single User (RWO) は、1 つのノードによる読み取り/書き込みとしてボリュームをマウントします。
      • Shared Access (RWX) は、多くのノードによる読み取り/書き込みとしてボリュームをマウントします。
      • Read Only (ROX) は、多くのノードによる読み取り専用としてボリュームをマウントします。
   4. オプション: Advanced Storage settings: デフォルト値の Filesystem の代わりに Block を選択する場合は、Volume mode をクリックします。OpenShift Virtualization は、raw ブロックボリュームを静的にプロビジョニングできます。これらのボリュームにはファイルシステムがなく、ディスクに直接書き込むアプリケーションや、独自のストレージサービスを実装するアプリケーションにはパフォーマンス上の利点があります。

7. ブートソースを保存する適切な方法を選択します。

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

手順

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

手順

1. OpenShift Virtualization コンソールのサイドメニューから、Workloads > Virtualization をクリックします。
2. Templates タブをクリックします。
3. カスタマイズするテンプレートの Source provider 列にあるリンクをクリックします。ウィンドウが表示され、テンプレートに現在 定義されている ソースがあることを示します。
4. ウィンドウで Customize source リンクをクリックします。
5. ブートソースのカスタマイズプロセスについて提供された情報を読んだ後、About boot source customization ウィンドウで Continue をクリックして、カスタマイズを続行します。

6. Prepare boot source customization ページの Define new template セクションで、以下を実行します。

   1. New template namespace フィールドを選択してから、プロジェクトを選択します。
   2. New template name フィールドに、カスタムテンプレートの名前を入力します。
   3. New template provider フィールドに、テンプレートプロバイダーの名前を入力します。
   4. New template support フィールドを選択してから、作成するカスタムテンプレートのサポートの連絡先を示す適切な値を選択します。
   5. New template flavor フィールドを選択してから、作成するカスタムイメージの適切な CPU およびメモリーの値を選択します。
7. Prepare boot source for customize セクションで、必要に応じてログイン認証情報を定義する cloud-init YAML スクリプトをカスタマイズします。それ以外の場合は、スクリプトによりデフォルトの認証情報が生成されます。
8. Start Customization をクリックします。カスタマイズプロセスが開始され、Preparing boot source customization ページが表示され、その後に Customize boot source ページが表示されます。Customize boot source ページには、実行中のスクリプトの出力が表示されます。スクリプトが完了したら、カスタムイメージが利用可能になります。
9. VNC console で、Guest login credentials セクションの show password をクリックします。ログイン認証情報が表示されます。
10. ログインのイメージの準備ができたら、Guest login credentials セクションに表示されるユーザー名およびパスワードを指定して、VNC Console でサインインします。
11. カスタムイメージが期待どおりに機能することを確認します。機能する場合は、Make this boot source available をクリックします。
12. Finish customization and make template available ウィンドウで、I have sealed the boot source so it can be used as a template を選択してから、Apply をクリックします。
13. Finishing boot source customization ページで、テンプレート作成プロセスが完了するまで待ちます。Navigate to template details または Navigate to template list をクリックして、カスタムブートソースから作成したカスタマイズされたテンプレートを表示します。

手順

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