10.16. 仮想マシンのインポート
10.16.1. データボリュームインポートの TLS 証明書
10.16.1.1. データボリュームインポートの認証に使用する TLS 証明書の追加
ソースからデータをインポートするには、レジストリーまたは HTTPS エンドポイントの TLS 証明書を設定マップに追加する必要があります。この設定マップは、宛先データボリュームの namespace に存在する必要があります。
TLS 証明書の相対パスを参照して設定マップ を作成します。
手順
正しい namespace にあることを確認します。設定マップは、同じ namespace にある場合にデータボリュームによってのみ参照されます。
$ oc get ns
設定マップを作成します。
$ oc create configmap <configmap-name> --from-file=</path/to/file/ca.pem>
10.16.1.2. 例: TLS 証明書から作成される設定マップ
以下は、ca.pem
TLS 証明書で作成される設定マップの例です。
apiVersion: v1 kind: ConfigMap metadata: name: tls-certs data: ca.pem: | -----BEGIN CERTIFICATE----- ... <base64 encoded cert> ... -----END CERTIFICATE-----
10.16.2. データボリュームの使用による仮想マシンイメージのインポート
既存の仮想マシンイメージは OpenShift Container Platform クラスターストレージにインポートできます。Containerized Data Importer (CDI) を使用すると、データボリュームを使用してイメージを永続ボリューム要求 (PVC) にインポートできます。OpenShift Virtualization は 1 つ以上のデータボリュームを使用して、データのインポートと基盤となる PVC の作成を自動化します。次に、データボリュームを永続ストレージの仮想マシンに割り当てることができます。
仮想マシンイメージは、HTTP または HTTPS エンドポイントでホストするか、コンテナーディスクに組み込み、コンテナーレジストリーで保存できます。
ディスクイメージを PVC にインポートする際に、ディスクイメージは PVC で要求されるストレージの全容量を使用するように拡張されます。この領域を使用するには、仮想マシンのディスクパーティションおよびファイルシステムの拡張が必要になる場合があります。
サイズ変更の手順は、仮想マシンにインストールされるオペレーティングシステムによって異なります。詳細は、該当するオペレーティングシステムのドキュメントを参照してください。
10.16.2.1. 前提条件
- エンドポイントに TLS 証明書が必要な場合、TLS 証明書がデータボリュームと同じ namespace の config map に組み込まれていて、データボリューム設定で参照されている。
コンテナーディスクをインポートするには、以下を実行すること。
- 仮想マシンイメージからコンテナーディスクを準備 し、これをコンテナーレジストリーに保存してからインポートする必要がある場合があります。
-
コンテナーレジストリーに TLS がない場合、レジストリーを
HyperConverged
カスタムリソースのinsecureRegistries
フィールドに追加 し、ここからコンテナーディスクをインポートできます。
- この操作を正常に完了するためには、ストレージクラスを定義するか、CDI スクラッチ領域を用意 しなければならない場合があります。
データボリュームを含むブロックストレージに仮想マシンイメージをインポートする場合は、使用可能なローカルブロック永続ボリュームが必要です。
10.16.2.2. CDI がサポートする操作マトリックス
このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。
コンテンツタイプ | HTTP | HTTPS | HTTP Basic 認証 | レジストリー | アップロード |
---|---|---|---|---|---|
KubeVirt (QCOW2) |
✓ QCOW2 |
✓ QCOW2** |
✓ QCOW2 |
✓ QCOW2* |
✓ QCOW2* |
KubeVirt (RAW) |
✓ RAW |
✓ RAW |
✓ RAW |
✓ RAW* |
✓ RAW* |
✓ サポートされる操作
□ サポートされない操作
* スクラッチ領域が必要
**カスタム認証局が必要な場合にスクラッチ領域が必要
CDI は OpenShift Container Platform の クラスター全体のプロキシー設定 を使用するようになりました。
10.16.2.3. データボリュームについて
DataVolume
オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは、スタンドアロンリソースとして、または仮想マシン (VM) 仕様の dataVolumeTemplate
フィールドを使用して作成できます。
-
スタンドアロンデータボリュームを使用して準備した仮想マシンディスクの PVC は、仮想マシンから独立したライフサイクルを維持します。仮想マシン仕様の
dataVolumeTemplate
フィールドを使用して PVC を準備すると、PVC は仮想マシンと同じライフサイクルを共有します。
10.16.2.4. ローカルブロック永続ボリューム
データボリュームを含むブロックストレージに仮想マシンイメージをインポートする場合は、使用可能なローカルブロック永続ボリュームが必要です。
10.16.2.4.1. ブロック永続ボリュームについて
ブロック永続ボリューム (PV) は、raw ブロックデバイスによってサポートされる PV です。これらのボリュームにはファイルシステムがなく、オーバーヘッドを削減することで、仮想マシンのパフォーマンス上の利点をもたらすことができます。
raw ブロックボリュームは、PV および永続ボリューム要求 (PVC) 仕様で volumeMode: Block
を指定してプロビジョニングされます。
10.16.2.4.2. ローカルブロック永続ボリュームの作成
データボリュームを含むブロックストレージに仮想マシンイメージをインポートする場合は、使用可能なローカルブロック永続ボリュームが必要です。
ファイルにデータを設定し、これをループデバイスとしてマウントすることにより、ノードでローカルブロック永続ボリューム (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
- 直前の手順で作成された永続ボリュームのファイル名。
10.16.2.5. データボリュームを使用して仮想マシンイメージをストレージにインポートする
データボリュームを使用して、仮想マシンイメージをストレージにインポートできます。
仮想マシンイメージは、HTTP または HTTPS エンドポイントでホストするか、イメージをコンテナーディスクに組み込み、コンテナーレジストリーで保存できます。
イメージのデータソースは、VirtualMachine
設定ファイルで指定します。仮想マシンが作成されると、仮想マシンイメージを含むデータボリュームがストレージにインポートされます。
前提条件
仮想マシンイメージをインポートするには、以下が必要である。
-
RAW、ISO、または QCOW2 形式の仮想マシンディスクイメージ (オプションで
xz
またはgz
を使用して圧縮される)。 - データソースにアクセスするために必要な認証情報と共にイメージがホストされる HTTP または HTTPS エンドポイント
-
RAW、ISO、または QCOW2 形式の仮想マシンディスクイメージ (オプションで
- コンテナーディスクをインポートするには、仮想マシンイメージをコンテナーディスクに組み込み、データソースにアクセスするために必要な認証クレデンシャルとともにコンテナーレジストリーに保存する必要があります。
- 仮想マシンが自己署名証明書またはシステム CA バンドルによって署名されていない証明書を使用するサーバーと通信する必要がある場合は、データボリュームと同じ namespace に config map を作成する必要があります。
手順
データソースに認証が必要な場合は、データソースのクレデンシャルを指定して
Secret
マニフェストを作成し、endpoint-secret.yaml
として保存します。apiVersion: v1 kind: Secret metadata: name: endpoint-secret 1 labels: app: containerized-data-importer type: Opaque data: accessKeyId: "" 2 secretKey: "" 3
Secret
マニフェストを適用します。$ oc apply -f endpoint-secret.yaml
VirtualMachine
マニフェストを編集し、インポートする仮想マシンイメージのデータソースを指定して、vm-fedora-datavolume.yaml
として保存します。apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: creationTimestamp: null labels: kubevirt.io/vm: vm-fedora-datavolume name: vm-fedora-datavolume 1 spec: dataVolumeTemplates: - metadata: creationTimestamp: null name: fedora-dv 2 spec: storage: volumeMode: Block 3 resources: requests: storage: 10Gi storageClassName: local source: 4 http: url: "https://mirror.arizona.edu/fedora/linux/releases/35/Cloud/x86_64/images/Fedora-Cloud-Base-35-1.2.x86_64.qcow2" 5 secretRef: endpoint-secret 6 certConfigMap: "" 7 # To use a registry source, uncomment the following lines and delete the preceding HTTP source block # registry: # url: "docker://kubevirt/fedora-cloud-container-disk-demo:latest" # secretRef: registry-secret 8 # certConfigMap: "" 9 status: {} running: true template: metadata: creationTimestamp: null labels: kubevirt.io/vm: vm-fedora-datavolume spec: domain: devices: disks: - disk: bus: virtio name: datavolumedisk1 machine: type: "" resources: requests: memory: 1.5Gi terminationGracePeriodSeconds: 180 volumes: - dataVolume: name: fedora-dv name: datavolumedisk1 status: {}
- 1
- 仮想マシンの名前を指定します。
- 2
- データボリュームの名前を指定します。
- 3
- ボリュームおよびアクセスモードは、既知のストレージプロビジョナーに対して自動的に検出されます。または、
Block
を指定できます。 - 4 5
- コメントブロックを使用して、インポートする仮想マシンイメージの URL またはレジストリーエンドポイントを指定します。たとえば、レジストリーソースを使用する場合は、HTTP または HTTPS ソースブロックをコメントアウトするか削除できます。ここに示されている例の値は、必ず実際の値に置き換えてください。
- 6 8
- データソースの
Secret
を作成した場合は、Secret
名を指定します。 - 7 9
- オプション: CA 証明書 config map を指定します。
仮想マシンを作成します。
$ oc create -f vm-fedora-datavolume.yaml
注記oc create
コマンドは、データボリュームおよび仮想マシンを作成します。CDI コントローラーは適切なアノテーションを使用して基礎となる PVC を作成し、インポートプロセスが開始されます。インポートが完了すると、データボリュームのステータスがSucceeded
に変わります。仮想マシンを起動できます。データボリュームのプロビジョニングはバックグランドで実行されるため、これをプロセスをモニターする必要はありません。
検証
インポーター Pod は指定された URL から仮想マシンイメージまたはコンテナーディスクをダウンロードし、これをプロビジョニングされた PV に保存します。以下のコマンドを実行してインポーター Pod のステータスを確認します。
$ oc get pods
次のコマンドを実行して、ステータスが
Succeeded
になるまでデータボリュームを監視します。$ oc describe dv fedora-dv 1
- 1
VirtualMachine
マニフェストで定義したデータボリューム名を指定します。
シリアルコンソールにアクセスして、プロビジョニングが完了し、仮想マシンが起動したことを確認します。
$ virtctl console vm-fedora-datavolume
10.16.2.6. 関連情報
- 事前割り当てモードを設定 して、データボリューム操作の書き込みパフォーマンスを向上させます。