7.16. 仮想マシンのクローン作成
7.16.1. 複数の namespace 間でデータボリュームをクローン作成するためのユーザーパーミッションの有効化
namespace には相互に分離する性質があるため、ユーザーはデフォルトでは namespace をまたがってリソースのクローンを作成することができません。
ユーザーが仮想マシンのクローンを別の namespace に作成できるようにするには、cluster-admin
ロールを持つユーザーが新規のクラスターロールを作成する必要があります。このクラスターロールをユーザーにバインドし、それらのユーザーが仮想マシンのクローンを宛先 namespace に対して作成できるようにします。
7.16.1.1. 前提条件
-
cluster-admin
ロールを持つユーザーのみがクラスターロールを作成できること。
7.16.1.2. データボリュームについて
DataVolume
オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは OpenShift Virtualization に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。
7.16.1.3. データボリュームのクローン作成のための RBAC リソースの作成
datavolumes
リソースのすべてのアクションのパーミッションを有効にする新規のくスターロールを作成します。
手順
ClusterRole
マニフェストを作成します。apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: <datavolume-cloner> 1 rules: - apiGroups: ["cdi.kubevirt.io"] resources: ["datavolumes/source"] verbs: ["*"]
- 1
- クラスターロールの一意の名前。
クラスターにクラスターロールを作成します。
$ oc create -f <datavolume-cloner.yaml> 1
- 1
- 直前の手順で作成された
ClusterRole
マニフェストのファイル名です。
移行元および宛先 namespace の両方に適用される
RoleBinding
マニフェストを作成し、直前の手順で作成したクラスターロールを参照します。apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: <allow-clone-to-user> 1 namespace: <Source namespace> 2 subjects: - kind: ServiceAccount name: default namespace: <Destination namespace> 3 roleRef: kind: ClusterRole name: datavolume-cloner 4 apiGroup: rbac.authorization.k8s.io
クラスターにロールバインディングを作成します。
$ oc create -f <datavolume-cloner.yaml> 1
- 1
- 直前の手順で作成された
RoleBinding
マニフェストのファイル名です。
7.16.2. 新規データボリュームへの仮想マシンディスクのクローン作成
データボリューム設定ファイルでソース PVC を参照し、新規データボリュームに仮想マシンディスクの永続ボリューム要求 (PVC) のクローンを作成できます。
異なるボリュームモード間でのクローン作成操作はサポートされていません。volumeMode
の値は、ソースとターゲットの両方の仕様で一致している必要があります。
たとえば、volumeMode: Block
の永続ボリューム (PV) から volumeMode: Filesystem
の PV へのクローン作成を試行する場合、操作はエラーメッセージを出して失敗します。
7.16.2.1. 前提条件
- ユーザーは、仮想マシンディスクの PVC のクローンを別の namespace に作成するために 追加のパーミッション が必要である。
7.16.2.2. データボリュームについて
DataVolume
オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは OpenShift Virtualization に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。
7.16.2.3. 新規データボリュームへの仮想マシンディスクの永続ボリューム要求 (PVC) のクローン作成
既存の仮想マシンディスクの永続ボリューム要求 (PVC) のクローンを新規データボリュームに作成できます。その後、新規データボリュームは新規の仮想マシンに使用できます。
データボリュームが仮想マシンとは別に作成される場合、データボリュームのライフサイクルは仮想マシンから切り離されます。仮想マシンが削除されても、データボリュームもその関連付けられた PVC も削除されません。
前提条件
- 使用する既存の仮想マシンディスクの PVC を判別すること。クローン作成の前に、PVC に関連付けられた仮想マシンの電源を切る必要があります。
-
OpenShift CLI (
oc
) をインストールしている。
手順
- 関連付けられた PVC の名前および namespace を特定するために、クローン作成に必要な仮想マシンディスクを確認します。
新規データボリュームの名前、ソース PVC の名前および namespace、および新規データボリュームのサイズを指定するデータボリュームの YAML ファイルを作成します。
以下に例を示します。
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: - ReadWriteOnce resources: requests: storage: <2Gi> 4
データボリュームを作成して PVC のクローン作成を開始します。
$ oc create -f <cloner-datavolume>.yaml
注記データボリュームは仮想マシンが PVC の作成前に起動することを防ぐため、PVC のクローン作成中に新規データボリュームを参照する仮想マシンを作成できます。
7.16.2.4. テンプレート: データボリュームクローン設定ファイル
example-clone-dv.yaml
apiVersion: cdi.kubevirt.io/v1beta1 kind: DataVolume metadata: name: "example-clone-dv" spec: source: pvc: name: source-pvc namespace: example-ns pvc: accessModes: - ReadWriteOnce resources: requests: storage: "1G"
7.16.2.5. CDI がサポートする操作マトリックス
このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。
コンテンツタイプ | HTTP | HTTPS | HTTP Basic 認証 | レジストリー | アップロード |
---|---|---|---|---|---|
kubevirt (QCOW2) |
✓ QCOW2 |
✓ QCOW2** |
✓ QCOW2 |
✓ QCOW2* |
✓ QCOW2* |
KubeVirt (RAW) |
✓ RAW |
✓ RAW |
✓ RAW |
✓ RAW* |
✓ RAW* |
✓ サポートされる操作
□ サポートされない操作
* スクラッチ領域が必要
**カスタム認証局が必要な場合にスクラッチ領域が必要
7.16.3. データボリュームテンプレートの使用による仮想マシンのクローン作成
既存の仮想マシンの永続ボリューム要求 (PVC) のクローン作成により、新規の仮想マシンを作成できます。dataVolumeTemplate
を仮想マシン設定ファイルに含めることにより、元の PVC から新規のデータボリュームを作成します。
異なるボリュームモード間でのクローン作成操作はサポートされていません。volumeMode
の値は、ソースとターゲットの両方の仕様で一致している必要があります。
たとえば、volumeMode: Block
の永続ボリューム (PV) から volumeMode: Filesystem
の PV へのクローン作成を試行する場合、操作はエラーメッセージを出して失敗します。
7.16.3.1. 前提条件
- ユーザーは、仮想マシンディスクの PVC のクローンを別の namespace に作成するために 追加のパーミッション が必要である。
7.16.3.2. データボリュームについて
DataVolume
オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは OpenShift Virtualization に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。
7.16.3.3. データボリュームテンプレートの使用による、クローン作成された永続ボリューム要求 (PVC) からの仮想マシンの新規作成
既存の仮想マシンの永続ボリューム要求 (PVC) のクローンをデータボリュームに作成する仮想マシンを作成できます。仮想マシンマニフェストの dataVolumeTemplate
を参照することにより、source
PVC のクローンがデータボリュームに作成され、これは次に仮想マシンを作成するために自動的に使用されます。
データボリュームが仮想マシンのデータボリュームテンプレートの一部として作成されると、データボリュームのライフサイクルは仮想マシンに依存します。つまり、仮想マシンが削除されると、データボリュームおよび関連付けられた PVC も削除されます。
前提条件
- 使用する既存の仮想マシンディスクの PVC を判別すること。クローン作成の前に、PVC に関連付けられた仮想マシンの電源を切る必要があります。
-
OpenShift CLI (
oc
) をインストールしている。
手順
- 関連付けられた PVC の名前および namespace を特定するために、クローン作成に必要な仮想マシンを確認します。
VirtualMachine
オブジェクトの YAML ファイルを作成します。以下の仮想マシンのサンプルでは、source-namespace
namespace にあるmy-favorite-vm-disk
のクローンを作成します。favorite-clone
という2Gi
データはmy-favorite-vm-disk
から作成されます。以下に例を示します。
apiVersion: kubevirt.io/v1alpha3 kind: VirtualMachine metadata: labels: kubevirt.io/vm: vm-dv-clone name: vm-dv-clone 1 spec: running: false template: metadata: labels: kubevirt.io/vm: vm-dv-clone spec: domain: devices: disks: - disk: bus: virtio name: root-disk resources: requests: memory: 64M volumes: - dataVolume: name: favorite-clone name: root-disk dataVolumeTemplates: - metadata: name: favorite-clone spec: pvc: accessModes: - ReadWriteOnce resources: requests: storage: 2Gi source: pvc: namespace: "source-namespace" name: "my-favorite-vm-disk"
- 1
- 作成する仮想マシン。
PVC のクローンが作成されたデータボリュームで仮想マシンを作成します。
$ oc create -f <vm-clone-datavolumetemplate>.yaml
7.16.3.4. テンプレート: データボリューム仮想マシン設定ファイル
example-dv-vm.yaml
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachine
metadata:
labels:
kubevirt.io/vm: example-vm
name: example-vm
spec:
dataVolumeTemplates:
- metadata:
name: example-dv
spec:
pvc:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1G
source:
http:
url: "" 1
running: false
template:
metadata:
labels:
kubevirt.io/vm: example-vm
spec:
domain:
cpu:
cores: 1
devices:
disks:
- disk:
bus: virtio
name: example-dv-disk
machine:
type: q35
resources:
requests:
memory: 1G
terminationGracePeriodSeconds: 0
volumes:
- dataVolume:
name: example-dv
name: example-dv-disk
- 1
- インポートする必要のあるイメージの
HTTP
ソース (該当する場合)。
7.16.3.5. CDI がサポートする操作マトリックス
このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。
コンテンツタイプ | HTTP | HTTPS | HTTP Basic 認証 | レジストリー | アップロード |
---|---|---|---|---|---|
kubevirt (QCOW2) |
✓ QCOW2 |
✓ QCOW2** |
✓ QCOW2 |
✓ QCOW2* |
✓ QCOW2* |
KubeVirt (RAW) |
✓ RAW |
✓ RAW |
✓ RAW |
✓ RAW* |
✓ RAW* |
✓ サポートされる操作
□ サポートされない操作
* スクラッチ領域が必要
**カスタム認証局が必要な場合にスクラッチ領域が必要
7.16.4. 新規ブロックストレージデータボリュームへの仮想マシンディスクのクローン作成
データボリューム設定ファイルでソース PVC を参照し、新規ブロックデータボリュームに仮想マシンディスクの永続ボリューム要求 (PVC) のクローンを作成できます。
異なるボリュームモード間でのクローン作成操作はサポートされていません。volumeMode
の値は、ソースとターゲットの両方の仕様で一致している必要があります。
たとえば、volumeMode: Block
の永続ボリューム (PV) から volumeMode: Filesystem
の PV へのクローン作成を試行する場合、操作はエラーメッセージを出して失敗します。
7.16.4.1. 前提条件
- ユーザーは、仮想マシンディスクの PVC のクローンを別の namespace に作成するために 追加のパーミッション が必要である。
7.16.4.2. データボリュームについて
DataVolume
オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは OpenShift Virtualization に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。
7.16.4.3. ブロック永続ボリュームについて
ブロック永続ボリューム (PV) は、raw ブロックデバイスによってサポートされる PV です。これらのボリュームにはファイルシステムがなく、オーバーヘッドを削減することで、仮想マシンのパフォーマンス上の利点をもたらすことができます。
raw ブロックボリュームは、PV および永続ボリューム要求 (PVC) 仕様で volumeMode: Block
を指定してプロビジョニングされます。
7.16.4.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.16.4.5. 新規データボリュームへの仮想マシンディスクの永続ボリューム要求 (PVC) のクローン作成
既存の仮想マシンディスクの永続ボリューム要求 (PVC) のクローンを新規データボリュームに作成できます。その後、新規データボリュームは新規の仮想マシンに使用できます。
データボリュームが仮想マシンとは別に作成される場合、データボリュームのライフサイクルは仮想マシンから切り離されます。仮想マシンが削除されても、データボリュームもその関連付けられた PVC も削除されません。
前提条件
- 使用する既存の仮想マシンディスクの PVC を判別すること。クローン作成の前に、PVC に関連付けられた仮想マシンの電源を切る必要があります。
-
OpenShift CLI (
oc
) をインストールしている。 - ソース PVC と同じか、またはこれよりも大きい 1 つ以上の利用可能なブロック永続ボリューム (PV)。
手順
- 関連付けられた PVC の名前および namespace を特定するために、クローン作成に必要な仮想マシンディスクを確認します。
新規データボリュームの名前、ソース PVC の名前および namespace、利用可能なブロック PV を使用できるようにするために
volumeMode: Block
、および新規データボリュームのサイズを指定するデータボリュームの YAML ファイルを作成します。以下に例を示します。
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: - ReadWriteOnce resources: requests: storage: <2Gi> 4 volumeMode: Block 5
データボリュームを作成して PVC のクローン作成を開始します。
$ oc create -f <cloner-datavolume>.yaml
注記データボリュームは仮想マシンが PVC の作成前に起動することを防ぐため、PVC のクローン作成中に新規データボリュームを参照する仮想マシンを作成できます。
7.16.4.6. CDI がサポートする操作マトリックス
このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。
コンテンツタイプ | HTTP | HTTPS | HTTP Basic 認証 | レジストリー | アップロード |
---|---|---|---|---|---|
kubevirt (QCOW2) |
✓ QCOW2 |
✓ QCOW2** |
✓ QCOW2 |
✓ QCOW2* |
✓ QCOW2* |
KubeVirt (RAW) |
✓ RAW |
✓ RAW |
✓ RAW |
✓ RAW* |
✓ RAW* |
✓ サポートされる操作
□ サポートされない操作
* スクラッチ領域が必要
**カスタム認証局が必要な場合にスクラッチ領域が必要