7.18. 仮想マシンディスク
7.18.1. ストレージ機能
以下の表を使用して、OpenShift Virtualization のローカルおよび共有の永続ストレージ機能の可用性を確認できます。
7.18.1.1. OpenShift Virtualization ストレージ機能マトリクス
仮想マシンのライブマイグレーション | ホスト支援型仮想マシンディスクのクローン作成 | ストレージ支援型仮想マシンディスクのクローン作成 | 仮想マシンのスナップショット | |
---|---|---|---|---|
OpenShift Container Storage: RBD ブロックモードボリューム | Yes | はい | はい | はい |
OpenShift Virtualization ホストパスプロビジョナー | いいえ | はい | いいえ | いいえ |
他の複数ノードの書き込み可能なストレージ | はい [1] | はい | はい [2] | はい [2] |
他の単一ノードの書き込み可能なストレージ | いいえ | はい | はい [2] | はい [2] |
- PVC は ReadWriteMany アクセスモードを要求する必要があります。
- ストレージプロバイダーが Kubernetes および CSI スナップショット API の両方をサポートする必要があります。
以下を使用する仮想マシンのライブマイグレーションを行うことはできません。
- ReadWriteOnce (RWO) アクセスモードのストレージクラス
- SR-IOV や GPU などのパススルー機能
それらの仮想マシンの evictionStrategy
フィールドを LiveMigrate
に設定しないでください。
7.18.2. 仮想マシンのローカルストレージの設定
ホストパスプロビジョナー機能を使用して、仮想マシンのローカルストレージを設定できます。
7.18.2.1. ホストパスプロビジョナーについて
ホストパスプロビジョナーは、OpenShift Virtualization 用に設計されたローカルストレージプロビジョナーです。仮想マシンのローカルストレージを設定する必要がある場合、まずホストパスプロビジョナーを有効にする必要があります。
OpenShift Virtualization Operator のインストール時に、ホストパスプロビジョナー Operator は自動的にインストールされます。これを使用するには、以下を実行する必要があります。
SELinux を設定します。
-
Red Hat Enterprise Linux CoreOS (RHCOS) 8 ワーカーを使用する場合は、各ノードに
MachineConfig
オブジェクトを作成する必要があります。 -
それ以外の場合には、SELinux ラベル
container_file_t
を各ノードの永続ボリューム (PV) バッキングディレクトリーに適用します。
-
Red Hat Enterprise Linux CoreOS (RHCOS) 8 ワーカーを使用する場合は、各ノードに
-
HostPathProvisioner
カスタムリソースを作成します。 -
ホストパスプロビジョナーの
StorageClass
オブジェクトを作成します。
ホストパスプロビジョナー Operator は、カスタムリソースの作成時にプロビジョナーを各ノードに DaemonSet としてデプロイします。カスタムリソースファイルでは、ホストパスプロビジョナーが作成する永続ボリュームのバッキングディレクトリーを指定します。
7.18.2.2. Red Hat Enterprise Linux CoreOS (RHCOS) 8 でのホストパスプロビジョナー用の SELinux の設定
HostPathProvisioner
カスタムリソースを作成する前に、SELinux を設定する必要があります。Red Hat Enterprise Linux CoreOS (RHCOS) 8 ワーカーで SELinux を設定するには、各ノードに MachineConfig
オブジェクトを作成する必要があります。
前提条件
ホストパスプロビジョナーが作成する永続ボリューム (PV) 用に、各ノードにバッキングディレクトリーを作成すること。
重要/
パーティションは RHCOS で読み取り専用であるため、バッキングディレクトリーをファイルシステムの root ディレクトリーに置かないでください。たとえば、/var/<directory_name>
は使用できますが、/<directory_name>
は使用できません。
手順
MachineConfig
ファイルを作成します。以下に例を示します。$ touch machineconfig.yaml
ファイルを編集し、ホストパスプロビジョナーが 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 ディレクトリー (
/
) に置かないでください。
MachineConfig
オブジェクトを作成します。$ oc create -f machineconfig.yaml -n <namespace>
7.18.2.3. ホストパスプロビジョナーを使用したローカルストレージの有効化
ホストパスプロビジョナーをデプロイし、仮想マシンがローカルストレージを使用できるようにするには、最初に HostPathProvisioner
カスタムリソースを作成します。
前提条件
ホストパスプロビジョナーが作成する永続ボリューム (PV) 用に、各ノードにバッキングディレクトリーを作成すること。
重要/
パーティションは Red Hat Enterprise Linux CoreOS (RHCOS) で読み取り専用であるため、バッキングディレクトリーをファイルシステムの root ディレクトリーに置かないでください。たとえば、/var/<directory_name>
は使用できますが、/<directory_name>
は使用できません。SELinux コンテキスト
container_file_t
を各ノードの PV バッキングディレクトリーに適用すること。以下に例を示します。$ sudo chcon -t container_file_t -R <backing_directory_path>
注記Red Hat Enterprise Linux CoreOS 8 (RHCOS) ワーカーを使用する場合は、代わりに
MachineConfig
マニフェストを使用して SELinux を設定する必要があります。
手順
HostPathProvisioner
カスタムリソースファイルを作成します。以下に例を示します。$ touch hostpathprovisioner_cr.yaml
ファイルを編集し、
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
注記バッキングディレクトリーを作成していない場合、プロビジョナーはこの作成を試行します。
container_file_t
SELinux コンテキストを適用していない場合、これによりPermission denied
エラーが生じる可能性があります。openshift-cnv
namespace にカスタムリソースを作成します。$ oc create -f hostpathprovisioner_cr.yaml -n openshift-cnv
7.18.2.4. ストレージクラスの作成
ストレージクラスの作成時に、ストレージクラスに属する永続ボリューム (PV) の動的プロビジョニングに影響するパラメーターを設定します。StorageClass
オブジェクトの作成後には、このオブジェクトのパラメーターを更新できません。
OpenShift Container Platform Container Storage と共に OpenShift Virtualization を使用する場合、仮想マシンディスクの作成時に RBD ブロックモードの永続ボリューム要求 (PVC) を指定します。仮想マシンディスクの場合、RBD ブロックモードのボリュームは効率的で、Ceph FS または RBD ファイルシステムモードの PVC よりも優れたパフォーマンスを提供します。
RBD ブロックモードの PVC を指定するには、'ocs-storagecluster-ceph-rbd' ストレージクラスおよび VolumeMode: Block
を使用します。
手順
ストレージクラスを定義する YAML ファイルを作成します。以下に例を示します。
$ touch storageclass.yaml
ファイルを編集します。以下に例を示します。
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 を使用して作成されるまで遅延します。StorageClass
オブジェクトを作成します。$ oc create -f storageclass.yaml
関連情報
7.18.3. ファイルシステムオーバーヘッドの PVC 領域の確保
デフォルトで、Containerized Data Importer (CDI) は、Filesystem
ボリュームモードを使用する永続ボリューム要求 (PVC) のファイルシステムのオーバーヘッドデータ用に領域を確保します。CDI がこの目的で予約する割合をクローバルに設定し、また特定のストレージクラス用に設定できます。
7.18.3.1. ファイルシステムのオーバーヘッドが仮想マシンディスクの領域に影響を与える仕組み
仮想マシンディスクを Filesystem
ボリュームモードを使用する永続ボリューム要求 (PVC) に追加する場合、PVC で十分な容量があることを確認する必要があります。
- 仮想マシンディスク。
- Containerized Data Importer (CDI) が、メタデータなどのファイルシステムのオーバーヘッドに予約する領域。
デフォルトで、CDI はオーバーヘッド用に PVC 領域の 5.5% を予約し、その分、仮想マシンディスクに利用可能な領域を縮小します。
特定のユースケースに異なる値を使用する方が良い場合は、CDI
オブジェクトを編集してオーバーヘッドの値を設定できます。値はグローバルに変更でき、特定のストレージクラスの値を指定できます。
7.18.3.2. デフォルトのファイルシステムオーバーヘッド値の上書き
CDI
オブジェクトの spec.config.filesystemOverhead
属性を編集し、Containerized Data Importer (CDI) がファイルシステムのオーバーヘッド用に予約する永続ボリューム要求 (PVC) 領域の量を変更します。
前提条件
-
OpenShift CLI (
oc
) をインストールしている。
手順
以下のコマンドを実行して、編集するために
CDI
オブジェクトを開きます。$ oc edit cdi
spec.config.filesystemOverhead
フィールドを編集して、選択した値でデータを設定します。... spec: config: filesystemOverhead: global: "<new_global_value>" 1 storageClass: <storage_class_name>: "<new_value_for_this_storage_class>" 2
-
エディターを保存し、終了して
CDI
オブジェクトを更新します。
検証
以下のコマンドを実行して
CDI
ステータスを表示し、変更を確認します。$ oc get cdi -o yaml
7.18.4. コンピュートリソースクォータを持つ namespace で機能する CDI の設定
Containerized Data Importer (CDI) を使用して、CPU およびメモリーリソースの制限が適用される namespace に仮想マシンディスクをインポートし、アップロードし、そのクローンを作成できるようになりました。
7.18.4.1. namespace の CPU およびメモリークォータについて
ResourceQuota
オブジェクトで定義される リソースクォータ は、その namespace 内のリソースが消費できるコンピュートリソースの全体量を制限する制限を namespace に課します。
CDI
オブジェクトは Containerized Data Importer (CDI) のユーザー設定を定義します。CDI
オブジェクトの CPU およびメモリーの要求および制限の値はデフォルト値の 0 に設定されます。これにより、コンピュートリソース要件を指定しない CDI によって作成される Pod にデフォルト値が付与され、クォータで制限される namespace での実行が許可されます。
7.18.4.2. CPU およびメモリーのデフォルトを上書きするための CDI オブジェクトの編集
CDI
オブジェクトの spec.config.podResourceRequirements
フィールドを編集して、ユースケースに応じて CPU およびメモリーの要求および制限のデフォルト設定を変更します。
前提条件
-
OpenShift CLI (
oc
) をインストールしている。
手順
以下のコマンドを実行して
CDI
オブジェクトを編集します。$ oc edit cdi
CDI
オブジェクトのspec: podResourceRequirements
フィールドを編集して、デフォルトの CPU およびメモリーの要求および制限を変更します。apiVersion: cdi.kubevirt.io/v1beta1 kind: CDI ... spec: config: podResourceRequirements: limits: cpu: "4" memory: "1Gi" requests: cpu: "1" memory: "250Mi" ...
-
エディターを保存し、終了して
CDI
オブジェクトを更新します。
検証
CDI
オブジェクトのstatus
フィールドを表示して変更を確認します。$ oc get cdi -o yaml
7.18.4.3. 関連情報
7.18.5. データボリュームの事前割り当ての使用
Containerized Data Importer は、データボリュームの作成時に書き込みパフォーマンスを向上させるために、ディスク領域を事前に割り当てることができます。
クラスターまたは特定のデータボリュームに対して、事前割り当てをグローバルに有効にできます。
7.18.5.1. 事前割り当てについて
Containerized Data Importer (CDI) は、データボリュームに QEMU 事前割り当てモードを使用し、書き込みパフォーマンスを向上できます。操作のインポートおよびアップロードには、事前割り当てモードを使用できます。また、空のデータボリュームを作成する際にも使用できます。
事前割り当てが有効化されている場合、CDI は基礎となるファイルシステムおよびデバイスタイプに応じて、より適切な事前割り当て方法を使用します。
fallocate
-
ファイルシステムがこれをサポートする場合、CDI は
posix_fallocate
関数を使って領域を事前に割り当てるためにオペレーティングシステムのfallocate
呼び出しを使用します。これは、ブロックを割り当て、それらを未初期化としてマークします。 full
-
fallocate
モードを使用できない場合は、基礎となるストレージにデータを書き込むことで、full
モードがイメージの領域を割り当てます。ストレージの場所によっては、空の割り当て領域がすべてゼロになる場合があります。
7.18.5.2. 事前割り当てグローバルに有効にする
prellocation
フィールドを CDI
オブジェクトに追加して、Containerized Data Importer (CDI) のクラスター全体の事前割り当てモードを有効にすることができます。
前提条件
-
OpenShift CLI (
oc
) をインストールすること。
手順
oc
クライアントを使用してCDI
オブジェクトを編集します。$ oc edit cdi
spec.config.preallocation
フィールドをtrue
の値で設定します。apiVersion: cdi.kubevirt.io/v1beta1 kind: CDI metadata: ... spec: config: preallocation: true 1
- 1
preallocation
フィールドは、デフォルトで false に設定されるブール値です。
-
エディターを保存して終了し、
CDI
オブジェクトを更新して事前割り当てモードを有効にします。
7.18.5.3. データボリュームの事前割り当ての有効化
事前割り当てがクラスターに対してグローバルに有効化されていない場合、データボリュームマニフェストに spec.preallocation
フィールドを追加して、特定のデータボリュームに対してこれを有効化することができます。Web コンソールで、または OpenShift クライアント (oc
) を使用して、事前割り当てモードを有効化することができます。
事前割り当てモードは、すべての CDI ソースタイプでサポートされます。
手順
データボリュームマニフェストの
spec.preallocation
フィールドを指定します。apiVersion: cdi.kubevirt.io/v1beta1 kind: DataVolume metadata: name: preallocated-datavolume spec: source: 1 ... pvc: ... preallocation: true 2
7.18.6. Web コンソールの使用によるローカルディスクイメージのアップロード
Web コンソールを使用して、ローカルに保存されたディスクイメージファイルをアップロードできます。
7.18.6.1. 前提条件
- 仮想マシンのイメージファイルには、IMG、ISO、または QCOW2 形式のファイルを使用する必要がある。
- CDI でサポートされる操作マトリックス に応じてスクラッチ領域が必要な場合、まずは、この操作が正常に実行されるように ストレージクラスを定義するか、または CDI スクラッチ領域を用意 すること。
7.18.6.2. CDI がサポートする操作マトリックス
このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。
コンテンツタイプ | HTTP | HTTPS | HTTP Basic 認証 | レジストリー | アップロード |
---|---|---|---|---|---|
kubevirt (QCOW2) |
✓ QCOW2 |
✓ QCOW2** |
✓ QCOW2 |
✓ QCOW2* |
✓ QCOW2* |
KubeVirt (RAW) |
✓ RAW |
✓ RAW |
✓ RAW |
✓ RAW* |
✓ RAW* |
✓ サポートされる操作
□ サポートされない操作
* スクラッチ領域が必要
**カスタム認証局が必要な場合にスクラッチ領域が必要
7.18.6.3. Web コンソールを使用したイメージファイルのアップロード
Web コンソールを使用して、イメージファイルを新規の永続ボリューム要求 (PVC) にアップロードします。この PVC を後で使用して、イメージを新規の仮想マシンに割り当てることができます。
前提条件
以下のいずれかが必要である。
- ISO または IMG 形式のいずれかの raw 仮想マシンイメージファイル。
- QCOW2 形式の仮想マシンのイメージファイル。
最善の結果を得るには、アップロードする前にイメージファイルを以下のガイドラインに従って圧縮すること。
xz
またはgzip
を使用して raw イメージファイルを圧縮します。注記圧縮された raw イメージファイルを使用すると、最も効率的にアップロードできます。
クライアントについて推奨される方法を使用して、QCOW2 イメージファイルを圧縮します。
- Linux クライアントを使用する場合は、virt-sparsify ツールを使用して、QCOW2 ファイルをスパース化 (sparsify) します。
-
Windows クライアントを使用する場合は、
xz
またはgzip
を使用して QCOW2 ファイルを圧縮します。
手順
-
Web コンソールのサイドメニューから、Storage
Persistent Volume Claims をクリックします。 - Create Persistent Volume Claim ドロップダウンリストをクリックし、これを拡張します。
- With Data Upload Form をクリックし、Upload Data to Persistent Volume Claim ページを開きます。
- Browse をクリックし、ファイルマネージャーを開き、アップロードするイメージを選択するか、ファイルを Drag a file here or browse to upload フィールドにドラッグします。
オプション: 特定のオペレーティングシステムのデフォルトイメージとしてこのイメージを設定します。
- Attach this data to a virtual machine operating system チェックボックスを選択します。
- 一覧からオペレーティングシステムを選択します。
- Persistent Volume Claim Name フィールドには、一意の名前が自動的に入力され、これを編集することはできません。PVC に割り当てられた名前をメモし、必要に応じてこれを後で特定できるようにします。
- Storage Class 一覧からストレージクラスを選択します。
Size フィールドに PVC のサイズ値を入力します。ドロップダウンリストから、対応する測定単位を選択します。
警告PVC サイズは圧縮解除された仮想ディスクのサイズよりも大きくなければなりません。
- 選択したストレージクラスに一致する Access Mode を選択します。
- Upload をクリックします。
7.18.6.4. 関連情報
- 事前割り当てモードを設定 して、データボリューム操作の書き込みパフォーマンスを向上させます。
7.18.7. virtctl ツールの使用によるローカルディスクイメージのアップロード
virtctl
コマンドラインユーティリティーを使用して、ローカルに保存されたディスクイメージを新規または既存のデータボリュームにアップロードできます。
7.18.7.1. 前提条件
-
kubevirt-virtctl
パッケージを インストール すること。 - CDI でサポートされる操作マトリックス に応じてスクラッチ領域が必要な場合、まずは、この操作が正常に実行されるように ストレージクラスを定義するか、または CDI スクラッチ領域を用意 すること。
7.18.7.2. データボリュームについて
DataVolume
オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは OpenShift Virtualization に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。
7.18.7.3. アップロードデータボリュームの作成
ローカルディスクイメージのアップロードに使用する upload
データソースでデータボリュームを手動で作成できます。
手順
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
以下のコマンドを実行してデータボリュームを作成します。
$ oc create -f <upload-datavolume>.yaml
7.18.7.4. ローカルディスクイメージのデータボリュームへのアップロード
virtctl
CLI ユーティリティーを使用して、ローカルディスクイメージをクライアントマシンからクラスター内のデータボリューム (DV) にアップロードできます。この手順の実行時に、すでにクラスターに存在する DV を使用するか、または新規の DV を作成することができます。
ローカルディスクイメージのアップロード後に、これを仮想マシンに追加できます。
前提条件
以下のいずれかが必要である。
- ISO または IMG 形式のいずれかの raw 仮想マシンイメージファイル。
- QCOW2 形式の仮想マシンのイメージファイル。
最善の結果を得るには、アップロードする前にイメージファイルを以下のガイドラインに従って圧縮すること。
xz
またはgzip
を使用して raw イメージファイルを圧縮します。注記圧縮された raw イメージファイルを使用すると、最も効率的にアップロードできます。
クライアントについて推奨される方法を使用して、QCOW2 イメージファイルを圧縮します。
- Linux クライアントを使用する場合は、virt-sparsify ツールを使用して、QCOW2 ファイルをスパース化 (sparsify) します。
-
Windows クライアントを使用する場合は、
xz
またはgzip
を使用して QCOW2 ファイルを圧縮します。
-
kubevirt-virtctl
パッケージがクライアントマシンにインストールされていること。 - クライアントマシンが OpenShift Container Platform ルーターの証明書を信頼するように設定されていること。
手順
以下を特定します。
- 使用するアップロードデータボリュームの名前。このデータボリュームが存在しない場合、これは自動的に作成されます。
- データボリュームのサイズ (アップロード手順の実行時に作成する必要がある場合)。サイズはディスクイメージのサイズ以上である必要があります。
- アップロードする必要のある仮想マシンディスクイメージのファイルの場所。
virtctl image-upload
コマンドを実行してディスクイメージをアップロードします。直前の手順で特定したパラメーターを指定します。以下に例を示します。$ virtctl image-upload dv <datavolume_name> \ 1 --size=<datavolume_size> \ 2 --image-path=</path/to/image> \ 3
注記-
新規データボリュームを作成する必要がない場合は、
--size
パラメーターを省略し、--no-create
フラグを含めます。 - ディスクイメージを PVC にアップロードする場合、PVC サイズは圧縮されていない仮想ディスクのサイズよりも大きくなければなりません。
-
HTTPS を使用したセキュアでないサーバー接続を許可するには、
--insecure
パラメーターを使用します。--insecure
フラグを使用する際に、アップロードエンドポイントの信頼性は検証 されない 点に注意してください。
-
新規データボリュームを作成する必要がない場合は、
オプション。データボリュームが作成されたことを確認するには、以下のコマンドを実行してすべてのデータボリュームを表示します。
$ oc get dvs
7.18.7.5. CDI がサポートする操作マトリックス
このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。
コンテンツタイプ | HTTP | HTTPS | HTTP Basic 認証 | レジストリー | アップロード |
---|---|---|---|---|---|
kubevirt (QCOW2) |
✓ QCOW2 |
✓ QCOW2** |
✓ QCOW2 |
✓ QCOW2* |
✓ QCOW2* |
KubeVirt (RAW) |
✓ RAW |
✓ RAW |
✓ RAW |
✓ RAW* |
✓ RAW* |
✓ サポートされる操作
□ サポートされない操作
* スクラッチ領域が必要
**カスタム認証局が必要な場合にスクラッチ領域が必要
7.18.7.6. 関連情報
- 事前割り当てモードを設定 して、データボリューム操作の書き込みパフォーマンスを向上させます。
7.18.8. ブロックストレージデータボリュームへのローカルディスクイメージのアップロード
virtctl
コマンドラインユーティリティーを使用して、ローカルのディスクイメージをブロックデータボリュームにアップロードできます。
このワークフローでは、ローカルブロックデバイスを使用して永続ボリュームを使用し、このブロックボリュームを upload
データボリュームに関連付け、 virtctl
を使用してローカルディスクイメージをデータボリュームにアップロードできます。
7.18.8.1. 前提条件
-
kubevirt-virtctl
パッケージを インストール すること。 - CDI でサポートされる操作マトリックス に応じてスクラッチ領域が必要な場合、まずは、この操作が正常に実行されるように ストレージクラスを定義するか、または CDI スクラッチ領域を用意 すること。
7.18.8.2. データボリュームについて
DataVolume
オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは OpenShift Virtualization に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。
7.18.8.3. ブロック永続ボリュームについて
ブロック永続ボリューム (PV) は、raw ブロックデバイスによってサポートされる PV です。これらのボリュームにはファイルシステムがなく、オーバーヘッドを削減することで、仮想マシンのパフォーマンス上の利点をもたらすことができます。
raw ブロックボリュームは、PV および永続ボリューム要求 (PVC) 仕様で volumeMode: Block
を指定してプロビジョニングされます。
7.18.8.4. ローカルブロック永続ボリュームの作成
ファイルにデータを設定し、これをループデバイスとしてマウントすることにより、ノードでローカルブロック永続ボリューム (PV) を作成します。次に、このループデバイスを PV マニフェストで Block
ボリュームとして参照し、これを仮想マシンイメージのブロックデバイスとして使用できます。
手順
-
ローカル PV を作成するノードに
root
としてログインします。この手順では、node01
を例に使用します。 ファイルを作成して、これを null 文字で設定し、ブロックデバイスとして使用できるようにします。以下の例では、2Gb (20 100Mb ブロック) のサイズのファイル
loop10
を作成します。$ dd if=/dev/zero of=<loop10> bs=100M count=20
loop10
ファイルをループデバイスとしてマウントします。$ losetup </dev/loop10>d3 <loop10> 1 2
マウントされたループデバイスを参照する
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
ブロック PV を作成します。
# oc create -f <local-block-pv10.yaml>1
- 1
- 直前の手順で作成された永続ボリュームのファイル名。
7.18.8.5. アップロードデータボリュームの作成
ローカルディスクイメージのアップロードに使用する upload
データソースでデータボリュームを手動で作成できます。
手順
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
以下のコマンドを実行してデータボリュームを作成します。
$ oc create -f <upload-datavolume>.yaml
7.18.8.6. ローカルディスクイメージのデータボリュームへのアップロード
virtctl
CLI ユーティリティーを使用して、ローカルディスクイメージをクライアントマシンからクラスター内のデータボリューム (DV) にアップロードできます。この手順の実行時に、すでにクラスターに存在する DV を使用するか、または新規の DV を作成することができます。
ローカルディスクイメージのアップロード後に、これを仮想マシンに追加できます。
前提条件
以下のいずれかが必要である。
- ISO または IMG 形式のいずれかの raw 仮想マシンイメージファイル。
- QCOW2 形式の仮想マシンのイメージファイル。
最善の結果を得るには、アップロードする前にイメージファイルを以下のガイドラインに従って圧縮すること。
xz
またはgzip
を使用して raw イメージファイルを圧縮します。注記圧縮された raw イメージファイルを使用すると、最も効率的にアップロードできます。
クライアントについて推奨される方法を使用して、QCOW2 イメージファイルを圧縮します。
- Linux クライアントを使用する場合は、virt-sparsify ツールを使用して、QCOW2 ファイルをスパース化 (sparsify) します。
-
Windows クライアントを使用する場合は、
xz
またはgzip
を使用して QCOW2 ファイルを圧縮します。
-
kubevirt-virtctl
パッケージがクライアントマシンにインストールされていること。 - クライアントマシンが OpenShift Container Platform ルーターの証明書を信頼するように設定されていること。
手順
以下を特定します。
- 使用するアップロードデータボリュームの名前。このデータボリュームが存在しない場合、これは自動的に作成されます。
- データボリュームのサイズ (アップロード手順の実行時に作成する必要がある場合)。サイズはディスクイメージのサイズ以上である必要があります。
- アップロードする必要のある仮想マシンディスクイメージのファイルの場所。
virtctl image-upload
コマンドを実行してディスクイメージをアップロードします。直前の手順で特定したパラメーターを指定します。以下に例を示します。$ virtctl image-upload dv <datavolume_name> \ 1 --size=<datavolume_size> \ 2 --image-path=</path/to/image> \ 3
注記-
新規データボリュームを作成する必要がない場合は、
--size
パラメーターを省略し、--no-create
フラグを含めます。 - ディスクイメージを PVC にアップロードする場合、PVC サイズは圧縮されていない仮想ディスクのサイズよりも大きくなければなりません。
-
HTTPS を使用したセキュアでないサーバー接続を許可するには、
--insecure
パラメーターを使用します。--insecure
フラグを使用する際に、アップロードエンドポイントの信頼性は検証 されない 点に注意してください。
-
新規データボリュームを作成する必要がない場合は、
オプション。データボリュームが作成されたことを確認するには、以下のコマンドを実行してすべてのデータボリュームを表示します。
$ oc get dvs
7.18.8.7. CDI がサポートする操作マトリックス
このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。
コンテンツタイプ | HTTP | HTTPS | HTTP Basic 認証 | レジストリー | アップロード |
---|---|---|---|---|---|
kubevirt (QCOW2) |
✓ QCOW2 |
✓ QCOW2** |
✓ QCOW2 |
✓ QCOW2* |
✓ QCOW2* |
KubeVirt (RAW) |
✓ RAW |
✓ RAW |
✓ RAW |
✓ RAW* |
✓ RAW* |
✓ サポートされる操作
□ サポートされない操作
* スクラッチ領域が必要
**カスタム認証局が必要な場合にスクラッチ領域が必要
7.18.8.8. 関連情報
- 事前割り当てモードを設定 して、データボリューム操作の書き込みパフォーマンスを向上させます。
7.18.9. オフラインの仮想マシンスナップショットの管理
オフ (オフライン) になっている仮想マシンの仮想マシン (VM) スナップショットを作成し、復元し、削除できます。OpenShift Virtualization は、以下でオフラインの仮想マシンスナップショットをサポートします。
- Red Hat OpenShift Container Storage
- Kubernetes Volume Snapshot API をサポートする Container Storage Interface (CSI) ドライバーを使用するその他のストレージプロバイダー
7.18.9.1. 仮想マシンスナップショットについて
スナップショット は、特定の時点における仮想マシン (VM) の状態およびデータを表します。スナップショットを使用して、バックアップおよび障害復旧のために既存の仮想マシンを (スナップショットで表される) 以前の状態に復元したり、以前の開発バージョンに迅速にロールバックしたりできます。
オフラインの仮想マシンのスナップショットは、電源がオフになった (停止状態の) 仮想マシンから作成されます。スナップショットは、仮想マシンに割り当てられた各 Container Storage Interface (CSI) ボリュームのコピーと、仮想マシンの仕様およびメタデータのコピーを保存します。スナップショットは作成後に変更できません。
オフラインの仮想マシンスナップショット機能を使用すると、クラスター管理者、およびアプリケーション開発者は以下を実行できます。
- 新規 SCC の作成
- 特定の仮想マシンに割り当てられているすべてのスナップショットの一覧表示
- スナップショットからの仮想マシンの復元
- 既存の仮想マシンスナップショットの削除
7.18.9.1.1. 仮想マシンスナップショットコントローラーおよびカスタムリソース定義 (CRD)
仮想マシンスナップショット機能では、スナップショットを管理するための CRD として定義された 3 つの新規 API オブジェクトが導入されました。
-
VirtualMachineSnapshot
: スナップショットを作成するユーザー要求を表します。これには、仮想マシンの現在の状態に関する情報が含まれます。 -
VirtualMachineSnapshotContent
: クラスター上のプロビジョニングされたリソース (スナップショット) を表します。これは、仮想マシンのスナップショットコントローラーによって作成され、仮想マシンの復元に必要なすべてのリソースへの参照が含まれます。 -
VirtualMachineRestore
: スナップショットから仮想マシンを復元するユーザー要求を表します。
仮想マシンスナップショットコントローラーは、1 対 1 のマッピングで、VirtualMachineSnapshotContent
オブジェクトを、この作成に使用した VirtualMachineSnapshot
オブジェクトにバインドします。
7.18.9.2. Web コンソールでのオフライン仮想マシンスナップショットの作成
Web コンソールを使用して仮想マシン (VM) を作成することができます。
仮想マシンスナップショットには、以下の要件を満たすディスクのみが含まれます。
- データボリュームまたは永続ボリューム要求 (PVC) のいずれかでなければなりません。
- Container Storage Interface (CSI) ボリュームスナップショットをサポートするストレージクラスに属している必要があります。
仮想マシンストレージにスナップショットをサポートしないディスクが含まれる場合、それらを編集するか、またはクラスター管理者にお問い合わせください。
手順
-
サイドメニューから Workloads
Virtualization をクリックします。 - Virtual Machines タブをクリックします。
- 仮想マシンを選択して、Virtual Machine Overview 画面を開きます。
-
仮想マシンが実行されている場合、Actions
Stop Virtual Machine をクリックしてこの電源をオフにします。 - Snapshots タブをクリックしてから Take Snapshot をクリックします。
- Snapshot Name およびオプションの Description フィールドに入力します。
- Disks included in this Snapshot を拡張し、スナップショットに組み込むストレージボリュームを表示します。
- 仮想マシンにスナップショットに追加できないディスクがあり、それでも続行する場合は、I am aware of this warning and wish to proceed チェックボックスを選択します。
- Save をクリックします。
7.18.9.3. CLI でのオフライン仮想マシンスナップショットの作成
VirtualMachineSnapshot
オブジェクトを作成し、オフライン仮想マシンの仮想マシン (VM) スナップショットを作成できます。
前提条件
- 永続ボリューム要求 (PVC) が Container Storage Interface (CSI) ボリュームスナップショットをサポートするストレージクラスにあることを確認する。
-
OpenShift CLI (
oc
) をインストールしている。 - スナップショットを作成する仮想マシンの電源を切ること。
手順
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
VirtualMachineSnapshot
リソースを作成します。スナップコントローラーはVirtualMachineSnapshotContent
オブジェクトを作成し、これをVirtualMachineSnapshot
にバインドし、VirtualMachineSnapshot
オブジェクトのstatus
およびreadyToUse
フィールドを更新します。$ oc create -f <my-vmsnapshot>.yaml
検証
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
-
VirtualMachineSnapshotContent
リソースのspec:volumeBackups
プロパティーをチェックし、予想される PVC がスナップショットに含まれることを確認します。
7.18.9.4. Web コンソールでのスナップショットからの仮想マシンの復元
仮想マシン (VM) は、Web コンソールのスナップショットで表される以前の設定に復元できます。
手順
-
サイドメニューから Workloads
Virtualization をクリックします。 - Virtual Machines タブをクリックします。
- 仮想マシンを選択して、Virtual Machine Overview 画面を開きます。
-
仮想マシンが実行されている場合、Actions
Stop Virtual Machine をクリックしてこの電源をオフにします。 - Snapshots タブをクリックします。このページには、仮想マシンに関連付けられたスナップショットの一覧が表示されます。
仮想マシンのスナップショットを復元するには、以下のいずれかの方法を選択します。
- 仮想マシンを復元する際にソースとして使用するスナップショットの場合は、Restore をクリックします。
-
スナップショットを選択して Snapshot Details 画面を開き、Actions
Restore Virtual Machine Snapshot をクリックします。
- 確認のポップアップウィンドウで Restore をクリックし、仮想マシンをスナップショットで表される以前の設定に戻します。
7.18.9.5. CLI でのスナップショットからの仮想マシンの復元
仮想マシンスナップショットを使用して、既存の仮想マシン (VM) を以前の設定に復元できます。
前提条件
-
OpenShift CLI (
oc
) をインストールしている。 - 以前の状態に復元する仮想マシンの電源を切ること。
手順
復元する仮想マシンの名前およびソースとして使用されるスナップショットの名前を指定する
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
VirtualMachineRestore
リソースを作成します。スナップショットコントローラーは、VirtualMachineRestore
オブジェクトのステータスフィールドを更新し、既存の仮想マシン設定をスナップショットのコンテンツに置き換えます。$ oc create -f <my-vmrestore>.yaml
検証
仮想マシンがスナップショットで表される以前の状態に復元されていることを確認します。
complete
フラグはtrue
に設定される必要があります。$ oc get vmrestore <my-vmrestore>
出力例
apiVersion: snapshot.kubevirt.io/v1alpha1 kind: VirtualMachineRestore metadata: creationTimestamp: "2020-09-30T14:46:27Z" generation: 5 name: my-vmrestore namespace: default ownerReferences: - apiVersion: kubevirt.io/v1alpha3 blockOwnerDeletion: true controller: true kind: VirtualMachine name: my-vm uid: 355897f3-73a0-4ec4-83d3-3c2df9486f4f resourceVersion: "5512" selfLink: /apis/snapshot.kubevirt.io/v1alpha1/namespaces/default/virtualmachinerestores/my-vmrestore uid: 71c679a8-136e-46b0-b9b5-f57175a6a041 spec: target: apiGroup: kubevirt.io kind: VirtualMachine name: my-vm virtualMachineSnapshotName: my-vmsnapshot status: complete: true 1 conditions: - lastProbeTime: null lastTransitionTime: "2020-09-30T14:46:28Z" reason: Operation complete status: "False" 2 type: Progressing - lastProbeTime: null lastTransitionTime: "2020-09-30T14:46:28Z" reason: Operation complete status: "True" 3 type: Ready deletedDataVolumes: - test-dv1 restoreTime: "2020-09-30T14:46:28Z" restores: - dataVolumeName: restore-71c679a8-136e-46b0-b9b5-f57175a6a041-datavolumedisk1 persistentVolumeClaim: restore-71c679a8-136e-46b0-b9b5-f57175a6a041-datavolumedisk1 volumeName: datavolumedisk1 volumeSnapshotName: vmsnapshot-28eedf08-5d6a-42c1-969c-2eda58e2a78d-volume-datavolumedisk1
7.18.9.6. Web コンソールでの仮想マシンのスナップショットの削除
Web コンソールを使用して既存の仮想マシンスナップショットを削除できます。
手順
-
サイドメニューから Workloads
Virtualization をクリックします。 - Virtual Machines タブをクリックします。
- 仮想マシンを選択して、Virtual Machine Overview 画面を開きます。
- Snapshots タブをクリックします。このページには、仮想マシンに関連付けられたスナップショットの一覧が表示されます。
仮想マシンスナップショットを削除するには、以下のいずれかの方法を選択します。
- 削除する仮想マシンスナップショットの Options メニュー をクリックして、 Delete Virtual Machine Snapshot を選択します。
-
スナップショットを選択して Snapshot Details 画面を開き、Actions
Delete Virtual Machine Snapshot をクリックします。
- 確認のポップアップウィンドウで、Delete をクリックしてスナップショットを削除します。
7.18.9.7. CLI での仮想マシンのスナップショットの削除
適切な VirtualMachineSnapshot
オブジェクトを削除して、既存の仮想マシン (VM) スナップショットを削除できます。
前提条件
-
OpenShift CLI (
oc
) をインストールしている。
手順
VirtualMachineSnapshot
オブジェクトを削除します。スナップショットコントローラーは、VirtualMachineSnapshot
を、関連付けられたVirtualMachineSnapshotContent
オブジェクトと共に削除します。$ oc delete vmsnapshot <my-vmsnapshot>
検証
スナップショットが削除され、この仮想マシンに割り当てられていないことを確認します。
$ oc get vmsnapshot
7.18.9.8. 関連情報
7.18.10. ローカル仮想マシンディスクの別のノードへの移動
ローカルボリュームストレージを使用する仮想マシンは、特定のノードで実行されるように移動することができます。
以下の理由により、仮想マシンを特定のノードに移動する場合があります。
- 現在のノードにローカルストレージ設定に関する制限がある。
- 新規ノードがその仮想マシンのワークロードに対して最適化されている。
ローカルストレージを使用する仮想マシンを移行するには、データボリュームを使用して基礎となるボリュームのクローンを作成する必要があります。クローン操作が完了したら、新規データボリュームを使用できるように 仮想マシン設定を編集 するか、または 新規データボリュームを別の仮想マシンに追加 できます。
cluster-admin
ロールのないユーザーには、複数の namespace 間でボリュームのクローンを作成できるように 追加のユーザーパーミッション が必要になります。
7.18.10.1. ローカルボリュームの別のノードへのクローン作成
基礎となる永続ボリューム要求 (PVC) のクローンを作成して、仮想マシンディスクを特定のノードで実行するように移行することができます。
仮想マシンディスクのノードが適切なノードに作成されることを確認するには、新規の永続ボリューム (PV) を作成するか、または該当するノードでそれを特定します。一意のラベルを PV に適用し、これがデータボリュームで参照できるようにします。
宛先 PV のサイズはソース PVC と同じか、またはそれよりも大きくなければなりません。宛先 PV がソース PVC よりも小さい場合、クローン作成操作は失敗します。
前提条件
- 仮想マシンが実行されていないこと。仮想マシンディスクのクローンを作成する前に、仮想マシンの電源を切ります。
手順
ノードに新規のローカル 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
ターゲットノードに存在する 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 ...
PV に一意のラベルを追加します。
$ oc label pv <destination-pv> node=node01
以下を参照するデータボリュームマニフェストを作成します。
- 仮想マシンの 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
データボリュームマニフェストをクラスターに適用してクローン作成の操作を開始します。
$ oc apply -f <clone-datavolume.yaml>
データボリュームは、仮想マシンの PVC のクローンを特定のノード上の PV に作成します。
7.18.11. 空のディスクイメージを追加して仮想ストレージを拡張する
空のディスクイメージを OpenShift Virtualization に追加することによって、ストレージ容量を拡張したり、新規のデータパーティションを作成したりできます。
7.18.11.1. データボリュームについて
DataVolume
オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは OpenShift Virtualization に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。
7.18.11.2. データボリュームを使用した空のディスクイメージの作成
データボリューム設定ファイルをカスタマイズし、デプロイすることにより、新規の空のディスクイメージを永続ボリューム要求 (PVC) に作成することができます。
前提条件
- 1 つ以上の利用可能な永続ボリュームがあること。
-
OpenShift CLI (
oc
) をインストールしている。
手順
データボリューム設定ファイルを編集します。
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
以下のコマンドを実行して、空のディスクイメージを作成します。
$ oc create -f <blank-image-datavolume>.yaml
7.18.11.3. テンプレート: 空のディスクイメージのデータボリューム設定ファイル
blank-image-datavolume.yaml
apiVersion: cdi.kubevirt.io/v1beta1 kind: DataVolume metadata: name: blank-image-datavolume spec: source: blank: {} pvc: # Optional: Set the storage class or omit to accept the default # storageClassName: "hostpath" accessModes: - ReadWriteOnce resources: requests: storage: 500Mi
7.18.11.4. 関連情報
- 事前割り当てモードを設定 して、データボリューム操作の書き込みパフォーマンスを向上させます。
7.18.12. smart-cloning を使用したデータボリュームのクローン作成
smart-cloning は OpenShift Container Platform Storage (OCS) のビルトイン機能であり、クローン作成プロセスのパフォーマンスを強化するように設計されています。smart-cloning で作成したクローンは、ホスト支援型のクローン作成よりも速く、効率的です。
smart-cloning を有効にするためにアクションを実行する必要はありませんが、この機能を使用するには、ストレージ環境が smart-cloning と互換性があることを確認する必要があります。
永続ボリューム要求 (PVC) ソースでデータボリュームを作成すると、クローン作成プロセスが自動的に開始します。お使いの環境で smart-cloning をサポートするかどうかにかかわらず、データボリュームのクローンは常に受信できます。ただし、ストレージプロバイダーが smart-cloning に対応している場合、smart-cloning によるパフォーマンス上のメリットが得られます。
7.18.12.1. smart-cloning について
データボリュームに smart-cloning が実行された場合、以下が発生します。
- ソースの永続ボリューム要求 (PVC) のスナップショットが作成されます。
- PVC はスナップショットから作成されます。
- スナップショットは削除されます。
7.18.12.2. データボリュームのクローン作成
前提条件
smart-cloning が実行されるには、以下の条件が必要です。
- ストレージプロバイダーはスナップショットをサポートする必要がある。
- ソースおよびターゲット PVC は、同じ namespace に定義される必要がある。
- ソースおよびターゲット PVC は、同じストレージクラスに定義される必要がある。
-
VolumeSnapshotClass
オブジェクトは、ソースおよびターゲット PVC の両方に定義されるストレージクラスを参照する必要がある。
これらの前提条件のいずれかが満たされない場合、PVC ソースでデータボリュームを作成すると、ホスト支援型クローンが自動的に実行されます。
手順
データボリュームのクローン作成を開始するには、以下を実行します。
新規データボリュームの名前、ソース PVC の名前および namespace、および新規データボリュームのサイズを指定する
DataVolume
オブジェクトの YAML ファイルを作成します。この例では、ソース PVC のクローンをブロックモードで作成し、volumeMode: Block
が使用されます。apiVersion: cdi.kubevirt.io/v1beta1 kind: DataVolume metadata: name: <cloner-datavolume> 1 spec: source: pvc: namespace: "<source-namespace>" 2 name: "<my-favorite-vm-disk>" 3 pvc: accessModes: - ReadWriteMany resources: requests: storage: <2Gi> 4 volumeMode: Block 5
データボリュームを作成して PVC のクローン作成を開始します。
$ oc create -f <cloner-datavolume>.yaml
注記データボリュームは仮想マシンが PVC の作成前に起動することを防ぐため、PVC のクローン作成中に新規データボリュームを参照する仮想マシンを作成できます。
7.18.12.3. 関連情報
- 新規データボリュームへの仮想マシンディスクの永続ボリューム要求 (PVC) のクローン作成
- 事前割り当てモードを設定 して、データボリューム操作の書き込みパフォーマンスを向上させます。
7.18.13. データボリュームのストレージのデフォルト
kubevirt-storage-class-defaults
設定マップはデータボリュームの アクセスモード および ボリュームモード のデフォルト設定を提供します。Web コンソールで、基礎となるストレージにより適したデータボリュームを作成するために、設定マップに対してストレージクラスのデフォルトを編集したり、追加したりできます。
7.18.13.1. データボリュームのストレージ設定について
データボリュームでは、定義された アクセスモード と ボリュームモード を Web コンソールで作成する必要があります。これらのストレージ設定は、デフォルトで ReadWriteOnce
アクセスモードおよび Filesystem
ボリュームモードで設定されます。
これらの設定は、openshift-cnv
namespace で kubevirt-storage-class-defaults
設定マップを編集して変更できます。また、異なるストレージタイプについて Web コンソールでデータボリュームを作成するために、他のストレージクラスの設定を追加することもできます。
基礎となるストレージでサポートされるストレージ設定を設定する必要があります。
Web コンソールで作成するすべてのデータボリュームは、設定マップにも定義されるストレージクラスを指定しない限り、デフォルトのストレージ設定を使用します。
7.18.13.1.1. アクセスモード
データボリュームは以下のアクセスモードをサポートします。
-
ReadWriteOnce
: ボリュームは単一ノードで、read-write としてマウントできます。ReadWriteOnce
にはより多様性があり、これはデフォルトの設定です。 -
ReadWriteMany
: ボリュームは数多くのノードで、read-write としてマウントできます。ReadWriteMany
は、ノード間の仮想マシンのライブマイグレーションなどの、一部の機能で必要になります。
ReadWriteMany
は、基礎となるストレージがこれをサポートしている場合に推奨されます。
7.18.13.1.2. ボリュームモード
ボリュームモードは、ボリュームをフォーマットされたファイルシステムで使用するか、または raw ブロック状態のままにするかを定義します。データボリュームは以下のボリュームモードをサポートします。
-
Filesystem
: データボリュームにファイルシステムを作成します。これはデフォルトの設定です。 -
Block
: ブロックデータボリュームを作成します。基礎となるストレージがサポートしている場合は、Block
を使用します。
7.18.13.2. Web コンソールでの kubevirt-storage-class-defaults 設定マップの編集
データボリュームのストレージ設定を、openshift-cnv
namespace の kubevirt-storage-class-defaults
設定マップを編集して変更します。また、異なるストレージタイプについて Web コンソールでデータボリュームを作成するために、他のストレージクラスの設定を追加することもできます。
基礎となるストレージでサポートされるストレージ設定を設定する必要があります。
手順
-
サイドメニューから、Workloads
Config Maps をクリックします。 - Project 一覧で、openshift-cnv を選択します。
- kubevirt-storage-class-defaults をクリックして Config Map Overview を開きます。
- YAML タブをクリックして編集可能な設定を表示します。
基礎となるストレージに適したストレージ設定で
data
の値を更新します。... data: accessMode: ReadWriteOnce 1 volumeMode: Filesystem 2 <new>.accessMode: ReadWriteMany 3 <new>.volumeMode: Block 4
- Save をクリックして設定マップを更新します。
7.18.13.3. CLI での kubevirt-storage-class-defaults 設定マップの編集
データボリュームのストレージ設定を、openshift-cnv
namespace の kubevirt-storage-class-defaults
設定マップを編集して変更します。また、異なるストレージタイプについて Web コンソールでデータボリュームを作成するために、他のストレージクラスの設定を追加することもできます。
基礎となるストレージでサポートされるストレージ設定を設定する必要があります。
手順
以下のコマンドを実行して設定マップを編集します。
$ oc edit configmap kubevirt-storage-class-defaults -n openshift-cnv
設定マップの
data
値を更新します。... data: accessMode: ReadWriteOnce 1 volumeMode: Filesystem 2 <new>.accessMode: ReadWriteMany 3 <new>.volumeMode: Block 4
- エディターを保存し、終了して設定マップを更新します。
7.18.13.4. 複数のストレージクラスのデフォルト例
以下の YAML ファイルは、kubevirt-storage-class-defaults
設定マップの例です。これには、migration
および block
の 2 つのストレージクラスについてストレージが設定されます。
設定マップを更新する前に、すべての設定が基礎となるストレージでサポートされていることを確認してください。
kind: ConfigMap apiVersion: v1 metadata: name: kubevirt-storage-class-defaults namespace: openshift-cnv ... data: accessMode: ReadWriteOnce volumeMode: Filesystem nfs-sc.accessMode: ReadWriteMany nfs-sc.volumeMode: Filesystem block-sc.accessMode: ReadWriteMany block-sc.volumeMode: Block
7.18.14. ブートソースの作成および使用
ブートソース には、ブート可能なオペレーティングシステム (OS) とドライバーなどの OS のすべての設定が含まれます。
ブートソースを使用して、特定の設定で仮想マシンテンプレートを作成します。これらのテンプレートを使用して、利用可能な仮想マシンを多数作成することができます。
カスタムブートソースの作成、ブートソースのアップロード、およびその他のタスクを支援するために、OpenShift Container Platform Web コンソールでクイックスタートツアーを利用できます。Help メニューから Quick Starts を選択して、クイックスタートツアーを表示します。
前提条件
-
ブートソースを追加するには、
os-images.kubevirt.io:edit
RBAC ロールを持つユーザー、または管理者としてログインしていること。ブートソースが割り当てられたテンプレートから仮想マシンを作成するには、特別な権限は必要ありません。
Microsoft Windows の要件の詳細は、Creating installation media for Windows boot sources を参照してください。
7.18.14.1. 仮想マシンテンプレートのブートソースの追加
ブートソースは、仮想マシンの作成に使用するすべての仮想マシンテンプレートまたはカスタムテンプレートに設定できます。仮想マシンテンプレートがブートソースを使用して設定されている場合、それらには Templates タブで Available というラベルが付けられます。ブートソースをテンプレートに追加した後に、テンプレートから新規仮想マシンを作成できます。
Web コンソールでブートソースを選択および追加する方法は 4 つあります。
- ローカルファイルのアップロード (PVC の作成)
- URL を使用したインポート (PVC の作成)
- 既存の PVC のクローン作成 (PVC の作成)
- レジストリーを使用したインポート (PVC の作成)
前提条件
-
ブートソースを追加するには、
os-images.kubevirt.io:edit
RBAC ロールを持つユーザー、または管理者としてログインしていること。ブートソースが追加されたテンプレートから仮想マシンを作成するには、特別な権限は必要ありません。 - ローカルファイルをアップロードするには、オペレーティングシステムのイメージファイルがローカルマシンに存在している必要がある。
- URL を使用してインポートするには、オペレーティングシステムイメージのある Web サーバーへのアクセスが必要である。例: イメージが含まれる Red Hat Enterprise Linux Web ページ。
- 既存の PVC のクローンを作成するには、PVC を含むプロジェクトへのアクセスが必要である。
- レジストリーを使用してインポートするには、コンテナーレジストリーへのアクセスが必要である。
手順
-
OpenShift Virtualization コンソールのサイドメニューから Workloads
Virtualization をクリックします。 - Templates タブをクリックします。
- ブートソースを設定する仮想マシンテンプレートを特定し、Add source をクリックします。
- Add boot source to template ウィンドウで、 Select boot source をクリックし、永続ボリューム要求 (PVC) を作成するための方法を選択します: ローカルファイルのアップロード、URL を使用したインポート、既存 PVC のクローン作成、またはレジストリーを使用したインポート。
- オプション:This is a CD-ROM boot source をクリックして CD-ROM をマウントし、これを使用してオペレーティングシステムを空のディスクにインストールします。追加の空のディスクは OpenShift Virtualization で自動作成およびマウントされます。追加のディスクが必要ない場合には、仮想マシンの作成時に削除できます。
Persistent Volume Claim size の値を入力し、圧縮解除されたイメージおよび必要な追加の領域に十分な PVC サイズを指定します。
- オプション: このテンプレートに名前を関連付けるために Source provider の名前を入力します。
- Advanced: Storage class をクリックし、ディスクを作成するために使用されるストレージクラスを選択します。
- Advanced: Access mode をクリックし、永続ボリュームのアクセスモードを選択します。サポートされるアクセスモード: Single User (RWO)、Shared Access (RWX)、および Read Only (ROX)。
- Advanced: デフォルト値の Filesystem の代わりに Block を選択する場合は、Volume mode をクリックします。
ブートソースを保存する適切な方法を選択します。
- ローカルファイルをアップロードしている場合に、Save and upload をクリックします。
- URL またはレジストリーからコンテンツをインポートしている場合は、Save and import をクリックします。
- 既存の PVC のクローンを作成している場合は、Save and clone をクリックします。
ブートソースが含まれるカスタム仮想マシンテンプレートは Templates タブに一覧表示され、このテンプレートを使用して仮想マシンを作成できます。
7.18.14.2. ブートソースが割り当てられたテンプレートからの仮想マシンの作成
ブートソースをテンプレートに追加した後に、テンプレートから新規仮想マシンを作成できます。
手順
- OpenShift Container Platform Web コンソールで、サイドメニューの Workloads > Virtualization をクリックします。
- Virtual Machines タブまたは Templates タブで、Create をクリックし、Virtual Machine with Wizard を選択します。
- General ステップで、OS およびバージョン名の横にある (Source available) ラベルのあるオペレーティングシステムの一覧から OS を選択します。(Source available) ラベルは、この OS でブートソースが利用可能であることを示します。
- Select a template ステップで、OS およびバージョン名の横にある (Source available) ラベルのあるオペレーティングシステムの一覧から OS を選択します。(Source available) ラベルは、この OS でブートソースが利用可能であることを示します。
- Review and Confirm をクリックします。
- 必要に応じて、仮想マシンの設定を確認し、これを編集します。
- Create Virtual Machine をクリックし、仮想マシンを作成します。Successfully created virtual machine ページが表示されます。
7.18.14.3. 関連情報
7.18.15. 仮想マシンでのコンテナーディスクの使用
仮想マシンイメージをコンテナーディスクにビルドし、これをコンテナーレジストリーに保存することができます。次に、コンテナーディスクを仮想マシンの永続ストレージにインポートしたり、一時ストレージの仮想マシンに直接割り当てたりすることができます。
大規模なコンテナーディスクを使用する場合、I/O トラフィックが増え、ワーカーノードに影響を与える可能性があります。これにより、ノードが利用できなくなる可能性があります。この問題を解決するには、以下を実行します。
7.18.15.1. コンテナーディスクについて
コンテナーディスクは、コンテナーイメージレジストリーにコンテナーイメージとして保存される仮想マシンのイメージです。コンテナーディスクを使用して、同じディスクイメージを複数の仮想マシンに配信し、多数の仮想マシンのクローンを作成することができます。
コンテナーディスクは、仮想マシンに割り当てられるデータボリュームを使用して永続ボリューム要求 (PVC) にインポートするか、または一時 containerDisk
ボリュームとして仮想マシンに直接割り当てることができます。
7.18.15.1.1. データボリュームの使用によるコンテナーディスクの PVC へのインポート
Containerized Data Importer (CDI) を使用し、データボリュームを使用してコンテナーディスクを PVC にインポートします。次に、データボリュームを永続ストレージの仮想マシンに割り当てることができます。
7.18.15.1.2. コンテナーディスクの containerDisk
ボリュームとしての仮想マシンへの割り当て
containerDisk
ボリュームは一時的なボリュームです。これは、仮想マシンが停止されるか、再起動するか、または削除される際に破棄されます。containerDisk
ボリュームを持つ仮想マシンが起動すると、コンテナーイメージはレジストリーからプルされ、仮想マシンをホストするノードでホストされます。
containerDisk
ボリュームは、CD-ROM などの読み取り専用ファイルシステム用に、または破棄可能な仮想マシン用に使用します。
データはホストノードのローカルストレージに一時的に書き込まれるため、読み取り/書き込みファイルシステムに containerDisk
ボリュームを使用することは推奨されません。これにより、データを移行先ノードに移行する必要があるため、ノードのメンテナンス時など、仮想マシンのライブマイグレーションが遅くなります。さらに、ノードの電源が切れた場合や、予期せずにシャットダウンする場合にすべてのデータが失われます。
7.18.15.2. 仮想マシン用のコンテナーディスクの準備
仮想マシンイメージでコンテナーディスクをビルドし、これを仮想マシンで使用する前にこれをコンテナーレジストリーにプッシュする必要があります。次に、データボリュームを使用してコンテナーディスクを PVC にインポートし、これを仮想マシンに割り当てるか、またはコンテナーディスクを一時的な containerDisk
ボリュームとして仮想マシンに直接割り当てることができます。
コンテナーディスク内のディスクイメージのサイズは、コンテナーディスクがホストされるレジストリーの最大レイヤーサイズによって制限されます。
Red Hat Quay の場合、Red Hat Quay の初回デプロイ時に作成される YAML 設定ファイルを編集して、最大レイヤーサイズを変更できます。
前提条件
-
podman
がインストールされていない場合はインストールすること。 - 仮想マシンイメージは QCOW2 または RAW 形式のいずれかであること。
手順
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 に置き換えます。
コンテナーをビルドし、これにタグ付けします。
$ podman build -t <registry>/<container_disk_name>:latest .
コンテナーイメージをレジストリーにプッシュします。
$ podman push <registry>/<container_disk_name>:latest
コンテナーレジストリーに TLS がない場合は、コンテナーディスクを永続ストレージにインポートする前に非セキュアなレジストリーとしてこれを追加する必要があります。
7.18.15.3. 非セキュアなレジストリーとして使用するコンテナーレジストリーの TLS の無効化
レジストリーを cdi-insecure-registries
設定マップに追加することで、コンテナーレジストリーの TLS (トランスポート層セキュリティー) を無効にできます。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにログインすること。
手順
openshift-cnv
namespace のcdi-insecure-registries
設定マップにレジストリーを追加します。$ oc patch configmap cdi-insecure-registries -n openshift-cnv \ --type merge -p '{"data":{"mykey": "<insecure-registry-host>:5000"}}' 1
- 1
<insecure-registry-host>
をレジストリーのホスト名に置き換えます。
7.18.15.4. 次のステップ
- コンテナーディスクを仮想マシンの永続ストレージにインポート します。
-
一時ストレージの
containerDisk
ボリュームを使用する 仮想マシンを作成 します。
7.18.16. CDI のスクラッチ領域の用意
7.18.16.1. データボリュームについて
DataVolume
オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは OpenShift Virtualization に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。
7.18.16.2. スクラッチ領域について
Containerized Data Importer (CDI) では、仮想マシンイメージのインポートやアップロードなどの、一部の操作を実行するためにスクラッチ領域 (一時ストレージ) が必要になります。このプロセスで、CDI は、宛先データボリューム (DV) をサポートする PVC のサイズと同じサイズのスクラッチ領域 PVC をプロビジョニングします。スクラッチ領域 PVC は操作の完了または中止後に削除されます。
CDI
オブジェクトの spec.config.scratchSpaceStorageClass
フィールドでスクラッチ領域 PVC をバインドするために使用されるストレージクラスを定義できます。
定義されたストレージクラスがクラスターのストレージクラスに一致しない場合、クラスターに定義されたデフォルトのストレージクラス が使用されます。クラスターで定義されたデフォルトのストレージクラスがない場合、元の DV または PVC のプロビジョニングに使用されるストレージクラスが使用されます。
CDI では、元のデータボリュームをサポートする PVC の種類を問わず、file
ボリュームモードが設定されているスクラッチ領域が必要です。元の PVC が block
ボリュームモードでサポートされる場合、 file
ボリュームモード PVC をプロビジョニングできるストレージクラスを定義する必要があります。
手動プロビジョニング
ストレージクラスがない場合、CDI はイメージのサイズ要件に一致するプロジェクトの PVC を使用します。これらの要件に一致する PVC がない場合、CDI インポート Pod は適切な PVC が利用可能になるまで、またはタイムアウト機能が Pod を強制終了するまで Pending 状態になります。
7.18.16.3. スクラッチ領域を必要とする CDI 操作
Type | 理由 |
---|---|
レジストリーのインポート | CDI はイメージをスクラッチ領域にダウンロードし、イメージファイルを見つけるためにレイヤーを抽出する必要があります。その後、raw ディスクに変換するためにイメージファイルが QEMU-img に渡されます。 |
イメージのアップロード | QEMU-IMG は STDIN の入力を受け入れません。代わりに、アップロードするイメージは、変換のために QEMU-IMG に渡される前にスクラッチ領域に保存されます。 |
アーカイブされたイメージの HTTP インポート | QEMU-IMG は、CDI がサポートするアーカイブ形式の処理方法を認識しません。イメージが QEMU-IMG に渡される前にアーカイブは解除され、スクラッチ領域に保存されます。 |
認証されたイメージの HTTP インポート | QEMU-IMG が認証を適切に処理しません。イメージが QEMU-IMG に渡される前にスクラッチ領域に保存され、認証されます。 |
カスタム証明書の HTTP インポート | QEMU-IMG は HTTPS エンドポイントのカスタム証明書を適切に処理しません。代わりに CDI は、ファイルを QEMU-IMG に渡す前にイメージをスクラッチ領域にダウンロードします。 |
7.18.16.4. CDI オブジェクトでのストレージクラスの定義
CDI
オブジェクトでストレージクラスを定義し、CDI 操作のスクラッチ領域を動的にプロビジョニングします。
前提条件
-
OpenShift CLI (
oc
) をインストールすること。
手順
oc
クライアントを使用してCDI
オブジェクトを編集します。$ oc edit cdi
spec.config.scratchSpaceStorageClass
フィールドを、クラスターのストレージクラスに一致するように編集します。apiVersion: cdi.kubevirt.io/v1beta1 kind: CDI ... spec: config: scratchSpaceStorageClass: "<storage_class>" 1 ...
- 1
<storage_class>
を、クラスター内の CDI 操作のスクラッチ領域をプロビジョニングするために使用するストレージクラスに置き換えます。
-
デフォルトエディターを保存し、終了して
CDI
オブジェクトを更新します。
7.18.16.5. CDI がサポートする操作マトリックス
このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。
コンテンツタイプ | HTTP | HTTPS | HTTP Basic 認証 | レジストリー | アップロード |
---|---|---|---|---|---|
kubevirt (QCOW2) |
✓ QCOW2 |
✓ QCOW2** |
✓ QCOW2 |
✓ QCOW2* |
✓ QCOW2* |
KubeVirt (RAW) |
✓ RAW |
✓ RAW |
✓ RAW |
✓ RAW* |
✓ RAW* |
✓ サポートされる操作
□ サポートされない操作
* スクラッチ領域が必要
**カスタム認証局が必要な場合にスクラッチ領域が必要
関連情報
- ストレージクラスおよびこれらがクラスターで定義される方法についての詳細は、動的プロビジョニング セクションを参照してください。
7.18.17. 永続ボリュームの再利用
静的にプロビジョニングされた永続ボリューム (PV) を再利用するには、まずボリュームを回収する必要があります。これには、ストレージ設定を再利用できるように PV を削除する必要があります。
7.18.17.1. 静的にプロビジョニングされた永続ボリュームの回収について
永続ボリューム (PV) を回収する場合、PV のバインドを永続ボリューム要求 (PVC) から解除し、PV を削除します。基礎となるストレージによっては、共有ストレージを手動で削除する必要がある場合があります。
次に、PV 設定を再利用し、異なる名前の PV を作成できます。
静的にプロビジョニングされる PV には、回収に Retain
の回収 (reclaim) ポリシーが必要です。これがない場合、PV は PVC が PV からのバインド解除時に failed 状態になります。
Recycle
回収ポリシーは OpenShift Container Platform 4 では非推奨となっています。
7.18.17.2. 静的にプロビジョニングされた永続ボリュームの回収
永続ボリューム要求 (PVC) のバインドを解除し、PV を削除して静的にプロビジョニングされた永続ボリューム (PV) を回収します。共有ストレージを手動で削除する必要がある場合もあります。
静的にプロビジョニングされる PV の回収方法は、基礎となるストレージによって異なります。この手順では、ストレージに応じてカスタマイズする必要がある可能性のある一般的な方法を示します。
手順
PV の回収ポリシーが
Retain
に設定されていることを確認します。PV の回収ポリシーを確認します。
$ oc get pv <pv_name> -o yaml | grep 'persistentVolumeReclaimPolicy'
persistentVolumeReclaimPolicy
がRetain
に設定されていない場合、以下のコマンドで回収ポリシーを編集します。$ oc patch pv <pv_name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
PV を使用しているリソースがないことを確認します。
$ oc describe pvc <pvc_name> | grep 'Mounted By:'
PVC を使用するリソースをすべて削除してから継続します。
PVC を削除して PV を解放します。
$ oc delete pvc <pvc_name>
オプション: PV 設定を YAML ファイルにエクスポートします。この手順の後半で共有ストレージを手動で削除する場合は、この設定を参照してください。このファイルで
spec
パラメーターをベースとして使用し、PV の回収後に同じストレージ設定で新規 PV を作成することもできます。$ oc get pv <pv_name> -o yaml > <file_name>.yaml
PV を削除します。
$ oc delete pv <pv_name>
オプション: ストレージタイプによっては、共有ストレージフォルダーの内容を削除する必要がある場合があります。
$ rm -rf <path_to_share_storage>
オプション: 削除された PV と同じストレージ設定を使用する PV を作成します。回収された PV 設定をすでにエクスポートしている場合、そのファイルの
spec
パラメーターを新規 PV マニフェストのベースとして使用することができます。注記競合の可能性を回避するには、新規 PV オブジェクトに削除されたものとは異なる名前を割り当てることが推奨されます。
$ oc create -f <new_pv_name>.yaml
関連情報
- 仮想マシンのローカルストレージの設定
- OpenShift Container Platform Storage ドキュメントには、永続ストレージ についての詳細情報が記載されています。
7.18.18. データボリュームの削除
oc
コマンドラインインターフェイスを使用して、データボリュームを手動で削除できます。
仮想マシンを削除する際に、これが使用するデータボリュームは自動的に削除されます。
7.18.18.1. データボリュームについて
DataVolume
オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは OpenShift Virtualization に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。
7.18.18.2. すべてのデータボリュームの一覧表示
oc
コマンドラインインターフェイスを使用して、クラスターのデータボリュームを一覧表示できます。
手順
以下のコマンドを実行して、データボリュームを一覧表示します。
$ oc get dvs
7.18.18.3. データボリュームの削除
oc
コマンドラインインターフェイス (CLI) を使用してデータボリュームを削除できます。
前提条件
- 削除する必要のあるデータボリュームの名前を特定すること。
手順
以下のコマンドを実行し、データボリューム を削除します。
$ oc delete dv <datavolume_name>
注記このコマンドは、現在のプロジェクトに存在するオブジェクトのみを削除します。削除する必要のあるオブジェクトが別のプロジェクトまたは namespace にある場合、
-n <project_name>
オプションを指定します。