7.15. 仮想マシンのインポート
7.15.1. データボリュームインポートの TLS 証明書
7.15.1.1. データボリュームインポートの認証に使用する TLS 証明書の追加
ソースからデータをインポートするには、レジストリーまたは HTTPS エンドポイントの TLS 証明書を設定マップに追加する必要があります。この設定マップは、宛先データボリュームの namespace に存在する必要があります。
TLS 証明書の相対パスを参照して設定マップ を作成します。
手順
正しい namespace にあることを確認します。設定マップは、同じ namespace にある場合にデータボリュームによってのみ参照されます。
$ oc get ns
設定マップを作成します。
$ oc create configmap <configmap-name> --from-file=</path/to/file/ca.pem>
7.15.1.2. 例: TLS 証明書から作成される設定マップ
以下は、ca.pem
TLS 証明書で作成される設定マップの例です。
apiVersion: v1 kind: ConfigMap metadata: name: tls-certs data: ca.pem: | -----BEGIN CERTIFICATE----- ... <base64 encoded cert> ... -----END CERTIFICATE-----
7.15.2. データボリュームの使用による仮想マシンイメージのインポート
Containerized Data Importer (CDI) を使用し、データボリュームを使用して仮想マシンイメージを永続ボリューム要求 (PVC) にインポートします。次に、データボリュームを永続ストレージの仮想マシンに割り当てることができます。
仮想マシンイメージは、HTTP または HTTPS エンドポイントでホストするか、またはコンテナーディスクに組み込み、コンテナーレジストリーで保存できます。
ディスクイメージを PVC にインポートする際に、ディスクイメージは PVC で要求されるストレージの全容量を使用するように拡張されます。この領域を使用するには、仮想マシンのディスクパーティションおよびファイルシステムの拡張が必要になる場合があります。
サイズ変更の手順は、仮想マシンにインストールされるオペレーティングシステムによって異なります。詳細は、該当するオペレーティングシステムのドキュメントを参照してください。
7.15.2.1. 前提条件
- エンドポイントに TLS 証明書が必要な場合、証明書はデータボリュームと同じ namespace の 設定マップ に組み込む 必要があり、これはデータボリューム設定で参照されること。
コンテナーディスクをインポートするには、以下を実行すること。
- 仮想マシンイメージからコンテナーディスクを準備 し、これをコンテナーレジストリーに保存してからインポートする必要がある場合があります。
-
コンテナーレジストリーに TLS がない場合、レジストリーを
cdi-insecure-registries
設定マップに追加 し、ここからコンテナーディスクをインポートする必要があります。
- この操作を正常に実行するためには、ストレージクラスを定義するか、または CDI のスクラッチ領域を用意 する必要がある場合がある。
7.15.2.2. CDI がサポートする操作マトリックス
このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。
コンテンツタイプ | HTTP | HTTPS | HTTP Basic 認証 | レジストリー | アップロード |
---|---|---|---|---|---|
kubevirt (QCOW2) |
✓ QCOW2 |
✓ QCOW2** |
✓ QCOW2 |
✓ QCOW2* |
✓ QCOW2* |
KubeVirt (RAW) |
✓ RAW |
✓ RAW |
✓ RAW |
✓ RAW* |
✓ RAW* |
✓ サポートされる操作
□ サポートされない操作
* スクラッチ領域が必要
**カスタム認証局が必要な場合にスクラッチ領域が必要
7.15.2.3. データボリュームについて
DataVolume
オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは OpenShift Virtualization に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。
7.15.2.4. データボリュームを使用して仮想マシンイメージをストレージにインポートする
データボリュームを使用して、仮想マシンイメージをストレージにインポートできます。
仮想マシンイメージは、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/v1alpha3 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: resources: requests: storage: 10Gi storageClassName: local source: http: 3 url: "https://mirror.arizona.edu/fedora/linux/releases/35/Cloud/x86_64/images/Fedora-Cloud-Base-35-1.2.x86_64.qcow2" 4 secretRef: endpoint-secret 5 certConfigMap: "" 6 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: 60 volumes: - dataVolume: name: fedora-dv name: datavolumedisk1 status: {}
- 1
- 仮想マシンの名前を指定します。
- 2
- データボリュームの名前を指定します。
- 3
- HTTP または HTTPS エンドポイントに
http
を指定します。レジストリーからインポートされたコンテナーディスクイメージのregistry
を指定します。 - 4
- インポートする必要のある仮想マシンイメージのソース。この例では、HTTPS エンドポイントで仮想マシンイメージを参照します。コンテナーレジストリーエンドポイントのサンプルは
url: "docker://kubevirt/fedora-cloud-container-disk-demo:latest"
です。 - 5
- データソースの
Secret
を作成した場合は必須です。 - 6
- オプション: 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
7.15.2.5. 関連情報
- 事前割り当てモードを設定 して、データボリューム操作の書き込みパフォーマンスを向上させます。
7.15.3. データボリュームの使用による仮想マシンイメージのブロックストレージへのインポート
既存の仮想マシンイメージは OpenShift Container Platform クラスターにインポートできます。OpenShift Virtualization はデータボリュームを使用してデータのインポートおよび基礎となる永続ボリューム要求 (PVC) の作成を自動化します。
ディスクイメージを PVC にインポートする際に、ディスクイメージは PVC で要求されるストレージの全容量を使用するように拡張されます。この領域を使用するには、仮想マシンのディスクパーティションおよびファイルシステムの拡張が必要になる場合があります。
サイズ変更の手順は、仮想マシンにインストールされるオペレーティングシステムによって異なります。詳細は、該当するオペレーティングシステムのドキュメントを参照してください。
7.15.3.1. 前提条件
- CDI でサポートされる操作マトリックス に応じてスクラッチ領域が必要な場合、まずは、この操作が正常に実行されるように ストレージクラスを定義するか、または CDI スクラッチ領域を用意 すること。
7.15.3.2. データボリュームについて
DataVolume
オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは OpenShift Virtualization に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。
7.15.3.3. ブロック永続ボリュームについて
ブロック永続ボリューム (PV) は、raw ブロックデバイスによってサポートされる PV です。これらのボリュームにはファイルシステムがなく、オーバーヘッドを削減することで、仮想マシンのパフォーマンス上の利点をもたらすことができます。
raw ブロックボリュームは、PV および永続ボリューム要求 (PVC) 仕様で volumeMode: Block
を指定してプロビジョニングされます。
7.15.3.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.15.3.5. データボリュームを使用して仮想マシンイメージをブロックストレージにインポートする
データボリュームを使用して、仮想マシンイメージをブロックストレージにインポートできます。仮想マシンを作成する前に、VirtualMachine
マニフェストでデータボリュームを参照します。
前提条件
-
RAW、ISO、または QCOW2 形式の仮想マシンディスクイメージ (オプションで
xz
またはgz
を使用して圧縮される)。 - データソースにアクセスするために必要な認証情報と共にイメージがホストされる HTTP または HTTPS エンドポイント
手順
データソースに認証が必要な場合は、データソースのクレデンシャルを指定して
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
データ
DataVolume
マニフェストを作成し、仮想マシンイメージのデータソースとstorage.volumeMode
のBlock
を指定します。apiVersion: cdi.kubevirt.io/v1beta1 kind: DataVolume metadata: name: import-pv-datavolume 1 spec: storageClassName: local 2 source: http: url: "https://mirror.arizona.edu/fedora/linux/releases/35/Cloud/x86_64/images/Fedora-Cloud-Base-35-1.2.x86_64.qcow2" 3 secretRef: endpoint-secret 4 storage: volumeMode: Block 5 resources: requests: storage: 10Gi
仮想マシンイメージをインポートするために data volume を作成します。
$ oc create -f import-pv-datavolume.yaml
仮想マシンを作成する前に、VirtualMachine
マニフェストでこのデータボリュームを参照できます。
7.15.3.6. CDI がサポートする操作マトリックス
このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。
コンテンツタイプ | HTTP | HTTPS | HTTP Basic 認証 | レジストリー | アップロード |
---|---|---|---|---|---|
kubevirt (QCOW2) |
✓ QCOW2 |
✓ QCOW2** |
✓ QCOW2 |
✓ QCOW2* |
✓ QCOW2* |
KubeVirt (RAW) |
✓ RAW |
✓ RAW |
✓ RAW |
✓ RAW* |
✓ RAW* |
✓ サポートされる操作
□ サポートされない操作
* スクラッチ領域が必要
**カスタム認証局が必要な場合にスクラッチ領域が必要
7.15.3.7. 関連情報
- 事前割り当てモードを設定 して、データボリューム操作の書き込みパフォーマンスを向上させます。
7.15.4. 単一の Red Hat Virtualization 仮想マシンのインポート
VM Import ウィザードまたは CLI を使用して、単一の Red Hat Virtualization (RHV) 仮想マシンを OpenShift Virtualization にインポートできます。
7.15.4.1. OpenShift Virtualization ストレージ機能マトリクス
以下の表は、仮想マシンのインポートをサポートする OpenShift Virtualization ストレージタイプについて説明しています。
RHV 仮想マシンのインポート | |
---|---|
OpenShift Container Storage: RBD ブロックモードボリューム | Yes |
OpenShift Virtualization ホストパスプロビジョナー | No |
他の複数ノードの書き込み可能なストレージ | ○ [1] |
他の単一ノードの書き込み可能なストレージ | ○ [2] |
- PVC は ReadWriteMany アクセスモードを要求する必要があります。
- PVC は ReadWriteOnce アクセスモードを要求する必要があります。
7.15.4.2. 仮想マシンをインポートするための前提条件
仮想マシンを Red Hat Virtualization (RHV) から OpenShift Virtualization にインポートするには、以下の前提条件を満たす必要があります。
- 管理者ユーザー権限があること。
ストレージ:
- OpenShift Virtualization のローカルおよび共有永続ストレージクラスは、仮想マシンのインポートをサポートする必要があります。
- Ceph RBD ブロックモードのボリュームを使用していて、仮想ディスクに利用可能なストレージ領域が小さすぎると、インポートプロセスバーは 75% で 20 分以上停止し、移行は成功しません。Web コンソールにエラーメッセージは表示されません。BZ#1910019
ネットワーク:
- RHV および OpenShift Virtualization ネットワークは同じ名前を持つか、または相互にマップされる必要があります。
-
RHV 仮想マシンネットワークインターフェイスは
e1000
、rtl8139
、またはvirtio
である必要があります。
仮想マシンディスク:
-
ディスクインターフェイスは
sata
、virtio_scsi
、またはvirtio
である必要があります。 - ディスクは直接の LUN として設定することはできません。
-
ディスクのステータスは
illegal
またはlocked
にすることができません。 -
ストレージタイプは
image
である必要があります。 - SCSI 予約を無効にする必要があります。
-
ScsiGenericIO
を無効にする必要があります。
-
ディスクインターフェイスは
仮想マシンの設定:
- 仮想マシンが GPU リソースを使用する場合は、GPU を提供するノードを設定する必要があります。
- 仮想マシンを vGPU リソース用に設定することはできません。
-
仮想マシンには、
illegal
状態のスナップショットを含めることはできません。 - 仮想マシンは OpenShift Container Platform で作成されから、その後に RHV に追加することはできません。
- 仮想マシンを USB デバイス用に設定することはできません。
-
watchdog モデルは
diag288
にすることができません。
7.15.4.3. VM Import ウィザードを使用した仮想マシンのインポート
VM Import ウィザードを使用して、単一の仮想マシンをインポートできます。
手順
-
Web コンソールで、Workloads
Virtual Machines をクリックします。 - Create Virtual Machine をクリックし、Import with Wizard を選択します。
- Provider 一覧で Red Hat Virtualization (RHV) を選択します。
Connect to New Instance または保存された RHV インスタンスを選択します。
Connect to New Instance を選択する場合は、以下のフィールドに入力します。
-
API URL:
https://<RHV_Manager_FQDN>/ovirt-engine/api
など。 CA certificate: Browse をクリックして RHV Manager CA 証明書をアップロードするか、またはフィールドに CA 証明書を貼り付けます。
以下のコマンドを実行して CA 証明書を表示します。
$ openssl s_client -connect <RHV_Manager_FQDN>:443 -showcerts < /dev/null
CA 証明書は、出力内の 2 番目の証明書です。
-
Username: RHV Manager ユーザー名 (例:
ocpadmin@internal
) - Password: RHV Manager パスワード
-
API URL:
- 保存された RHV インスタンスを選択する場合、ウィザードは保存された認証情報を使用して RHV インスタンスに接続します。
Check and Save をクリックし、接続が完了するまで待ちます。
注記接続の詳細はシークレットに保存されます。正しくない URL、ユーザー名またはパスワードを使用してプロバイダーを追加する場合、Workloads
Secrets をクリックし、プロバイダーのシークレットを削除します。 - クラスターおよび仮想マシンを選択します。
- Next をクリックします。
- Review 画面で、設定を確認します。
- オプション:Start virtual machine on creation を選択します。
Edit をクリックして、以下の設定を更新します。
-
General
Name: 仮想マシン名は 63 文字に制限されます。 General
Description: 仮想マシンの説明 (オプション)。 Storage Class: NFS または ocs-storagecluster-ceph-rbd を選択します。
ocs-storagecluster-ceph-rbd を選択する場合、ディスクの Volume Mode を Block に設定する必要があります。
-
Advanced
Volume Mode: Block を選択します。
-
Advanced
Volume Mode: Block を選択します。 -
Networking
Network: 利用可能なネットワーク割り当て定義オブジェクトの一覧からネットワークを選択できます。
-
General
インポート設定を編集した場合は、Import または Review and Import をクリックします。
Successfully created virtual machine というメッセージが表示され、仮想マシンに作成されたリソースの一覧が表示されます。仮想マシンが Workloads
Virtual Machines に表示されます。
仮想マシンウィザードのフィールド
名前 | パラメーター | 説明 |
---|---|---|
名前 |
この名前には、小文字 ( | |
説明 | オプションの説明フィールド。 | |
Operating System | テンプレートで仮想マシン用に選択される主なオペレーティングシステム。テンプレートから仮想マシンを作成する場合、このフィールドを編集することはできません。 | |
Boot Source | URL を使用したインポート (PVC の作成) | HTTP または HTTPS エンドポイントで利用できるイメージからコンテンツをインポートします。例: オペレーティングシステムイメージのある Web ページから URL リンクを取得します。 |
既存の PVC のクローン作成 (PVC の作成) | クラスターで利用可能な既存の永続ボリューム要求 (PVC) を選択し、これをクローンします。 | |
レジストリーを使用したインポート (PVC の作成) |
クラスターからアクセスできるレジストリーの起動可能なオペレーティングシステムコンテナーから仮想マシンをプロビジョニングします。例: | |
PXE (ネットワークブート: ネットワークインターフェイスの追加) | ネットワークのサーバーからオペレーティングシステムを起動します。PXE ブート可能なネットワーク接続定義が必要です。 | |
永続ボリューム要求 (PVC) のプロジェクト | PVC のクローン作成に使用するプロジェクト名。 | |
永続ボリューム要求 (PVC) の名前 | 既存の PVC のクローンを作成する場合にこの仮想マシンテンプレートに適用する必要のある PVC 名。 | |
これを CD-ROM ブートソースとしてマウントする | CD-ROM には、オペレーティングシステムをインストールするための追加のディスクが必要です。チェックボックスを選択して、ディスクを追加し、後でカスタマイズします。 | |
Flavor | Tiny、Small、Medium、Large、Custom | 仮想マシンに割り当てられる CPU およびメモリーの量を決定するプリセット。Flavor に設定される Preset はオペレーティングシステムによって決まります。 |
Workload Type | Desktop | デスクトップで使用するための仮想マシン設定。小規模な環境での使用に適しています。Web コンソールでの使用に推奨されます。 |
Server | パフォーマンスのバランスを図り、さまざまなサーバーのワークロードと互換性があります。 | |
High-Performance | 高パフォーマンスのワークロードに対して最適化された仮想マシン設定。 | |
作成後にこの仮想マシンを起動します。 | このチェックボックスはデフォルトで選択され、仮想マシンは作成後に実行を開始します。仮想マシンの作成時に起動する必要がない場合は、チェックボックスをクリアします。 |
ネットワークフィールド
名前 | 説明 |
---|---|
名前 | ネットワークインターフェイスコントローラーの名前。 |
モデル | ネットワークインターフェイスコントローラーのモデルを示します。サポートされる値は e1000e および virtio です。 |
ネットワーク | 利用可能なネットワーク接続定義の一覧。 |
Type |
利用可能なバインディングメソッドの一覧。デフォルトの Pod ネットワークについては、 |
MAC Address | ネットワークインターフェイスコントローラーの MAC アドレス。MAC アドレスが指定されていない場合、これは自動的に割り当てられます。 |
ストレージフィールド
名前 | 選択 | 説明 |
---|---|---|
Source | 空白 (PVC の作成) | 空のディスクを作成します。 |
URL を使用したインポート (PVC の作成) | URL (HTTP または HTTPS エンドポイント) を介してコンテンツをインポートします。 | |
既存 PVC の使用 | クラスターですでに利用可能な PVC を使用します。 | |
既存の PVC のクローン作成 (PVC の作成) | クラスターで利用可能な既存の PVC を選択し、このクローンを作成します。 | |
レジストリーを使用したインポート (PVC の作成) | コンテナーレジストリーを使用してコンテンツをインポートします。 | |
コンテナー (一時的) | クラスターからアクセスできるレジストリーにあるコンテナーからコンテンツをアップロードします。コンテナーディスクは、CD-ROM や一時的な仮想マシンなどの読み取り専用ファイルシステムにのみ使用する必要があります。 | |
名前 |
ディスクの名前。この名前には、小文字 ( | |
Size | ディスクのサイズ (GiB 単位)。 | |
Type | ディスクのタイプ。例: Disk または CD-ROM | |
Interface | ディスクデバイスのタイプ。サポートされるインターフェイスは、virtIO、SATA、および SCSI です。 | |
Storage Class | ディスクの作成に使用されるストレージクラス。 | |
Advanced | 永続ボリュームがフォーマットされたファイルシステムまたは raw ブロック状態を使用するかどうかを定義します。デフォルトは Filesystem です。 |
ストレージの詳細設定
名前 | パラメーター | 説明 |
---|---|---|
ボリュームモード | Filesystem | ファイルシステムベースのボリュームで仮想ディスクを保存します。 |
Block |
ブロックボリュームで仮想ディスクを直接保存します。基礎となるストレージがサポートしている場合は、 | |
アクセスモード [1] | Single User (RWO) | ディスクは単一ノードで読み取り/書き込みとしてマウントできます。 |
Shared Access (RWX) | ディスクは数多くのノードで読み取り/書き込みとしてマウントできます。 | |
Read Only (ROX) | ディスクは数多くのノードで読み取り専用としてマウントできます。 |
- コマンドラインインターフェイスを使用してアクセスモードを変更できます。
7.15.4.4. CLI を使用した仮想マシンのインポート
Secret
および VirtualMachineImport
カスタムリソース (CR) を作成して、CLI で仮想マシンをインポートできます。Secret
CR は RHV Manager の認証情報および CA 証明書を保存します。VirtualMachineImport
CR は仮想マシンのインポートプロセスのパラメーターを定義します。
オプション: VirtualMachineImport
CR とは別に ResourceMapping
CR を作成できます。ResourceMapping
CR は、追加の RHV 仮想マシンをインポートする場合などに柔軟性を提供します。
デフォルトのターゲットストレージクラスは NFS である必要があります。Cinder は RHV 仮想マシンのインポートをサポートしません。
手順
以下のコマンドを実行して
Secret
CR を作成します。$ cat <<EOF | oc create -f - apiVersion: v1 kind: Secret metadata: name: rhv-credentials namespace: default 1 type: Opaque stringData: ovirt: | apiUrl: <api_endpoint> 2 username: ocpadmin@internal password: 3 caCert: | -----BEGIN CERTIFICATE----- 4 -----END CERTIFICATE----- EOF
$ openssl s_client -connect :443 -showcerts < /dev/null
オプション: 以下のコマンドを実行して、リソースマッピングを
VirtualMachineImport
CR から分離する必要がある場合にResourceMapping
を作成します。$ cat <<EOF | kubectl create -f - apiVersion: v2v.kubevirt.io/v1alpha1 kind: ResourceMapping metadata: name: resourcemapping_example namespace: default spec: ovirt: networkMappings: - source: name: <rhv_logical_network>/<vnic_profile> 1 target: name: <target_network> 2 type: pod storageMappings: 3 - source: name: <rhv_storage_domain> 4 target: name: <target_storage_class> 5 volumeMode: <volume_mode> 6 EOF
- 1
- RHV の論理ネットワークおよび vNIC プロファイルを指定します。
- 2
- OpenShift Virtualization ネットワークを指定します。
- 3
- ストレージマッピングが
ResourceMapping
およびVirtualMachineImport
CR の両方に指定される場合、VirtualMachineImport
CR が優先されます。 - 4
- RHV ストレージドメインを指定します。
- 5
nfs
またはocs-storagecluster-ceph-rbd
を指定します。- 6
ocs-storagecluster-ceph-rbd
ストレージクラスを指定した場合、Block
をボリュームモードとして指定する必要があります。
以下のコマンドを実行して
VirtualMachineImport
CR を作成します。$ cat <<EOF | oc create -f - apiVersion: v2v.kubevirt.io/v1beta1 kind: VirtualMachineImport metadata: name: vm-import namespace: default spec: providerCredentialsSecret: name: rhv-credentials namespace: default # resourceMapping: 1 # name: resourcemapping-example # namespace: default targetVmName: vm_example 2 startVm: true source: ovirt: vm: id: <source_vm_id> 3 name: <source_vm_name> 4 cluster: name: <source_cluster_name> 5 mappings: 6 networkMappings: - source: name: <source_logical_network>/<vnic_profile> 7 target: name: <target_network> 8 type: pod storageMappings: 9 - source: name: <source_storage_domain> 10 target: name: <target_storage_class> 11 accessMode: <volume_access_mode> 12 diskMappings: - source: id: <source_vm_disk_id> 13 target: name: <target_storage_class> 14 EOF
- 1
ResourceMapping
CR を作成する場合、resourceMapping
セクションのコメントを解除します。- 2
- ターゲットの仮想マシン名を指定します。
- 3
- ソース仮想マシン ID を指定します (例:
80554327-0569-496b-bdeb-fcbbf52b827b
)。Manager マシンの Web ブラウザーでhttps://www.example.com/ovirt-engine/api/vms/
を入力して仮想マシン ID を取得し、すべての仮想マシンを一覧表示できます。インポートする仮想マシンとその対応する仮想マシン ID を見つけます。仮想マシン名またはクラスター名を指定する必要はありません。 - 4
- ソース仮想マシン名を指定する場合、ソースクラスターも指定する必要があります。ソース仮想マシン ID は指定しないでください。
- 5
- ソースクラスターを指定する場合、ソース仮想マシン名も指定する必要があります。ソース仮想マシン ID は指定しないでください。
- 6
ResourceMapping
CR を作成する場合、mappings
セクションをコメントアウトします。- 7
- ソース仮想マシンの論理ネットワークおよび vNIC プロファイルを指定します。
- 8
- OpenShift Virtualization ネットワークを指定します。
- 9
- ストレージマッピングが
ResourceMapping
およびVirtualMachineImport
CR の両方に指定される場合、VirtualMachineImport
CR が優先されます。 - 10
- ソースストレージドメインを指定します。
- 11
- ターゲットストレージクラスを指定します。
- 12
ReadWriteOnce
、ReadWriteMany
、またはReadOnlyMany
を指定します。アクセスモードが指定されていない場合、{virt} は RHV 仮想マシンまたは仮想ディスクアクセスモード上の HostMigration mode 設定に基づいて正しいボリュームアクセスモードを判別します。 -
RHV 仮想マシン移行モードが
Allow manual and automatic migration
の場合、デフォルトのアクセスモードはReadWriteMany
になります。 -
RHV 仮想ディスクのアクセスモードが
ReadOnly
の場合、デフォルトのアクセスモードはReadOnlyMany
になります。 -
その他のすべての設定では、デフォルトのアクセスモードは
ReadWriteOnce
です。
-
RHV 仮想マシン移行モードが
- 13
- ソース仮想マシンディスク ID を指定します (例:
8181ecc1-5db8-4193-9c92-3ddab3be7b05
)。Manager マシンの Web ブラウザーでhttps://www.example.com/ovirt-engine/api/vms/vm23
を入力して仮想マシンの詳細を確認し、ディスク ID 取得できます。 - 14
- ターゲットストレージクラスを指定します。
仮想マシンインポートの進捗に従い、インポートが正常に完了したことを確認します。
$ oc get vmimports vm-import -n default
インポートが成功したことを示す出力は、以下のようになります。
出力例
... status: conditions: - lastHeartbeatTime: "2020-07-22T08:58:52Z" lastTransitionTime: "2020-07-22T08:58:52Z" message: Validation completed successfully reason: ValidationCompleted status: "True" type: Valid - lastHeartbeatTime: "2020-07-22T08:58:52Z" lastTransitionTime: "2020-07-22T08:58:52Z" message: 'VM specifies IO Threads: 1, VM has NUMA tune mode specified: interleave' reason: MappingRulesVerificationReportedWarnings status: "True" type: MappingRulesVerified - lastHeartbeatTime: "2020-07-22T08:58:56Z" lastTransitionTime: "2020-07-22T08:58:52Z" message: Copying virtual machine disks reason: CopyingDisks status: "True" type: Processing dataVolumes: - name: fedora32-b870c429-11e0-4630-b3df-21da551a48c0 targetVmName: fedora32
7.15.4.4.1. 仮想マシンをインポートするための設定マップの作成
デフォルトの vm-import-controller
マッピングを上書きする場合や、追加のマッピングを追加する場合は、Red Hat Virtualization (RHV) 仮想マシンオペレーティングシステムを OpenShift Virtualization テンプレートにマップする設定マップを作成できます。
デフォルトの vm-import-controller
設定マップには、以下の RHV オペレーティングシステムおよびそれらの対応する共通の OpenShift Virtualization テンプレートが含まれます。
RHV 仮想マシンオペレーティングシステム | OpenShift Virtualization テンプレート |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
手順
Web ブラウザーで、
http://<RHV_Manager_FQDN>/ovirt-engine/api/vms/<VM_ID>
に移動して RHV 仮想マシンオペレーティングシステムの REST API 名を特定します。以下の例のように、オペレーティングシステム名が XML 出力の<os>
セクションに表示されます。... <os> ... <type>rhel_8x64</type> </os>
利用可能な OpenShift Virtualization テンプレートの一覧を表示します。
$ oc get templates -n openshift --show-labels | tr ',' '\n' | grep os.template.kubevirt.io | sed -r 's#os.template.kubevirt.io/(.*)=.*#\1#g' | sort -u
出力例
fedora31 fedora32 ... rhel8.1 rhel8.2 ...
- RHV 仮想マシンオペレーティングシステムに一致する OpenShift Virtualization テンプレートが利用可能なテンプレートの一覧に表示されない場合は、OpenShift Virtualization Web コンソールでテンプレートを作成します。
RHV 仮想マシンオペレーティングシステムを OpenShift Virtualization テンプレートにマップするために設定マップを作成します。
$ cat <<EOF | oc create -f - apiVersion: v1 kind: ConfigMap metadata: name: os-configmap namespace: default 1 data: guestos2common: | "Red Hat Enterprise Linux Server": "rhel" "CentOS Linux": "centos" "Fedora": "fedora" "Ubuntu": "ubuntu" "openSUSE": "opensuse" osinfo2common: | "<rhv-operating-system>": "<vm-template>" 2 EOF
設定マップの例
$ cat <<EOF | oc apply -f - apiVersion: v1 kind: ConfigMap metadata: name: os-configmap namespace: default data: osinfo2common: | "other_linux": "fedora31" EOF
カスタム設定マップが作成されていることを確認します。
$ oc get cm -n default os-configmap -o yaml
vm-import-controller-config
設定マップにパッチを適用し、新規設定マップを適用します。$ oc patch configmap vm-import-controller-config -n openshift-cnv --patch '{ "data": { "osConfigMap.name": "os-configmap", "osConfigMap.namespace": "default" 1 } }'
- 1
- 設定マップで namespace を変更した場合は、namespace を更新します。
テンプレートが OpenShift Virtualization Web コンソールに表示されることを確認します。
-
サイドメニューから Workloads
Virtualization をクリックします。 - Virtual Machine Templates タブをクリックして、一覧でテンプレートを見つけます。
-
サイドメニューから Workloads
7.15.4.5. 仮想マシンのインポートのトラブルシューティング
7.15.4.5.1. ログ
VM Import Controller Pod ログでエラーの有無を確認できます。
手順
以下のコマンドを実行して、VM Import Controller Pod 名を表示します。
$ oc get pods -n <namespace> | grep import 1
- 1
- インポートされた仮想マシンの namespace を指定します。
出力例
vm-import-controller-f66f7d-zqkz7 1/1 Running 0 4h49m
以下のコマンドを実行して、VM Import Controller Pod ログを表示します。
$ oc logs <vm-import-controller-f66f7d-zqkz7> -f -n <namespace> 1
- 1
- VM Import Controller Pod 名および namespace を指定します。
7.15.4.5.2. エラーメッセージ
以下のエラーメッセージが表示される場合があります。
以下のエラーメッセージが VM Import Controller Pod ログに表示され、OpenShift Virtualization ストレージ PV が適切でない場合は進捗バーは 10% で停止します。
Failed to bind volumes: provisioning failed for PVC
互換性のあるストレージクラスを使用する必要があります。Cinder ストレージクラスはサポートされません。
7.15.4.5.3. 既知の問題
- Ceph RBD ブロックモードのボリュームを使用していて、仮想ディスクに利用可能なストレージ領域が小さすぎると、インポートプロセスバーは 75% で 20 分以上停止し、移行は成功しません。Web コンソールにエラーメッセージは表示されません。BZ#1910019
7.15.5. 単一 VMware 仮想マシンまたはテンプレートのインポート
VM Import ウィザードを使用して、VMware vSphere 6.5、6.7、または 7.0 の仮想マシンまたは仮想マシンテンプレートを OpenShift Virtualization にインポートできます。
VM テンプレートをインポートする場合、OpenShift Virtualization はテンプレートに基づいて仮想マシンを作成します。
7.15.5.1. OpenShift Virtualization ストレージ機能マトリクス
以下の表は、仮想マシンのインポートをサポートする OpenShift Virtualization ストレージタイプについて説明しています。
VMware VM のインポート | |
---|---|
OpenShift Container Storage: RBD ブロックモードボリューム | Yes |
OpenShift Virtualization ホストパスプロビジョナー | Yes |
他の複数ノードの書き込み可能なストレージ | ○ [1] |
他の単一ノードの書き込み可能なストレージ | ○ [2] |
- PVC は ReadWriteMany アクセスモードを要求する必要があります。
- PVC は ReadWriteOnce アクセスモードを要求する必要があります。
7.15.5.2. VDDK イメージの作成
インポートプロセスでは、VMware Virtual Disk Development Kit (VDDK) を使用して VMware 仮想ディスクをコピーします。
VDDK SDK をダウンロードし、VDDK イメージを作成し、イメージレジストリーにイメージをアップロードしてからこれを v2v-vmware
設定マップに追加できます。
内部 OpenShift Container Platform イメージレジストリーまたは VDDK イメージのセキュアな外部イメージレジストリーのいずれかを設定できます。レジストリーは OpenShift Virtualization 環境からアクセスできる必要があります。
VDDK イメージをパブリックリポジトリーに保存すると、VMware ライセンスの条件に違反する可能性があります。
7.15.5.2.1. 内部イメージレジストリーの設定
イメージレジストリー Operator 設定を更新して、ベアメタルに内部 OpenShift Container Platform イメージレジストリーを設定できます。
レジストリーをルートで公開して、OpenShift Container Platform クラスターから、または外部からレジストリーに直接アクセスできます。
イメージレジストリーの管理状態の変更
イメージレジストリーを起動するには、イメージレジストリー Operator 設定の managementState
を Removed
から Managed
に変更する必要があります。
手順
ManagementState
イメージレジストリー Operator 設定をRemoved
からManaged
に変更します。以下に例を示します。$ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"managementState":"Managed"}}'
ベアメタルおよび他の手動インストールの場合のレジストリーストレージの設定
クラスター管理者は、インストール後にレジストリーをストレージを使用できるように設定する必要があります。
前提条件
- クラスター管理者のパーミッション。
- ベアメタルなどの、手動でプロビジョニングされた Red Hat Enterprise Linux CoreOS (RHCOS) ノードを使用するクラスター。
Red Hat OpenShift Container Storage などのクラスターのプロビジョニングされた永続ストレージ。
重要OpenShift Container Platform は、1 つのレプリカのみが存在する場合にイメージレジストリーストレージの
ReadWriteOnce
アクセスをサポートします。2 つ以上のレプリカで高可用性をサポートするイメージレジストリーをデプロイするには、ReadWriteMany
アクセスが必要です。- 100Gi の容量が必要です。
手順
レジストリーをストレージを使用できるように設定するには、
configs.imageregistry/cluster
リソースのspec.storage.pvc
を変更します。注記共有ストレージを使用する場合は、外部からアクセスを防ぐためにセキュリティー設定を確認します。
レジストリー Pod がないことを確認します。
$ oc get pod -n openshift-image-registry -l docker-registry=default
出力例
No resourses found in openshift-image-registry namespace
注記出力にレジストリー Pod がある場合は、この手順を続行する必要はありません。
レジストリー設定を確認します。
$ oc edit configs.imageregistry.operator.openshift.io
出力例
storage: pvc: claim:
claim
フィールドを空のままにし、image-registry-storage
PVC の自動作成を可能にします。clusteroperator
ステータスを確認します。$ oc get clusteroperator image-registry
出力例
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE image-registry 4.7 True False False 6h50m
イメージのビルドおよびプッシュを有効にするためにレジストリーが managed に設定されていることを確認します。
以下を実行します。
$ oc edit configs.imageregistry/cluster
次に、行を変更します。
managementState: Removed
上記を以下のように変更します。
managementState: Managed
クラスターからレジストリーへの直接アクセス
クラスター内からレジストリーにアクセスすることができます。
手順
内部ルートを使用して、クラスターからレジストリーにアクセスします。
ノードの名前を取得してノードにアクセスします。
$ oc get nodes
$ oc debug nodes/<node_name>
ノード上で
oc
やpodman
などのツールへのアクセスを有効にするには、以下のコマンドを実行します。sh-4.2# chroot /host
アクセストークンを使用してコンテナーイメージレジストリーにログインします。
sh-4.2# oc login -u kubeadmin -p <password_from_install_log> https://api-int.<cluster_name>.<base_domain>:6443
sh-4.2# podman login -u kubeadmin -p $(oc whoami -t) image-registry.openshift-image-registry.svc:5000
以下のようなログインを確認するメッセージが表示されるはずです。
Login Succeeded!
注記ユーザー名には任意の値を指定でき、トークンには必要な情報がすべて含まれます。コロンが含まれるユーザー名を指定すると、ログインに失敗します。
イメージレジストリー Operator はルートを作成するため、
default-route-openshift-image-registry.<cluster_name>
のようになります。レジストリーに対して
podman pull
およびpodman push
操作を実行します。重要任意のイメージをプルできますが、system:registry ロールを追加している場合は、各自のプロジェクトにあるレジストリーにのみイメージをプッシュすることができます。
次の例では、以下を使用します。
コンポーネント 値 <registry_ip>
172.30.124.220
<port>
5000
<project>
openshift
<image>
image
<tag>
省略 (デフォルトは
latest
)任意のイメージをプルします。
sh-4.2# podman pull name.io/image
新規イメージに
<registry_ip>:<port>/<project>/<image>
形式でタグ付けします。プロジェクト名は、イメージを正しくレジストリーに配置し、これに後でアクセスできるようにするために OpenShift Container Platform のプル仕様に表示される必要があります。sh-4.2# podman tag name.io/image image-registry.openshift-image-registry.svc:5000/openshift/image
注記指定されたプロジェクトについて
system:image-builder
ロールを持っている必要があります。このロールにより、ユーザーはイメージの書き出しやプッシュを実行できます。そうでない場合は、次の手順のpodman push
は失敗します。これをテストするには、新規プロジェクトを作成し、イメージをプッシュできます。新しくタグ付けされたイメージをレジストリーにプッシュします。
sh-4.2# podman push image-registry.openshift-image-registry.svc:5000/openshift/image
セキュアなレジストリーの手動による公開
クラスター内から OpenShift Container Platform レジストリーにログインするのではなく、外部からレジストリーにアクセスできるように、このレジストリーをルートに公開します。これにより、ルートアドレスを使用してクラスターの外部からレジストリーにログインし、ルートホストを使用してイメージにタグを付けて既存のプロジェクトにプッシュすることができます。
前提条件:
以下の前提条件は自動的に実行されます。
- レジストリー Operator のデプロイ。
- Ingress Operator のデプロイ。
手順
configs.imageregistry.operator.openshift.io
リソースで DefaultRoute
パラメーターを使用するか、またはカスタムルートを使用してルートを公開することができます。
DefaultRoute
を使用してレジストリーを公開するには、以下を実行します。
DefaultRoute
をTrue
に設定します。$ oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge
podman
でログインします。$ HOST=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')
$ podman login -u kubeadmin -p $(oc whoami -t) --tls-verify=false $HOST 1
- 1
--tls-verify=false
は、ルートのクラスターのデフォルト証明書が信頼されない場合に必要になります。Ingress Operator で、信頼されるカスタム証明書をデフォルト証明書として設定できます。
カスタムルートを使用してレジストリーを公開するには、以下を実行します。
ルートの TLS キーでシークレットを作成します。
$ oc create secret tls public-route-tls \ -n openshift-image-registry \ --cert=</path/to/tls.crt> \ --key=</path/to/tls.key>
この手順はオプションです。シークレットを作成しない場合、ルートは Ingress Operator からデフォルトの TLS 設定を使用します。
レジストリー Operator では、以下のようになります。
spec: routes: - name: public-routes hostname: myregistry.mycorp.organization secretName: public-route-tls ...
注記レジストリーのルートのカスタム TLS 設定を指定している場合は
secretName
のみを設定します。
7.15.5.2.2. 外部イメージレジストリーの設定
VDDK イメージの外部イメージレジストリーを使用する場合、外部イメージレジストリーの認証局を OpenShift Container Platform クラスターに追加できます。
オプションで、Docker 認証情報からプルシークレットを作成し、これをサービスアカウントに追加できます。
クラスターへの認証局の追加
以下の手順でイメージのプッシュおよびプル時に使用する認証局 (CA) をクラスターに追加することができます。
前提条件
- クラスター管理者の権限があること。
-
レジストリーの公開証明書 (通常は、
/etc/docker/certs.d/
ディレクトリーにあるhostname/ca.crt
ファイル)。
手順
自己署名証明書を使用するレジストリーの信頼される証明書が含まれる
ConfigMap
をopenshift-config
namespace に作成します。それぞれの CA ファイルについて、ConfigMap
のキーがhostname[..port]
形式のレジストリーのホスト名であることを確認します。$ oc create configmap registry-cas -n openshift-config \ --from-file=myregistry.corp.com..5000=/etc/docker/certs.d/myregistry.corp.com:5000/ca.crt \ --from-file=otherregistry.com=/etc/docker/certs.d/otherregistry.com/ca.crt
クラスターイメージの設定を更新します。
$ oc patch image.config.openshift.io/cluster --patch '{"spec":{"additionalTrustedCA":{"name":"registry-cas"}}}' --type=merge
Pod が他のセキュリティー保護されたレジストリーからイメージを参照できるようにする設定
Docker クライアントの .dockercfg
$HOME/.docker/config.json
ファイルは、セキュア/非セキュアなレジストリーに事前にログインしている場合に認証情報を保存する Docker 認証情報ファイルです。
OpenShift Container Platform の内部レジストリーにないセキュリティー保護されたコンテナーイメージをプルするには、Docker 認証情報でプルシークレットを作成し、これをサービスアカウントに追加する必要があります。
手順
セキュリティー保護されたレジストリーの
.dockercfg
ファイルがすでにある場合は、以下を実行してそのファイルからシークレットを作成できます。$ oc create secret generic <pull_secret_name> \ --from-file=.dockercfg=<path/to/.dockercfg> \ --type=kubernetes.io/dockercfg
または、
$HOME/.docker/config.json
ファイルがある場合は以下を実行します。$ oc create secret generic <pull_secret_name> \ --from-file=.dockerconfigjson=<path/to/.docker/config.json> \ --type=kubernetes.io/dockerconfigjson
セキュアなレジストリーについての Docker 認証情報ファイルがまだない場合には、以下のコマンドを実行してシークレットを作成することができます。
$ oc create secret docker-registry <pull_secret_name> \ --docker-server=<registry_server> \ --docker-username=<user_name> \ --docker-password=<password> \ --docker-email=<email>
Pod のイメージをプルするためのシークレットを使用するには、そのシークレットをサービスアカウントに追加する必要があります。この例では、サービスアカウントの名前は、Pod が使用するサービスアカウントの名前に一致している必要があります。デフォルトのサービスアカウントは
default
です。$ oc secrets link default <pull_secret_name> --for=pull
7.15.5.2.3. VDDK イメージの作成および使用
VMware Virtual Disk Development Kit (VDDK) をダウンロードして、VDDK イメージをビルドし、VDDK イメージをイメージレジストリーにプッシュできます。VDDK イメージを v2v-vmware
設定マップに追加します。
前提条件
- OpenShift Container Platform 内部イメージレジストリーまたはセキュアな外部レジストリーにアクセスできる必要がある。
手順
一時ディレクトリーを作成し、これに移動します。
$ mkdir /tmp/<dir_name> && cd /tmp/<dir_name>
- ブラウザーで VMware code に移動し、SDKs をクリックします。
- Compute Virtualization で Virtual Disk Development Kit(VDDK) をクリックします。
- VMware vSphere のバージョンに対応する VDDK バージョンを選択します。たとえば、vSphere 7.0 の場合は VDDK 7.0 を選択し、Download をクリックしてから、VDDK アーカイブを一時ディレクトリーに保存します。
VDDK アーカイブを展開します。
$ tar -xzf VMware-vix-disklib-<version>.x86_64.tar.gz
Dockerfile
を作成します。$ cat > Dockerfile <<EOF FROM busybox:latest COPY vmware-vix-disklib-distrib /vmware-vix-disklib-distrib RUN mkdir -p /opt ENTRYPOINT ["cp", "-r", "/vmware-vix-disklib-distrib", "/opt"] EOF
イメージをビルドします。
$ podman build . -t <registry_route_or_server_path>/vddk:<tag> 1
- 1
- イメージレジストリーを指定します。
-
内部 OpenShift Container Platform レジストリーの場合は、内部レジストリールート (例:
image-registry.openshift-image-registry.svc:5000/openshift/vddk:<tag>
) を使用します。 -
外部レジストリーの場合は、サーバー名、パスおよびタグを指定します (例:
server.example.com:5000/vddk:<tag>
)。
-
内部 OpenShift Container Platform レジストリーの場合は、内部レジストリールート (例:
イメージをレジストリーにプッシュします。
$ podman push <registry_route_or_server_path>/vddk:<tag>
- イメージが OpenShift virtualization 環境からアクセスできることを確認します。
openshift-cnv プロジェクトで
v2v-vmware
設定マップを編集します。$ oc edit configmap v2v-vmware -n openshift-cnv
vddk-init-image
パラメーターをdata
スタンザに追加します。... data: vddk-init-image: <registry_route_or_server_path>/vddk:<tag>
7.15.5.3. VM Import ウィザードを使用した仮想マシンのインポート
VM Import ウィザードを使用して、単一の仮想マシンをインポートできます。
仮想マシンテンプレートをインポートすることもできます。VM テンプレートをインポートする場合、OpenShift Virtualization はテンプレートに基づいて仮想マシンを作成します。
前提条件
- 管理者ユーザー権限があること。
- VMware Virtual Disk Development Kit (VDDK) イメージは、OpenShift Virtualization 環境からアクセスできるイメージレジストリーにある。
-
VDDK イメージは
v2v-vmware
設定マップに追加されている。 - 仮想マシンの電源がオフになっている。
- 仮想ディスクが IDE または SCSI コントローラーに接続されている。仮想ディスクが SATA コントローラーに接続されている場合は、それらを IDE コントローラーに変更してから、仮想マシンを移行できます。
- OpenShift Virtualization のローカルおよび共有永続ストレージクラスは、仮想マシンのインポートをサポートする必要があります。
OpenShift Virtualization ストレージは、仮想ディスクに対応するのに十分な大きさである。
警告Ceph RBD ブロックモードのボリュームを使用している場合、ストレージは仮想ディスクに対応するのに十分な大きさである必要があります。ディスクが利用可能なストレージに対して大きすぎると、インポートプロセスが失敗し、仮想ディスクのコピーに使用される PV は解放されません。オブジェクトの削除をサポートするためのリソースが十分にないため、別の仮想マシンをインポートしたり、ストレージをクリーンアップしたりすることはできません。この状況を解決するには、ストレージバックエンドにオブジェクトストレージデバイスをさらに追加する必要があります。
OpenShift Virtualization egress ネットワークポリシーは以下のトラフィックを許可する必要がある。
宛先 プロトコル ポート VMware ESXi ホスト
TCP
443
VMware ESXi ホスト
TCP
902
VMware vCenter
TCP
5840
手順
-
Web コンソールで、Workloads
Virtual Machines をクリックします。 - Create Virtual Machine をクリックし、Import with Wizard を選択します。
- Provider 一覧から、VMware を選択します。
Connect to New Instance または保存された vCenter インスタンスを選択します。
- Connect to New Instance を選択する場合、vCenter hostname、Username、Password を入力します。
- 保存された vCenter インスタンスを選択する場合、ウィザードは保存された認証情報を使用して vCenter に接続します。
Check and Save をクリックし、接続が完了するまで待ちます。
注記接続の詳細はシークレットに保存されます。ホスト名、ユーザー名、またはパスワードが正しくないプロバイダーを追加した場合は、Workloads
Secrets をクリックし、プロバイダーのシークレットを削除します。 - 仮想マシンまたはテンプレートを選択します。
- Next をクリックします。
- Review 画面で、設定を確認します。
Edit をクリックして、以下の設定を更新します。
General:
- 説明
- オペレーティングシステム
- Flavor
- Memory
- CPU
- Workload Profile
Networking:
- 名前
- Model
- Network
- Type
- MAC Address
ストレージ: 仮想マシンディスクの Options メニュー をクリックし、Edit を選択して以下のフィールドを更新します。
- 名前
- Source: Import Disk など。
- Size
- Interface
Storage Class: NFS または ocs-storagecluster-ceph-rbd (ceph-rbd) を選択します。
ocs-storagecluster-ceph-rbd を選択する場合、ディスクの Volume Mode を Block に設定する必要があります。
他のストレージクラスは機能する可能性がありますが、正式にサポートされていません。
-
Advanced
Volume Mode: Block を選択します。 -
Advanced
Access Mode
Advanced
Cloud-init: - Form: Hostname および Authenticated SSH Keys を入力します。
-
Custom script: テキストフィールドに
cloud-init
スクリプトを入力します。
-
Advanced
Virtual Hardware: 仮想 CD-ROM をインポートされた仮想マシンに割り当てることができます。
インポート設定を編集した場合は、Import または Review and Import をクリックします。
Successfully created virtual machine というメッセージが表示され、仮想マシンに作成されたリソースの一覧が表示されます。仮想マシンが Workloads
Virtual Machines に表示されます。
仮想マシンウィザードのフィールド
名前 | パラメーター | 説明 |
---|---|---|
名前 |
この名前には、小文字 ( | |
説明 | オプションの説明フィールド。 | |
Operating System | テンプレートで仮想マシン用に選択される主なオペレーティングシステム。テンプレートから仮想マシンを作成する場合、このフィールドを編集することはできません。 | |
Boot Source | URL を使用したインポート (PVC の作成) | HTTP または HTTPS エンドポイントで利用できるイメージからコンテンツをインポートします。例: オペレーティングシステムイメージのある Web ページから URL リンクを取得します。 |
既存の PVC のクローン作成 (PVC の作成) | クラスターで利用可能な既存の永続ボリューム要求 (PVC) を選択し、これをクローンします。 | |
レジストリーを使用したインポート (PVC の作成) |
クラスターからアクセスできるレジストリーの起動可能なオペレーティングシステムコンテナーから仮想マシンをプロビジョニングします。例: | |
PXE (ネットワークブート: ネットワークインターフェイスの追加) | ネットワークのサーバーからオペレーティングシステムを起動します。PXE ブート可能なネットワーク接続定義が必要です。 | |
永続ボリューム要求 (PVC) のプロジェクト | PVC のクローン作成に使用するプロジェクト名。 | |
永続ボリューム要求 (PVC) の名前 | 既存の PVC のクローンを作成する場合にこの仮想マシンテンプレートに適用する必要のある PVC 名。 | |
これを CD-ROM ブートソースとしてマウントする | CD-ROM には、オペレーティングシステムをインストールするための追加のディスクが必要です。チェックボックスを選択して、ディスクを追加し、後でカスタマイズします。 | |
Flavor | Tiny、Small、Medium、Large、Custom | 仮想マシンに割り当てられる CPU およびメモリーの量を決定するプリセット。Flavor に設定される Preset はオペレーティングシステムによって決まります。 |
Workload Type | Desktop | デスクトップで使用するための仮想マシン設定。小規模な環境での使用に適しています。Web コンソールでの使用に推奨されます。 |
Server | パフォーマンスのバランスを図り、さまざまなサーバーのワークロードと互換性があります。 | |
High-Performance | 高パフォーマンスのワークロードに対して最適化された仮想マシン設定。 | |
作成後にこの仮想マシンを起動します。 | このチェックボックスはデフォルトで選択され、仮想マシンは作成後に実行を開始します。仮想マシンの作成時に起動する必要がない場合は、チェックボックスをクリアします。 |
Cloud-init フィールド
名前 | 説明 |
---|---|
Hostname | 仮想マシンの特定のホスト名を設定します。 |
認可された SSH キー | 仮想マシンの ~/.ssh/authorized_keys にコピーされるユーザーの公開鍵。 |
カスタムスクリプト | 他のオプションを、カスタム cloud-init スクリプトを貼り付けるフィールドに置き換えます。 |
ネットワークフィールド
名前 | 説明 |
---|---|
名前 | ネットワークインターフェイスコントローラーの名前。 |
モデル | ネットワークインターフェイスコントローラーのモデルを示します。サポートされる値は e1000e および virtio です。 |
ネットワーク | 利用可能なネットワーク接続定義の一覧。 |
Type |
利用可能なバインディングメソッドの一覧。デフォルトの Pod ネットワークについては、 |
MAC Address | ネットワークインターフェイスコントローラーの MAC アドレス。MAC アドレスが指定されていない場合、これは自動的に割り当てられます。 |
ストレージフィールド
名前 | 選択 | 説明 |
---|---|---|
Source | 空白 (PVC の作成) | 空のディスクを作成します。 |
URL を使用したインポート (PVC の作成) | URL (HTTP または HTTPS エンドポイント) を介してコンテンツをインポートします。 | |
既存 PVC の使用 | クラスターですでに利用可能な PVC を使用します。 | |
既存の PVC のクローン作成 (PVC の作成) | クラスターで利用可能な既存の PVC を選択し、このクローンを作成します。 | |
レジストリーを使用したインポート (PVC の作成) | コンテナーレジストリーを使用してコンテンツをインポートします。 | |
コンテナー (一時的) | クラスターからアクセスできるレジストリーにあるコンテナーからコンテンツをアップロードします。コンテナーディスクは、CD-ROM や一時的な仮想マシンなどの読み取り専用ファイルシステムにのみ使用する必要があります。 | |
名前 |
ディスクの名前。この名前には、小文字 ( | |
Size | ディスクのサイズ (GiB 単位)。 | |
Type | ディスクのタイプ。例: Disk または CD-ROM | |
Interface | ディスクデバイスのタイプ。サポートされるインターフェイスは、virtIO、SATA、および SCSI です。 | |
Storage Class | ディスクの作成に使用されるストレージクラス。 | |
Advanced | 永続ボリュームがフォーマットされたファイルシステムまたは raw ブロック状態を使用するかどうかを定義します。デフォルトは Filesystem です。 | |
Advanced | 永続ボリュームのアクセスモード。サポートされるアクセスモードは、Single User (RWO)、Shared Access (RWX)、および Read Only (ROX) です。 |
ストレージの詳細設定
以下のストレージの詳細設定は、Blank、Import via URLURL、および Clone existing PVC ディスクで利用できます。これらのパラメーターはオプションです。これらのパラメーターを指定しない場合、システムは kubevirt-storage-class-defaults
設定マップのデフォルト値を使用します。
名前 | パラメーター | 説明 |
---|---|---|
ボリュームモード | Filesystem | ファイルシステムベースのボリュームで仮想ディスクを保存します。 |
Block |
ブロックボリュームで仮想ディスクを直接保存します。基礎となるストレージがサポートしている場合は、 | |
アクセスモード | Single User (RWO) | ディスクは単一ノードで読み取り/書き込みとしてマウントできます。 |
Shared Access (RWX) | ディスクは数多くのノードで読み取り/書き込みとしてマウントできます。 注記 これは、ノード間の仮想マシンのライブマイグレーションなどの、一部の機能で必要になります。 | |
Read Only (ROX) | ディスクは数多くのノードで読み取り専用としてマウントできます。 |
7.15.5.3.1. インポートされた仮想マシンの NIC 名の更新
VMware からインポートされた仮想マシンの NIC 名を、 OpenShift Virtualization の命名規則に適合するように更新する必要があります。
手順
- 仮想マシンにログインします。
-
/etc/sysconfig/network-scripts
ディレクトリーに移動します。 ネットワーク設定ファイルの名前を変更します。
$ mv vmnic0 ifcfg-eth0 1
- 1
- ネットワーク設定ファイルの名前を
ifcfg-eth0
に変更します。追加のネットワーク設定ファイルには、ifcfg-eth1
、ifcfg-eth2
などの番号が順番に付けられます。
ネットワーク設定ファイルで
NAME
およびDEVICE
パラメーターを更新します。NAME=eth0 DEVICE=eth0
ネットワークを再起動します。
$ systemctl restart network
7.15.5.4. 仮想マシンのインポートのトラブルシューティング
7.15.5.4.1. ログ
V2V Conversion Pod ログでエラーの有無を確認できます。
手順
以下のコマンドを実行して、V2V Conversion Pod 名を表示します。
$ oc get pods -n <namespace> | grep v2v 1
- 1
- インポートされた仮想マシンの namespace を指定します。
出力例
kubevirt-v2v-conversion-f66f7d-zqkz7 1/1 Running 0 4h49m
以下のコマンドを実行して V2V Conversion Pod ログを表示します。
$ oc logs <kubevirt-v2v-conversion-f66f7d-zqkz7> -f -n <namespace> 1
- 1
- VM Conversion Pod 名および namespace を指定します。
7.15.5.4.2. エラーメッセージ
以下のエラーメッセージが表示される場合があります。
インポート前に VMware 仮想マシンがシャットダウンされない場合、OpenShift Container Platform コンソールのインポートされた仮想マシンにはエラーメッセージ
Readiness probe failed
が表示され、V2V Conversion Pod ログには以下のエラーメッセージが表示されます。INFO - have error: ('virt-v2v error: internal error: invalid argument: libvirt domain ‘v2v_migration_vm_1’ is running or paused. It must be shut down in order to perform virt-v2v conversion',)"
管理者以外のユーザーが仮想マシンのインポートを試みると、以下のエラーメッセージが OpenShift Container Platform コンソールに表示されます。
Could not load config map vmware-to-kubevirt-os in kube-public namespace Restricted Access: configmaps "vmware-to-kubevirt-os" is forbidden: User cannot get resource "configmaps" in API group "" in the namespace "kube-public"
仮想マシンをインポートできるのは、管理者ユーザーのみです。