Migration Toolkit for Virtualization のインストールおよび使用
VMware vSphere または Red Hat Virtualization から Red Hat OpenShift Virtualization への移行
Red Hat Modernization and Migration Documentation Team
ccs-mms-docs@redhat.com
概要
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。
第1章 Migration Toolkit for Virtualization について
Migration Toolkit for Virtualization (MTV) を使用して、仮想マシンを VMware vSphere または Red Hat Virtualization から OpenShift Virtualization に移行できます。
関連情報
1.1. コールド移行とウォーム移行
MTV は、Red Hat Virtualization (RHV) からのコールド移行と、VMware vSphere および RHV からのウォーム移行をサポートしています。
1.1.1. コールド移行
コールド移行は、デフォルトの移行タイプです。ソース仮想マシンは、データのコピー中にシャットダウンします。
1.1.2. ウォーム移行
ほとんどのデータは、ソース仮想マシン (VM) の実行中にプレコピー段階でコピーされます。
次に、VM がシャットダウンされ、残りのデータはカットオーバー段階でコピーされます。
プレコピー段階
仮想マシンはプレコピー段階ではシャットダウンされません。
仮想マシンディスクは、変更ブロックのトラッキング (CBT) スナップショットを使用して増分がコピーされます。スナップショットは、デフォルトでは 1 時間間隔で作成されます。forklift-controller
デプロイメントを更新して、スナップショットの間隔を変更できます。
各 ソース VM および各 VM ディスクに対して CBT を有効にする必要があります。
仮想マシンは、最大 28 CBT スナップショットをサポートします。ソース VM の CBT スナップショットが多すぎて、Migration Controller
サービスが新規スナップショットを作成できない場合、ウォーム移行に失敗する可能性があります。スナップショットが不要になると、Migration Controller
サービスは各スナップショットを削除します。
プレコピー段階は、カットオーバー段階を手動で開始するか、開始がスケジュールされるまで実行されます。
カットオーバー段階
カットオーバーの段階で仮想マシンはシャットダウンされ、残りのデータは移行されます。RAM に格納されたデータは移行されません。
MTV コンソールを使用してカットオーバー段階を手動で開始するか、Migration
マニフェストでカットオーバー時間をスケジュールできます。
第2章 前提条件
以下の前提条件を確認し、環境が移行用に準備されていることを確認します。
2.1. ソフトウェア要件
互換性のあるバージョン の OpenShift Container Platform および OpenShift Virtualization をインストールしている。
2.2. ストレージのサポートとデフォルトモード
MTV は、サポートされているストレージに以下のデフォルトのボリュームおよびアクセスモードを使用します。
OpenShift Virtualization ストレージが 動的プロビジョニング に対応していない場合、以下の設定を適用する必要があります。
Filesystem
のボリュームモードFilesystem
ボリュームモードは、Block
ボリュームモードよりも遅くなります。ReadWriteOnce
アクセスモードReadWriteOnce
アクセスモードは、仮想マシンのライブマイグレーションをサポートしません。
ストレージプロファイルの編集に関する詳細は、Enabling a statically-provisioned storage class を参照してください。
移行で、EXT4 ファイルシステムで作成されたブロックストレージおよび永続ボリュームを使用する場合は、CDI のファイルシステムのオーバーヘッドを 10% 以上に増やします。CDI が想定するデフォルトのオーバーヘッドには、root パーティション用に予約された場所が完全に含まれていません。CDI のファイルシステムオーバーヘッドをこの量だけ増やさないと、移行が失敗する可能性があります。
表2.1 デフォルトのボリュームおよびアクセスモード
プロビジョナー | ボリュームモード | アクセスモード |
---|---|---|
kubernetes.io/aws-ebs | ブロック | ReadWriteOnce |
kubernetes.io/azure-disk | ブロック | ReadWriteOnce |
kubernetes.io/azure-file | Filesystem | ReadWriteMany |
kubernetes.io/cinder | ブロック | ReadWriteOnce |
kubernetes.io/gce-pd | ブロック | ReadWriteOnce |
kubernetes.io/hostpath-provisioner | Filesystem | ReadWriteOnce |
manila.csi.openstack.org | Filesystem | ReadWriteMany |
openshift-storage.cephfs.csi.ceph.com | Filesystem | ReadWriteMany |
openshift-storage.rbd.csi.ceph.com | ブロック | ReadWriteOnce |
kubernetes.io/rbd | ブロック | ReadWriteOnce |
kubernetes.io/vsphere-volume | ブロック | ReadWriteOnce |
2.3. ネットワークの前提条件
すべての移行に、以下の前提条件が適用されます。
- IP アドレス、VLAN、およびその他のネットワーク設定が、移行前または移行中に変更されていない。仮想マシンの MAC アドレスは移行時に保持されます。
- 移行元環境、OpenShift Virtualization クラスター、およびレプリケーションリポジトリー間のネットワーク接続が、信頼でき中断されない。
- 複数の移行元および移行先ネットワークをマッピングする場合は、追加の移行先ネットワークごとに ネットワーク接続定義 が作成されている。
2.3.1. Ports
ファイアウォールは、以下のポートでトラフィックを有効にする必要があります。
表2.2 VMware vSphere からの移行に必要なネットワークポート
ポート | プロトコル | 送信元 | 送信先 | 目的 |
---|---|---|---|---|
443 | TCP | OpenShift ノード | VMware vCenter | VMware プロバイダーインベントリー ディスク転送の認証 |
443 | TCP | OpenShift ノード | VMware ESXi ホスト | ディスク転送の認証 |
902 | TCP | OpenShift ノード | VMware ESXi ホスト | ディスク転送データのコピー |
表2.3 Red Hat Virtualization からの移行に必要なネットワークポート
ポート | プロトコル | 送信元 | 送信先 | 目的 |
---|---|---|---|---|
443 | TCP | OpenShift ノード | RHV Engine | RHV プロバイダーインベントリー ディスク転送の認証 |
443 | TCP | OpenShift ノード | RHV ホスト | ディスク転送の認証 |
54322 | TCP | OpenShift ノード | RHV ホスト | ディスク転送データのコピー |
2.4. ソース仮想マシンの前提条件
すべての移行に、以下の前提条件が適用されます。
- ISO/CDROM ディスクをアンマウントしている。
- 各 NIC に、IPv4 アドレス および IPv6 アドレスが 1 つずつ、またはいずれか一方が 1 つ含まれている。
-
仮想マシンオペレーティングシステムが、OpenShift Virtualization のゲストオペレーティングシステム としての使用 および
virt-v2v
での KVM への変換 に対して認定およびサポートされている。 -
仮想マシン名には、小文字 (
a-z
)、数字 (0-9
)、またはハイフン (-
) のみが含まれ、最大 253 文字である。最初と最後の文字は英数字にする必要があります。この名前には、大文字、スペース、ピリオド (.
)、または特殊文字を使用できません。 仮想マシン名が、OpenShift Virtualization 環境の仮想マシンの名前と重複していない。
注記Migration Toolkit for Virtualization は、ルールに準拠していない VM に新しい名前を自動的に割り当てます。
Migration Toolkit for Virtualization は、新しい VM 名を自動的に生成するときに、次の変更を行います。
- 除外された文字を削除する。
- 大文字を小文字に切り替える。
-
アンダースコア (
_
) をダッシュ (-
) に変更する。
この機能により、ルールに準拠していない VM 名を入力した場合でも、移行をスムーズに進めることができます。
2.5. Red Hat Virtualization の前提条件
Red Hat Virtualization の移行には、以下の前提条件が適用されます。
- 互換性のあるバージョン の Red Hat Virtualization を使用する必要があります。
Manager の CA 証明書を取得している。
ブラウザーで
https://<engine_host>/ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA
に移動して、CA 証明書を取得できます。Manager Apache CA 証明書がサードパーティー CA 証明書に置き換えられた場合は、Manager Apache CA 証明書と Manager CA 証明書の両方が必要です。
2.6. VMware の前提条件
VMware の移行には、以下の前提条件が適用されます。
- 互換性のあるバージョン の VMware vSphere を使用している。
- 少なくとも最小限の VMware 権限 を持つユーザーとしてログインしている。
- VMware ツール をすべてのソース仮想マシン (VM) にインストールしている。
- ウォーム移行を実行している場合は、仮想マシンおよび仮想マシンディスクで 変更ブロックのトラッキング (CBT) を有効にしている。
- VMware Virtual Disk Development Kit (VDDK) イメージを作成している。
- vCenter ホストの SHA-1 フィンガープリントを取得している。
- 同じ移行計画の ESXi ホストから 10 台を超える仮想マシンを移行する場合は、ホストの NFC サービスメモリーを増やしている。
- Migration Toolkit for Virtualization (MTV) は休止状態の VM の移行をサポートしていないため、休止状態を無効にすることを強く推奨する。
停電が発生した場合、休止状態が無効になっている VM のデータが失われる可能性があります。ただし、ハイバネーションが無効になっていない場合は移行に失敗します。
MTV も OpenShift Virtualization も、VMWare から VM を移行するための Btrfs の変換をサポートしていません。
VMware 権限
Migration Toolkit for Virtualization (MTV) を使用して仮想マシンを Open Shift Virtualization に移行するには、次の最小限の VMware 権限のセットが必要です。
表2.4 VMware 権限
特権 | 説明 |
---|---|
| |
| 電源がオンになっている仮想マシンの電源をオフにできます。この操作により、ゲストオペレーティングシステムの電源がオフになります。 |
| 電源がオフになっている仮想マシンの電源をオンにし、中断している仮想マシンを再開できます。 |
注記
すべての | |
| ランダムな読み取りおよび書き込みアクセスのために仮想マシンでディスクを開くことができます。主にリモートディスクマウントに使用されます。 |
| VMX、ディスク、ログ、NVRAM など、仮想マシンに関連付けられたファイルの操作を許可します。 |
| ランダムな読み取りアクセスのために仮想マシンでディスクを開くことができます。主にリモートディスクマウントに使用されます。 |
| VMX、ディスク、ログ、NVRAM など、仮想マシンに関連付けられたファイルの読み取り操作を許可します。 |
| VMX、ディスク、ログ、NVRAM など、仮想マシンに関連付けられたファイルの書き込み操作を許可します。 |
| テンプレートのクローンを作成できます。 |
| 既存の仮想マシンのクローン作成とリソースの割り当てを許可します。 |
| 仮想マシンから新しいテンプレートを作成できます。 |
| 仮想マシンを移行せずに、仮想マシンのゲストオペレーティングシステムをカスタマイズできます。 |
| テンプレートからの仮想マシンのデプロイメントを許可します。 |
| 既存の電源がオフになっている仮想マシンをテンプレートとしてマークできます。 |
| 既存のテンプレートを仮想マシンとしてマークできます。 |
| カスタマイズ仕様の作成、変更、または削除を許可します。 |
| 仮想マシンのディスクでのプロモート操作を許可します。 |
| カスタマイズ仕様の読み取りを許可します。 |
| |
| 仮想マシンの現在の状態からスナップショットを作成できます。 |
| スナップショット履歴からスナップショットを削除できます。 |
2.6.1. VDDK イメージの作成
Migration Toolkit for Virtualization (MTV) は、VMware Virtual Disk Development Kit (VDDK) SDK を使用して、VMware vSphere から仮想ディスクを転送します。
VMware Virtual Disk Development Kit (VDDK) をダウンロードして、VDDK イメージをビルドし、VDDK イメージをイメージレジストリーにプッシュする必要があります。VMware ソースプロバイダーを追加するには、VDDK init イメージパスが必要です。
VDDK イメージをパブリックレジストリーに保存すると、VMware ライセンスの条項に違反する可能性があります。
前提条件
- OpenShift Container Platform イメージレジストリー
-
podman
がインストールされている。 - 外部レジストリーを使用している場合、OpenShift Virtualization がこれにアクセスできる。
手順
一時ディレクトリーを作成し、これに移動します。
$ mkdir /tmp/<dir_name> && cd /tmp/<dir_name>
- ブラウザーで、VMware VDDK バージョン 7 ダウンロードページ に移動します。
- バージョン 7.0.3.2 を選択し、Download をクリックします。
- VDDK アーカイブファイルを一時ディレクトリーに保存します。
VDDK アーカイブを展開します。
$ tar -xzf VMware-vix-disklib-<version>.x86_64.tar.gz
Dockerfile
を作成します。$ cat > Dockerfile <<EOF FROM registry.access.redhat.com/ubi8/ubi-minimal USER 1001 COPY vmware-vix-disklib-distrib /vmware-vix-disklib-distrib RUN mkdir -p /opt ENTRYPOINT ["cp", "-r", "/vmware-vix-disklib-distrib", "/opt"] EOF
VDDK イメージをビルドします。
$ podman build . -t <registry_route_or_server_path>/vddk:<tag>
VDDK イメージをレジストリーにプッシュします。
$ podman push <registry_route_or_server_path>/vddk:<tag>
- イメージが OpenShift Virtualization 環境からアクセスできることを確認します。
2.6.2. vCenter ホストの SHA-1 フィンガープリントの取得
Secret
CR を作成するには、vCenter ホストの SHA-1 フィンガープリントを取得する必要があります。
手順
以下のコマンドを実行します。
$ openssl s_client \ -connect <vcenter_host>:443 \ 1 < /dev/null 2>/dev/null \ | openssl x509 -fingerprint -noout -in /dev/stdin \ | cut -d '=' -f 2
- 1
- vCenter ホストの IP アドレスまたは FQDN を指定します。
出力例
01:23:45:67:89:AB:CD:EF:01:23:45:67:89:AB:CD:EF:01:23:45:67
2.6.3. ESXi ホストの NFC サービスメモリーの拡張
同じ移行計画の ESXi ホストから 10 台を超える仮想マシンを移行する場合は、ホストの NFC サービスメモリーを増やす必要があります。有効にしない場合、NFC サービスメモリーの同時接続は 10 台に制限されているため、移行に失敗します。
手順
- root として ESXi ホストにログインします。
/etc/vmware/hostd/config.xml
でmaxMemory
の値を1000000000
に変更します。... <nfcsvc> <path>libnfcsvc.so</path> <enabled>true</enabled> <maxMemory>1000000000</maxMemory> <maxStreamMemory>10485760</maxStreamMemory> </nfcsvc> ...
hostd
を再起動します。# /etc/init.d/hostd restart
ホストを再起動する必要はありません。
2.7. ソフトウェア互換性ガイドライン
互換性のあるソフトウェアバージョンをインストールする必要があります。
表2.5 互換性のあるソフトウェアバージョン
Migration Toolkit for Virtualization | OpenShift Container Platform | OpenShift Virtualization | VMware vSphere | Red Hat Virtualization |
---|---|---|---|---|
2.3.3 | 4.10 以降 | 4.10 以降 | 6.5 以降 | 4.4.9 以降 |
第3章 MTV Operator のインストール
OpenShift Container Platform Web コンソールまたはコマンドラインインターフェイス (CLI) を使用して MTV Operator をインストールできます。
3.1. OpenShift Container Platform Web コンソールを使用した MTV Operator のインストール
OpenShift Container Platform Web コンソールを使用して MTV Operator をインストールできます。
前提条件
- OpenShift Container Platform 4.10 以降がインストールされている。
- OpenShift 移行ターゲットクラスターに OpenShift Virtualization Operator インストールされている。
-
cluster-admin
パーミッションを持つユーザーとしてログインしている。
手順
- OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。
- Filter by keyword フィールドを使用して mtv-operator を検索します。
- Migration Tookit for Virtualization Operator をクリックしてから Install をクリックします。
- Install Operator ページで、 Install をクリックします。
- Operators → Installed Operators をクリックして、Migration Tookit for Virtualization Operator が Succeeded のステータスで openshift-mtv プロジェクトに表示されることを確認します。
- Migration Tookit for Virtualization Operator をクリックします。
- Provided APIs の下で ForkliftController を探し、Create Instance をクリックします。
- Create をクリックします。
- Workloads → Pods をクリックし、MTV Pod が実行されていることを確認します。
- OpenShift Container Platform Web コンソールにログインします。
- Networking → Routes をクリックします。
Project: 一覧で
openshift-mtv
プロジェクトを選択します。MTV Web コンソールのログインページを開く
forklift-ui
サービスの URL が表示されます。URL をクリックして MTV Web コンソールに移動します。
3.2. コマンドラインインターフェイスからの MTV Operator のインストール
コマンドラインインターフェイス (CLI) から MTV Operator をインストールできます。
前提条件
- OpenShift Container Platform 4.10 以降がインストールされている。
- OpenShift 移行ターゲットクラスターに OpenShift Virtualization Operator インストールされている。
-
cluster-admin
パーミッションを持つユーザーとしてログインしている。
手順
openshift-mtv プロジェクトを作成します。
$ cat << EOF | oc apply -f - apiVersion: project.openshift.io/v1 kind: Project metadata: name: openshift-mtv EOF
migration
というOperatorGroup
CR を作成します。$ cat << EOF | oc apply -f - apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: migration namespace: openshift-mtv spec: targetNamespaces: - openshift-mtv EOF
Operator の
Subscription
CR を作成します。$ cat << EOF | oc apply -f - apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: mtv-operator namespace: openshift-mtv spec: channel: release-v2.3.0 installPlanApproval: Automatic name: mtv-operator source: redhat-operators sourceNamespace: openshift-marketplace startingCSV: "mtv-operator.2.3.0" EOF
ForkliftController
CR を作成します。$ cat << EOF | oc apply -f - apiVersion: forklift.konveyor.io/v1beta1 kind: ForkliftController metadata: name: forklift-controller namespace: openshift-mtv spec: olm_managed: true EOF
MTV Pod が実行されていることを確認します。
$ oc get pods -n openshift-mtv
出力例
NAME READY STATUS RESTARTS AGE forklift-controller-788bdb4c69-mw268 2/2 Running 0 2m forklift-operator-6bf45b8d8-qps9v 1/1 Running 0 5m forklift-ui-7cdf96d8f6-xnw5n 1/1 Running 0 2m
以下のコマンドを使用して Forklift Web コンソール URL を取得します。
$ oc get route virt -n openshift-mtv \ -o custom-columns=:.spec.host
MTV Web コンソールのログインページを開く
forklift-ui
サービスの URL が表示されます。出力例
https://virt-openshift-mtv.apps.cluster.openshift.com.
3.3. MTV Web コンソール URL の取得
OpenShift Container Platform Web コンソールまたはコマンドラインのいずれかを使用して、MTV Web コンソール URL をいつでも取得できます。
前提条件
- OpenShift Virtualization Operator がインストールされている。
- MTV Operator がインストールされている。
-
cluster-admin
権限を持つユーザーとしてログインしている。
手順
OpenShift Container Platform Web コンソールを使用している場合は、以下の手順を実行します。
- OpenShift Container Platform Web コンソールにログインします。
- Networking → Routes をクリックします。
Project: 一覧で
openshift-mtv
プロジェクトを選択します。MTV Web コンソールのログインページを開く
forklift-ui
サービスの URL が表示されます。URL をクリックして MTV Web コンソールに移動します。
コマンドラインを使用している場合は、以下のコマンドを実行して MTV Web コンソール URL を取得します。
$ oc get route virt -n openshift-mtv \ -o custom-columns=:.spec.host
MTV Web コンソールのログインページを開く
forklift-ui
サービスの URL が表示されます。出力例
https://virt-openshift-mtv.apps.cluster.openshift.com.
これでブラウザーを起動し、MTV Web コンソールに移動します。
第4章 MTV Web コンソールを使用した仮想マシンの移行
MTV Web コンソールを使用して、仮想マシン (VM) を OpenShift Virtualization に移行できます。
すべての 前提条件 を満たしていることを確認する必要があります。
VMware のみ: 最小限の VMware の権限 セットが必要です。
VMware のみ: VMware Virtual Disk Development Kit (VDDK) イメージを作成する必要があります。
4.1. プロバイダーの追加
MTV Web コンソールを使用して、仮想マシンの移行元プロバイダーおよび移行先プロバイダーを追加できます。
4.1.1. 移行元プロバイダーの追加
MTV Web コンソールを使用して、Red Hat Virtualization 移行元プロバイダーまたは VMware 移行元プロバイダーを追加できます。
4.1.1.1. VMware 移行元プロバイダーの追加
MTV Web コンソールを使用して VMware 移行元プロバイダーを追加できます。
前提条件
- すべてのクラスターがアクセスできるセキュアなレジストリーに VMware Virtual Disk Development Kit (VDDK) イメージがある。
手順
- MTV Web コンソールで、Providers をクリックします。
- Add provider をクリックします。
- Type の一覧から VMware を選択します。
以下のフィールドに入力します。
- Name: プロバイダー一覧に表示する名前
- Hostname or IP address: vCenter ホスト名または IP アドレス
-
Username: vCenter ユーザー (例:
user@vsphere.local
) - Password: vCenter ユーザーパスワード
- VDDK init image: VDDKInitImage パス
- Verify certificate をクリックします。
- I trust the authenticity of this certificate チェックボックスを選択します。
Add をクリックしてプロバイダーを追加し、保存します。
移行元プロバイダーがプロバイダーのリストに表示されます。
4.1.1.1.1. VMware ソースプロバイダーの移行ネットワークの選択
MTV Web コンソールで移行元プロバイダーの移行ネットワークを選択して、移行元環境のリスクを軽減し、パフォーマンスを向上できます。
移行に管理ネットワークを使用すると、ネットワークに十分な帯域幅がないためにパフォーマンスが低下する可能性があります。この状況は、ディスク転送操作がネットワークを飽和状態にし、移行元プラットフォームに悪影響を及ぼす可能性があります。
前提条件
- 移行ネットワークにディスク転送に十分なスループット (最低速度は 10 Gbps) がある。
デフォルトゲートウェイを使用して、OpenShift Virtualization ノードから移行ネットワークにアクセスできる。
注記ソースの仮想ディスクは、ターゲット namespace の Pod ネットワークに接続されている Pod によってコピーされます。
- 移行ネットワークで、ジャンボフレームを有効にしている。
手順
- MTV Web コンソールで、Providers をクリックします。
- VMware タブをクリックします。
- プロバイダーの横にある Hosts 列のホスト番号をクリックし、ホストの一覧を表示します。
- 1 つまたは複数のホストを選択し、Select migration network をクリックします。
Network を選択します。
デフォルトネットワークを選択して、選択を解除できます。
移行元プロバイダーが VMware の場合は、以下のフィールドを入力します。
-
ESXi host admin username: ESXi ホスト管理ユーザー名を指定します (例:
root
)。 - ESXi host admin password: ESXi ホストの admin パスワードを指定します。
-
ESXi host admin username: ESXi ホスト管理ユーザー名を指定します (例:
移行元プロバイダーが Red Hat Virtualization の場合は、以下のフィールドを入力します。
- Username: Manager ユーザーを指定します。
- Password: Manager のパスワードを指定します。
- Save をクリックします。
各ホストのステータスが Ready であることを確認します。
ホストのステータスが Ready でない場合、移行ネットワーク上でホストに到達できないか、クレデンシャルが正しくない可能性があります。ホスト設定を変更して、変更を保存できます。
4.1.1.2. Red Hat Virtualization 移行元プロバイダーの追加
MTV Web コンソールを使用して Red Hat Virtualization 移行元プロバイダーを追加できます。
前提条件
- Manager の CA 証明書。
- Manager の Apache CA 証明書 (Manager の Apache CA 証明書がサードパーティーの CA 証明書に置き換えられた場合)。
手順
- MTV Web コンソールで、Providers をクリックします。
- Add provider をクリックします。
- Type の一覧から Red Hat Virtualization を選択します。
以下のフィールドに入力します。
- Name: プロバイダー一覧に表示する名前
- Hostname or IP address: Manager ホスト名または IP アドレス
- Username: Manager ユーザー
- Password: Manager パスワード
- CA certificate: Manager の CA 証明書Manager Apache CA 証明書がサードパーティーの CA 証明書に置き換えられた場合は、両方の CA 証明書を指定する必要があります。
Add をクリックしてプロバイダーを追加し、保存します。
移行元プロバイダーがプロバイダーのリストに表示されます。
4.1.2. 移行先プロバイダーの追加
MTV Web コンソールを使用して OpenShift Virtualization 移行先プロバイダーを追加できます。
4.1.2.1. OpenShift Virtualization 移行先プロバイダーの追加
MTV をインストールしたプロバイダーであるデフォルトの OpenShift Virtualization 移行先プロバイダーに加えて、OpenShift Virtualization 移行先プロバイダーを MTV Web コンソールに追加できます。
前提条件
-
cluster-admin
権限を持つ OpenShift Virtualization サービスアカウントトークン。
手順
- MTV Web コンソールで、Providers をクリックします。
- Add provider をクリックします。
- Type の一覧から OpenShift Virtualization を選択します。
以下のフィールドに入力します。
- Cluster name: ターゲットプロバイダーの一覧で表示するクラスター名を指定します。
- URL: クラスターの API エンドポイントを指定します。
-
Service account token:
cluster-admin
サービスアカウントトークンを指定します。
- Check connection をクリックしてクレデンシャルを確認します。
追加 をクリックします。
プロバイダーがプロバイダーの一覧に表示されます。
4.1.2.2. OpenShift Virtualization プロバイダーの移行ネットワークの選択
MTV Web コンソールで OpenShift Virtualization プロバイダーのデフォルトの移行ネットワークを選択し、パフォーマンスを向上させることができます。デフォルトの移行ネットワークは、ディスクが設定された namespace にディスクを転送するために使用されます。
移行ネットワークを選択しない場合、デフォルトの移行ネットワークは pod
ネットワークで、ディスク転送に最適ではない可能性があります。
移行計画の作成時に別のネットワークを選択して、プロバイダーのデフォルトの移行ネットワークを上書きできます。
手順
- MTV Web コンソールで、Providers をクリックします。
- OpenShift Virtualization タブをクリックします。
- プロバイダーを選択し、Select migration network をクリックします。
- 利用可能なネットワークの一覧からネットワークを選択し、Select をクリックします。
- プロバイダーの横にある Networks 列にあるネットワーク番号をクリックして、選択したネットワークがデフォルトの移行ネットワークであることを確認します。
4.2. ネットワークマッピングの作成
MTV Web コンソールを使用して、移行元ネットワークを OpenShift Virtualization ネットワークにマッピングすることで、1 つ以上のネットワークマッピングを作成できます。
前提条件
- Web コンソールに移行元および移行先プロバイダーが追加されている。
- 複数の移行元および移行先ネットワークをマッピングする場合、それぞれの追加の OpenShift Virtualization ネットワークに独自の ネットワーク割り当て定義 が設定されている。
手順
- Mappings をクリックします。
- Network タブをクリックしてから、Create mapping をクリックします。
以下のフィールドに入力します。
- Name: ネットワークマッピング一覧に表示する名前を入力します。
- Source provider: 移行元プロバイダーを選択します。
- Target provider: 移行先プロバイダーを選択します。
- Source networks: 移行元ネットワークを選択します。
- Target namespaces/networks: 移行先ネットワークを選択します。
- オプション:Add をクリックして追加のネットワークマッピングを作成するか、複数の移行元ネットワークを単一の移行先ネットワークにマッピングします。
- 追加ネットワークのマッピングを作成する場合は、ネットワーク接続定義を移行先ネットワークとして選択します。
Create をクリックします。
ネットワークマッピングは、Network mappings 画面に表示されます。
4.3. ストレージマッピングの作成
MTV Web コンソールを使用してストレージマッピングを作成し、移行元データストアを OpenShift Virtualization ストレージクラスにマッピングできます。
前提条件
- Web コンソールに移行元および移行先プロバイダーが追加されている。
- 仮想マシンの移行をサポートするローカルおよび共有の永続ストレージ。
手順
- Mappings をクリックします。
- Storage タブをクリックし、Create mapping をクリックします。
- ストレージマッピングの Name を入力します。
- Source provider および Target provider を選択します。
- 移行元プロバイダーが VMware の場合は、Source datastore および Target storage class を選択します。
- 移行元プロバイダーが Red Hat Virtualization の場合は、Source storage domain および Target storage class を選択します。
- オプション: Add をクリックして追加のストレージマッピングを作成するか、複数のデータストアまたはストレージドメインを単一のストレージクラスにマッピングします。
Create をクリックします。
マッピングは Storage mappings ページに表示されます。
4.4. 移行計画の作成
MTV の Web コンソールを使用して、移行プランを作成することができます。
移行計画により、一緒に移行する仮想マシンまたは同じ移行パラメーターの仮想マシン (一定の割合のクラスターのメンバーやアプリケーション全体など) をグループ化できます。
移行計画の指定された段階で Ansible Playbook またはカスタムコンテナーイメージを実行するようにフックを設定できます。
前提条件
- MTV が移行先クラスターにインストールされていない場合は、Web コンソールの Providers ページで移行先プロバイダーを追加している。
手順
- Web コンソールで、Migration plans をクリックしてから、Create migration plan をクリックします。
以下のフィールドに入力します。
- Plan name: 移行プラン一覧に表示する移行プラン名を入力します。
- Plan description: オプション: 移行計画の簡単な説明。
- Source provider: 移行元プロバイダーを選択します。
- Target provider: 移行先プロバイダーを選択します。
- Target namespace: 既存の移行先 namespace を入力して検索するか、または新規 namespace を作成できます。
Select a different network をクリックして、リストからネットワークを選択し、Select をクリックして、このプランの移行転送ネットワークを変更できます。
OpenShift Virtualization プロバイダーの移行転送ネットワークを定義し、ネットワークが移行先 namespace にある場合、そのネットワークがすべての移行プランのデフォルトネットワークになります。それ以外の場合には、
pod
ネットワークが使用されます。
- Next をクリックします。
- ソース仮想マシンのリストをフィルタリングするオプションを選択し、Next をクリックします。
- 移行する仮想マシンを選択し、Next をクリックします。
既存のネットワークマッピングを選択するか、新しいネットワークマッピングを作成します。
新規ネットワークマッピングを作成するには、以下を実行します。
- 各移行元ネットワークに対する移行先ネットワークを選択します。
- オプション: Save mapping to use again を選択し、ネットワークマッピング名を入力します。
- Next をクリックします。
既存のストレージマッピングを選択するか、または新規ストレージマッピングを作成します。
新規ストレージマッピングを作成するには、以下を実行します。
- VMware データストアまたは Red Hat Virtualization ストレージドメインに移行先ストレージクラスを選択します。
- オプション: Save mapping to use again を選択し、ストレージマッピング名を入力します。
- Next をクリックします。
移行のタイプを選択し、Next をクリックします。
- コールド移行: データのコピー中にソース仮想マシンは停止します。
- ウォーム移行: データが段階的にコピーされる間にソース仮想マシンは実行されます。後でカットオーバーを実行し、仮想マシンを停止し、残りの仮想マシンデータとメタデータをコピーします。
オプション: 移行フックを作成して、移行前または移行後に Ansible Playbook を実行できます。
- Add hook をクリックします。
- フックの実行時のステップを選択します。
フック定義を選択します。
- Ansible Playbook: Ansible Playbook を参照するか、フィールドに貼り付けます。
Custom container image: デフォルトの
hook-runner
イメージを使用しない場合は、イメージパス<registry_path>/<image_name>:<tag>
を入力します。注記レジストリーは OpenShift Container Platform クラスターからアクセスできる必要がある。
- Next をクリックします。
移行プランを確認し、Finish をクリックします。
移行プランは移行プランの一覧に保存されます。
- 移行計画の Options メニュー をクリックし、View details を選択して移行計画の詳細を確認します。
4.5. 移行プランの実行
移行プランを実行し、その進捗状況を MTV Web コンソールで表示できます。
前提条件
- 有効な移行計画が作成されている。
手順
Migration plans をクリックします。
Migration plans リストには、移行元プロバイダーと移行先プロバイダー、移行する仮想マシン (VM) の数、および計画のステータスが表示されます。
移行プランの横にある Start をクリックして移行を開始します。
ウォーム移行のみ:
- プレコピー段階が開始されます。
- Cutover クリックして移行を完了します。
移行プランを展開し、移行の詳細を表示します。
移行の詳細画面には、移行の開始時刻と終了時刻、コピーされたデータ量、および移行される各仮想マシンの進捗パイプラインが表示されます。
- VM を展開して、移行ステップ、各ステップの経過時間、およびその状態を表示します。
4.6. 移行計画のオプション
MTV Web コンソールの Migration plans ページで、移行計画の横にある Options メニュー をクリックして以下のオプションにアクセスできます。
- Edit: 移行計画の詳細を編集します。移行計画の実行中または正常に完了した後は、移行計画を編集できません。
Duplicate: 既存の計画と同じ仮想マシン (VM)、パラメーター、マッピング、およびフックを使用して、新しい移行計画を作成します。この機能は、以下のタスクに使用できます。
- VM を別の namespace に移行する。
- アーカイブされた移行計画を編集する。
- ステータスが異なる移行計画を編集する (例: 失敗、キャンセル、実行中、クリティカル、準備完了)。
Archive: 移行計画のログ、履歴、メタデータを削除します。計画を編集または再起動することはできません。閲覧のみ可能です。
注記Archive オプションは元に戻せません。ただし、アーカイブされた計画を複製することはできます。
Delete: 移行計画を完全に削除します。実行中の移行計画を削除することはできません。
注記Delete オプションは元に戻せません。
移行計画を削除しても、
importer
Pod、conversion
Pod、設定マップ、シークレット、失敗した VM、データボリュームなどの一時的なリソースは削除されません。(BZ#2018974) 一時的なリソースをクリーンアップするために、移行計画を削除する前にアーカイブする必要があります。- View details: 移行計画の詳細を表示します。
- Restart: 失敗またはキャンセルした移行計画を再起動します。
- Cancel scheduled cutover: ウォーム移行計画に対してスケジュールされたカットオーバー移行をキャンセルします。
4.7. 移行のキャンセル
MTV Web コンソールを使用して、移行計画が進行中に、一部またはすべての仮想マシン (VM) の移行をキャンセルすることができます。
手順
- Migration Plans をクリックします。
- 実行中の移行プランの名前をクリックし、移行の詳細を表示します。
- 1 つ以上の仮想マシンを選択し、Cancel をクリックします。
Yes, cancel をクリックしてキャンセルを確定します。
Migration details by VM 一覧では、キャンセルした仮想マシンのステータスは Canceled になります。移行されていない仮想マシンと移行された仮想マシンは影響を受けません。
Migration plans ページの移行計画の横にある Restart をクリックして、キャンセルした移行を再開できます。
第5章 コマンドラインからの仮想マシンの移行
コマンドラインから仮想マシンを OpenShift Virtualization に移行できます。
-
cluster-admin
権限を持つユーザーとしてログインしている。 - VMware のみ: 最小限の VMware の権限 セットが必要です。
- VMware のみ:vCenter SHA-1 フィンガープリント が必要です。
- VMware のみ: VMware Virtual Disk Development Kit (VDDK) イメージを作成する必要があります。
- すべての 前提条件 を満たしていることを確認する必要があります。
5.1. 仮想マシンの移行
MTV カスタムリソース (CR) を作成して、仮想マシン (VM) をコマンドライン (CLI) から移行します。
クラスタースコープの CR の名前を指定する必要があります。
namespace スコープの CR の名前と namespace の両方を指定する必要があります。
前提条件
-
cluster-admin
権限を持つユーザーとしてログインしている。 - VMware のみ: すべてのクラスターがアクセスできるセキュアなレジストリーに VMware Virtual Disk Development Kit (VDDK) イメージを用意しておく。
手順
ソースプロバイダーの認証情報の
Secret
マニフェストを作成します。$ cat << EOF | oc apply -f - apiVersion: v1 kind: Secret metadata: name: <secret> namespace: openshift-mtv type: Opaque stringData: user: <user> 1 password: <password> 2 cacert: | 3 <engine_ca_certificate> thumbprint: <vcenter_fingerprint> 4 EOF
ソースプロバイダーの
Provider
マニフェストを作成します。$ cat << EOF | oc apply -f - apiVersion: forklift.konveyor.io/v1beta1 kind: Provider metadata: name: <provider> namespace: openshift-mtv spec: type: <provider_type> 1 url: <api_end_point> 2 settings: vddkInitImage: <registry_route_or_server_path>/vddk:<tag> 3 secret: name: <secret> 4 namespace: openshift-mtv EOF
VMware のみ:
Host
マニフェストを作成します。$ cat << EOF | oc apply -f - apiVersion: forklift.konveyor.io/v1beta1 kind: Host metadata: name: <vmware_host> namespace: openshift-mtv spec: provider: namespace: openshift-mtv name: <source_provider> 1 id: <source_host_mor> 2 ipAddress: <source_network_ip> 3 EOF
移行元および宛先ネットワークをマッピングする
NetworkMap
マニフェストを作成します。$ cat << EOF | oc apply -f - apiVersion: forklift.konveyor.io/v1beta1 kind: NetworkMap metadata: name: <network_map> namespace: openshift-mtv spec: map: - destination: name: <pod> namespace: openshift-mtv type: pod 1 source: 2 id: <source_network_id> 3 name: <source_network_name> - destination: name: <network_attachment_definition> 4 namespace: <network_attachment_definition_namespace> 5 type: multus source: id: <source_network_id> name: <source_network_name> provider: source: name: <source_provider> namespace: openshift-mtv destination: name: <destination_cluster> namespace: openshift-mtv EOF
StorageMap
マニフェストを作成し、ソースおよび宛先ストレージをマッピングします。$ cat << EOF | oc apply -f - apiVersion: forklift.konveyor.io/v1beta1 kind: StorageMap metadata: name: <storage_map> namespace: openshift-mtv spec: map: - destination: storageClass: <storage_class> accessMode: <access_mode> 1 source: id: <source_datastore> 2 - destination: storageClass: <storage_class> accessMode: <access_mode> source: id: <source_datastore> provider: source: name: <source_provider> namespace: openshift-mtv destination: name: <destination_cluster> namespace: openshift-mtv EOF
オプション:
Hook
マニフェストを作成し、Plan
CR で指定されたフェーズ中に VM でカスタムコードを実行します。$ cat << EOF | oc apply -f - apiVersion: forklift.konveyor.io/v1beta1 kind: Hook metadata: name: <hook> namespace: openshift-mtv spec: image: quay.io/konveyor/hook-runner 1 playbook: | 2 LS0tCi0gbmFtZTogTWFpbgogIGhvc3RzOiBsb2NhbGhvc3QKICB0YXNrczoKICAtIG5hbWU6IExv YWQgUGxhbgogICAgaW5jbHVkZV92YXJzOgogICAgICBmaWxlOiAiL3RtcC9ob29rL3BsYW4ueW1s IgogICAgICBuYW1lOiBwbGFuCiAgLSBuYW1lOiBMb2FkIFdvcmtsb2FkCiAgICBpbmNsdWRlX3Zh cnM6CiAgICAgIGZpbGU6ICIvdG1wL2hvb2svd29ya2xvYWQueW1sIgogICAgICBuYW1lOiB3b3Jr bG9hZAoK EOF
移行の
Plan
マニフェストを作成します。$ cat << EOF | oc apply -f - apiVersion: forklift.konveyor.io/v1beta1 kind: Plan metadata: name: <plan> 1 namespace: openshift-mtv spec: warm: true 2 provider: source: name: <source_provider> namespace: openshift-mtv destination: name: <destination_cluster> namespace: openshift-mtv map: network: 3 name: <network_map> 4 namespace: openshift-mtv storage: name: <storage_map> 5 namespace: openshift-mtv targetNamespace: openshift-mtv vms: 6 - id: <source_vm> 7 - name: <source_vm> hooks: 8 - hook: namespace: openshift-mtv name: <hook> 9 step: <step> 10 EOF
- 1
Plan
CR の名前を指定します。- 2
- 移行がウォームまたはコールドであるかどうかを指定します。
Migration
CR マニフェストでcutover
パラメーターの値を指定せずにウォーム移行を指定する場合は、プレコピー段階のみが実行されます。 - 3
- 複数のネットワークマッピングを追加することができます。
- 4
NetworkMap
CR の名前を指定します。- 5
StorageMap
CR の名前を指定します。- 6
id
パラメーター またはname
パラメーターのいずれかを使用して、ソース仮想マシンを指定することができます。- 7
- VMware 仮想マシン MOR または RHV 仮想マシンの UUID を指定します。
- 8
- オプション: 仮想マシンのフックを最大 2 つ指定できます。各フックは個別の移行ステップで実行する必要があります。
- 9
Hook
CR の名前を指定します。- 10
- 移行完了後の移行プランの開始前または
PostHook
の前の許容値は、PreHook
です。
Plan
CR を実行するためのMigration
マニフェストを作成します。$ cat << EOF | oc apply -f - apiVersion: forklift.konveyor.io/v1beta1 kind: Migration metadata: name: <migration> 1 namespace: openshift-mtv spec: plan: name: <plan> 2 namespace: openshift-mtv cutover: <cutover_time> 3 EOF
複数の
Migration
CR を単一のPlan
CR に関連付けることができます。移行が完了しない場合は、Plan
CR を変更せずに新規Migration
CR を作成して残りの仮想マシンを移行できます。移行の進捗をモニタリングするための
Migration
CR を取得します。$ oc get migration/<migration> -n openshift-mtv -o yaml
5.2. vCenter ホストの SHA-1 フィンガープリントの取得
Secret
CR を作成するには、vCenter ホストの SHA-1 フィンガープリントを取得する必要があります。
手順
以下のコマンドを実行します。
$ openssl s_client \ -connect <vcenter_host>:443 \ 1 < /dev/null 2>/dev/null \ | openssl x509 -fingerprint -noout -in /dev/stdin \ | cut -d '=' -f 2
- 1
- vCenter ホストの IP アドレスまたは FQDN を指定します。
出力例
01:23:45:67:89:AB:CD:EF:01:23:45:67:89:AB:CD:EF:01:23:45:67
5.3. 移行のキャンセル
コマンドラインインターフェイス (CLI) から、移行の進行中に、移行全体または個々の仮想マシン (VM) の移行をキャンセルできます。
移行全体のキャンセル
Migration
CR を削除します。$ oc delete migration <migration> -n openshift-mtv 1
- 1
Migration
CR の名前を指定します。
個別の仮想マシンの移行のキャンセル
Migration
マニフェストのspec.cancel
ブロックに個別の VM を追加します。$ cat << EOF | oc apply -f - apiVersion: forklift.konveyor.io/v1beta1 kind: Migration metadata: name: <migration> namespace: openshift-mtv ... spec: cancel: - id: vm-102 1 - id: vm-203 - name: rhel8-vm EOF
- 1
id
キーまたはname
キーを使用して VM を指定できます。
id
キーの値は、VMware VM の場合は管理対象オブジェクト参照、RHV VM の場合は VM UUID です。残りの VM の進捗をモニタリングするための
Migration
CR を取得します。$ oc get migration/<migration> -n openshift-mtv -o yaml
第6章 高度な移行オプション
6.1. ウォーム移行のプレコピー間隔の変更
ForkliftController
カスタムリソース (CR) にパッチを適用して、スナップショットの間隔を変更できます。
手順
ForkliftController
CR にパッチを適用します。$ oc patch forkliftcontroller/<forklift-controller> -n openshift-mtv -p '{"spec": {"controller_precopy_interval": <60>}}' --type=merge 1
- 1
- プレコピーの間隔を分単位で指定します。デフォルト値は
60
です。
forklift-controller
Pod を再起動する必要はありません。
6.2. Validation サービスのカスタムルールの作成
Validation
サービスは Open Policy Agent (OPA) ポリシールールを使用して、移行に対する各仮想マシン (VM) の適合性を確認します。Validation
サービスは、各 VM の concerns 一覧を生成します。これは、Provider Inventory
サービスに VM 属性として保存されます。Web コンソールには、プロバイダーインベントリー内の各 VM の concerns が表示されます。
カスタムルールを作成して、Validation
サービスのデフォルトルールセットを拡張することができます。たとえば、VM に複数のディスクがあるかどうかを確認するルールを作成できます。
6.2.1. Rego ファイルについて
検証ルールは、Open Policy Agent (OPA) のネイティブクエリー言語である Rego で記述されます。ルールは、Validation
Pod の /usr/share/opa/policies/io/konveyor/forklift/<provider>
ディレクトリーに .rego
ファイルとして保存されます。
各検証ルールは、個別の .rego
ファイルに定義され、特定の条件をテストします。条件が true
と評価された場合、ルールは {“category", “label", “assessment"}
ハッシュを concerns
に追加します。concerns
のコンテンツは、VM のインベントリーレコードの concerns
キーに追加されます。Web コンソールには、プロバイダーインベントリー内の各 VM の concerns
キーのコンテンツが表示されます。
次の .rego
ファイルの例では、VMware VM のクラスターで有効になっている分散リソーススケジューリングを確認します。
drs_enabled.rego の例
package io.konveyor.forklift.vmware 1 has_drs_enabled { input.host.cluster.drsEnabled 2 } concerns[flag] { has_drs_enabled flag := { "category": "Information", "label": "VM running in a DRS-enabled cluster", "assessment": "Distributed resource scheduling is not currently supported by OpenShift Virtualization. The VM can be migrated but it will not have this feature in the target environment." } }
6.2.2. デフォルトの検証ルールの確認
カスタムルールを作成する前に、Validation
サービスのデフォルトルールを確認して、既存のデフォルト値を再定義するルールを作成しないようにする必要があります。
例: デフォルトのルールに default valid_input = false
の行が含まれていて、default valid_input = true
の行が含まれるカスタムルールを作成した場合、Validation
サービスは起動しません。
手順
Validation
Pod のターミナルに接続します。$ oc rsh <validation_pod>
プロバイダーの OPA ポリシーディレクトリーに移動します。
$ cd /usr/share/opa/policies/io/konveyor/forklift/<provider> 1
- 1
vmware
またはovirt
を指定します。
デフォルトポリシーを検索します。
$ grep -R "default" *
6.2.3. Inventory サービス JSON の取得
Inventory
サービスクエリーを仮想マシン (VM) に送信して Inventory
サービス JSON を取得します。出力には "input"
キーが含まれます。このキーには、Validation
サービスルールによってクエリーされるインベントリー属性が含まれます。
検証ルールは、"input"
キーの任意の属性に基づいて作成できます (例: input.snapshot.kind
)。
手順
プロジェクトのルートを取得します。
oc get route -n openshift-mtv
Inventory
サービスルートを取得します。$ oc get route <inventory_service> -n openshift-mtv
アクセストークンを取得します。
$ TOKEN=$(oc whoami -t)
HTTP GET リクエストをトリガーします (たとえば、Curl を使用):
$ curl -H "Authorization: Bearer $TOKEN" https://<inventory_service_route>/providers -k
プロバイダーの
UUID
を取得します。$ curl -H "Authorization: Bearer $TOKEN" https://<inventory_service_route>/providers/<provider> -k 1
- 1
- プロバイダーで使用できる値は
vsphere
およびovirt
です。
プロバイダーの VM を取得します。
$ curl -H "Authorization: Bearer $TOKEN" https://<inventory_service_route>/providers/<provider>/<UUID>/vms -k
VM の詳細を取得します。
$ curl -H "Authorization: Bearer $TOKEN" https://<inventory_service_route>/providers/<provider>/<UUID>/workloads/<vm> -k
出力例
{ "input": { "selfLink": "providers/vsphere/c872d364-d62b-46f0-bd42-16799f40324e/workloads/vm-431", "id": "vm-431", "parent": { "kind": "Folder", "id": "group-v22" }, "revision": 1, "name": "iscsi-target", "revisionValidated": 1, "isTemplate": false, "networks": [ { "kind": "Network", "id": "network-31" }, { "kind": "Network", "id": "network-33" } ], "disks": [ { "key": 2000, "file": "[iSCSI_Datastore] iscsi-target/iscsi-target-000001.vmdk", "datastore": { "kind": "Datastore", "id": "datastore-63" }, "capacity": 17179869184, "shared": false, "rdm": false }, { "key": 2001, "file": "[iSCSI_Datastore] iscsi-target/iscsi-target_1-000001.vmdk", "datastore": { "kind": "Datastore", "id": "datastore-63" }, "capacity": 10737418240, "shared": false, "rdm": false } ], "concerns": [], "policyVersion": 5, "uuid": "42256329-8c3a-2a82-54fd-01d845a8bf49", "firmware": "bios", "powerState": "poweredOn", "connectionState": "connected", "snapshot": { "kind": "VirtualMachineSnapshot", "id": "snapshot-3034" }, "changeTrackingEnabled": false, "cpuAffinity": [ 0, 2 ], "cpuHotAddEnabled": true, "cpuHotRemoveEnabled": false, "memoryHotAddEnabled": false, "faultToleranceEnabled": false, "cpuCount": 2, "coresPerSocket": 1, "memoryMB": 2048, "guestName": "Red Hat Enterprise Linux 7 (64-bit)", "balloonedMemory": 0, "ipAddress": "10.19.2.96", "storageUsed": 30436770129, "numaNodeAffinity": [ "0", "1" ], "devices": [ { "kind": "RealUSBController" } ], "host": { "id": "host-29", "parent": { "kind": "Cluster", "id": "domain-c26" }, "revision": 1, "name": "IP address or host name of the vCenter host or RHV Engine host", "selfLink": "providers/vsphere/c872d364-d62b-46f0-bd42-16799f40324e/hosts/host-29", "status": "green", "inMaintenance": false, "managementServerIp": "10.19.2.96", "thumbprint": <thumbprint>, "timezone": "UTC", "cpuSockets": 2, "cpuCores": 16, "productName": "VMware ESXi", "productVersion": "6.5.0", "networking": { "pNICs": [ { "key": "key-vim.host.PhysicalNic-vmnic0", "linkSpeed": 10000 }, { "key": "key-vim.host.PhysicalNic-vmnic1", "linkSpeed": 10000 }, { "key": "key-vim.host.PhysicalNic-vmnic2", "linkSpeed": 10000 }, { "key": "key-vim.host.PhysicalNic-vmnic3", "linkSpeed": 10000 } ], "vNICs": [ { "key": "key-vim.host.VirtualNic-vmk2", "portGroup": "VM_Migration", "dPortGroup": "", "ipAddress": "192.168.79.13", "subnetMask": "255.255.255.0", "mtu": 9000 }, { "key": "key-vim.host.VirtualNic-vmk0", "portGroup": "Management Network", "dPortGroup": "", "ipAddress": "10.19.2.13", "subnetMask": "255.255.255.128", "mtu": 1500 }, { "key": "key-vim.host.VirtualNic-vmk1", "portGroup": "Storage Network", "dPortGroup": "", "ipAddress": "172.31.2.13", "subnetMask": "255.255.0.0", "mtu": 1500 }, { "key": "key-vim.host.VirtualNic-vmk3", "portGroup": "", "dPortGroup": "dvportgroup-48", "ipAddress": "192.168.61.13", "subnetMask": "255.255.255.0", "mtu": 1500 }, { "key": "key-vim.host.VirtualNic-vmk4", "portGroup": "VM_DHCP_Network", "dPortGroup": "", "ipAddress": "10.19.2.231", "subnetMask": "255.255.255.128", "mtu": 1500 } ], "portGroups": [ { "key": "key-vim.host.PortGroup-VM Network", "name": "VM Network", "vSwitch": "key-vim.host.VirtualSwitch-vSwitch0" }, { "key": "key-vim.host.PortGroup-Management Network", "name": "Management Network", "vSwitch": "key-vim.host.VirtualSwitch-vSwitch0" }, { "key": "key-vim.host.PortGroup-VM_10G_Network", "name": "VM_10G_Network", "vSwitch": "key-vim.host.VirtualSwitch-vSwitch1" }, { "key": "key-vim.host.PortGroup-VM_Storage", "name": "VM_Storage", "vSwitch": "key-vim.host.VirtualSwitch-vSwitch1" }, { "key": "key-vim.host.PortGroup-VM_DHCP_Network", "name": "VM_DHCP_Network", "vSwitch": "key-vim.host.VirtualSwitch-vSwitch1" }, { "key": "key-vim.host.PortGroup-Storage Network", "name": "Storage Network", "vSwitch": "key-vim.host.VirtualSwitch-vSwitch1" }, { "key": "key-vim.host.PortGroup-VM_Isolated_67", "name": "VM_Isolated_67", "vSwitch": "key-vim.host.VirtualSwitch-vSwitch2" }, { "key": "key-vim.host.PortGroup-VM_Migration", "name": "VM_Migration", "vSwitch": "key-vim.host.VirtualSwitch-vSwitch2" } ], "switches": [ { "key": "key-vim.host.VirtualSwitch-vSwitch0", "name": "vSwitch0", "portGroups": [ "key-vim.host.PortGroup-VM Network", "key-vim.host.PortGroup-Management Network" ], "pNICs": [ "key-vim.host.PhysicalNic-vmnic4" ] }, { "key": "key-vim.host.VirtualSwitch-vSwitch1", "name": "vSwitch1", "portGroups": [ "key-vim.host.PortGroup-VM_10G_Network", "key-vim.host.PortGroup-VM_Storage", "key-vim.host.PortGroup-VM_DHCP_Network", "key-vim.host.PortGroup-Storage Network" ], "pNICs": [ "key-vim.host.PhysicalNic-vmnic2", "key-vim.host.PhysicalNic-vmnic0" ] }, { "key": "key-vim.host.VirtualSwitch-vSwitch2", "name": "vSwitch2", "portGroups": [ "key-vim.host.PortGroup-VM_Isolated_67", "key-vim.host.PortGroup-VM_Migration" ], "pNICs": [ "key-vim.host.PhysicalNic-vmnic3", "key-vim.host.PhysicalNic-vmnic1" ] } ] }, "networks": [ { "kind": "Network", "id": "network-31" }, { "kind": "Network", "id": "network-34" }, { "kind": "Network", "id": "network-57" }, { "kind": "Network", "id": "network-33" }, { "kind": "Network", "id": "dvportgroup-47" } ], "datastores": [ { "kind": "Datastore", "id": "datastore-35" }, { "kind": "Datastore", "id": "datastore-63" } ], "vms": null, "networkAdapters": [], "cluster": { "id": "domain-c26", "parent": { "kind": "Folder", "id": "group-h23" }, "revision": 1, "name": "mycluster", "selfLink": "providers/vsphere/c872d364-d62b-46f0-bd42-16799f40324e/clusters/domain-c26", "folder": "group-h23", "networks": [ { "kind": "Network", "id": "network-31" }, { "kind": "Network", "id": "network-34" }, { "kind": "Network", "id": "network-57" }, { "kind": "Network", "id": "network-33" }, { "kind": "Network", "id": "dvportgroup-47" } ], "datastores": [ { "kind": "Datastore", "id": "datastore-35" }, { "kind": "Datastore", "id": "datastore-63" } ], "hosts": [ { "kind": "Host", "id": "host-44" }, { "kind": "Host", "id": "host-29" } ], "dasEnabled": false, "dasVms": [], "drsEnabled": true, "drsBehavior": "fullyAutomated", "drsVms": [], "datacenter": null } } } }
6.2.4. 検証ルールの作成
ルールを含む設定マップカスタムリソース (CR) を Validation
サービスに適用して、検証ルールを作成します。
-
既存のルールと同じ名前でルールを作成すると、
Validation
サービスは、それらのルールでOR
操作を実行します。 -
デフォルトのルールと矛盾するルールを作成すると、
Validation
サービスは開始されません。
検証ルールの例
検証ルールは、Provider Inventory
サービスが収集する仮想マシン (VM) 属性に基づいています。
たとえば、VMware API はこのパス (MOR:Virtual Machine.config.extra Config["numa.node Affinity"]
) を使用して、VMware VM に NUMA ノードアフィニティーが設定されているかどうかを確認します。
Provider Inventory
サービスは、この設定を簡素化し、テスト可能な属性を、リストの値で返します。
"numaNodeAffinity": [ "0", "1" ],
この属性に基づいて Rego クエリーを作成し、それを forklift-validation-config
設定マップに追加します。
`count(input.numaNodeAffinity) != 0`
手順
以下の例に従って設定マップ CR を作成します。
$ cat << EOF | oc apply -f - apiVersion: v1 kind: ConfigMap metadata: name: <forklift-validation-config> namespace: openshift-mtv data: vmware_multiple_disks.rego: |- package <provider_package> 1 has_multiple_disks { 2 count(input.disks) > 1 } concerns[flag] { has_multiple_disks 3 flag := { "category": "<Information>", 4 "label": "Multiple disks detected", "assessment": "Multiple disks detected on this VM." } } EOF
forklift-controller
デプロイメントを0
にスケーリングして、Validation
Pod を停止します。$ oc scale -n openshift-mtv --replicas=0 deployment/forklift-controller
forklift-controller
デプロイメントを1
にスケーリングして、Validation
Pod を起動します。$ oc scale -n openshift-mtv --replicas=1 deployment/forklift-controller
Validation
Pod ログをチェックして、Pod が起動したことを確認します。$ oc logs -f <validation_pod>
カスタムルールがデフォルトのルールと競合する場合、
Validation
Pod は起動しません。ソースプロバイダーを削除します。
$ oc delete provider <provider> -n openshift-mtv
ソースプロバイダーを追加して、新規ルールを適用します。
$ cat << EOF | oc apply -f - apiVersion: forklift.konveyor.io/v1beta1 kind: Provider metadata: name: <provider> namespace: openshift-mtv spec: type: <provider_type> 1 url: <api_end_point> 2 secret: name: <secret> 3 namespace: openshift-mtv EOF
カスタムルールを作成した後、ルールのバージョンを更新して、Inventory
サービスが変更を検出し、VM を検証できるようにする必要があります。
6.2.5. インベントリールールバージョンの更新
Provider Inventory
サービスが変更を検出して Validation
サービスをトリガーするように、ルールを更新するたびにインベントリールールのバージョンを更新する必要があります。
ルールバージョンは、各プロバイダーの rules_version.rego
ファイルに記録されます。
手順
現在のルールバージョンを取得します。
$ GET https://forklift-validation/v1/data/io/konveyor/forklift/<provider>/rules_version 1
出力例
{ "result": { "rules_version": 5 } }
Validation
Pod のターミナルに接続します。$ oc rsh <validation_pod>
-
/usr/share/opa/policies/io/konveyor/forklift/<provider>/rules_version.rego
ファイルでルールバージョンを更新します。 -
Validation
Pod ターミナルからログアウトします。 更新されたルールバージョンを検証します。
$ GET https://forklift-validation/v1/data/io/konveyor/forklift/<provider>/rules_version 1
出力例
{ "result": { "rules_version": 6 } }
第7章 Migration Toolkit for Virtualization のアップグレード
OpenShift Container Platform Web コンソールを使用して新しいバージョンをインストールすることで、MTV Operator をアップグレードできます。
リリースは飛ばさずに、次のリリースにアップグレードする必要があります (例: 2.0 から 2.1 または 2.1 から 2.2)。
手順
- OCP Web コンソールで、Operators → Installed Operators → Migration Tookit for Virtualization Operator → Subscription をクリックします。
更新チャンネルを正しいリリースに変更します。
OpenShift Container Platform のドキュメントで Changing update channel を参照してください。
Upgrade status が Up to date から Upgrade available に変わります。そうでない場合は、
Catalog Source
Pod を再起動します。-
カタログソース (例:
redhat-operators
) に注意してください。 コマンドラインで、カタログソース Pod を取得します。
$ oc get pod -n openshift-marketplace | grep <catalog_source>
Pod を削除します。
$ oc delete pod -n openshift-marketplace <catalog_source_pod>
Upgrade status が Up to date から Upgrade available に変わります。
Subscriptions タブで Update approval を Automatic に設定すると、アップグレードが自動的に開始されます。
-
カタログソース (例:
Subscriptions タブで Update approval を Manual に設定すると、アップグレードが承認されます。
OpenShift Container Platform のドキュメントで Manually approving a pending upgrade を参照してください。
Web コンソールにログインする前に、
forklift-ui
Pod がReady
状態になっていることを確認します。$ oc get pods -n openshift-mtv
出力例
NAME READY STATUS RESTARTS AGE forklift-controller-788bdb4c69-mw268 2/2 Running 0 2m forklift-operator-6bf45b8d8-qps9v 1/1 Running 0 5m forklift-ui-7cdf96d8f6-xnw5n 1/1 Running 0 2m
-
VMware ソースプロバイダーを MTV 2.2 に追加した場合には、MTV 2.3 にアップグレードすると、VMware プロバイダーの状態が Critical に変わります。この問題を修正するには、VDDK
init
イメージを追加して VMware プロバイダーの証明書を確認して、VMwhere プロバイダーを編集します。詳細は、Addding a VMSphere source provider を参照してください。 -
MTV 2.2 の OpenShift Container Platform 宛先プロバイダーの NFS にマッピングされた場合には、MTV 2.3 にアップグレードすると NFS マッピングが無効になります。この問題を修正するには、NFS ストレージプロファイルの
AccessModes
パラメーターおよびVolumeMode
パラメーターを編集します。詳細については、ストレージプロファイルのカスタマイズを参照してください。
第8章 Migration Toolkit for Virtualization のアンインストール
OpenShift Container Platform Web コンソールまたはコマンドラインインターフェイス (CLI) を使用して Migration Toolkit for Virtualization (MTV) をアンインストールできます。
8.1. OpenShift Container Platform Web コンソールを使用した MTV のアンインストール
OpenShift Container Platform Web コンソールを使用して openshift-mtv
プロジェクトおよびカスタムリソース定義 (CRD) を削除し、Migration Toolkit for Virtualization (MTV) をアンインストールできます。
前提条件
-
cluster-admin
権限を持つユーザーとしてログインしている。
手順
- Home → Projects をクリックします。
- openshift-mtv プロジェクトを作成します。
- プロジェクトの右側の Options メニュー から Delete Project を選択します。
- Delete Project ペインで、プロジェクト名を入力し、Delete をクリックします。
- Administration → CustomResourceDefinitions をクリックします。
-
検索 フィールドに
forklift
を入力し、forklift.konveyor.io
グループで CRD を見つけます。 - 各 CRD の右側で、Options メニュー から Delete CustomResourceDefinition を選択します。
8.2. コマンドラインインターフェイスからの MTV のアンインストール
openshift-mtv
プロジェクトおよび forklift.konveyor.io
カスタムリソース定義 (CRD) を削除して、コマンドラインインターフェイス (CLI) から Migration Toolkit for Virtualization (MTV) をアンインストールできます。
前提条件
-
cluster-admin
権限を持つユーザーとしてログインしている。
手順
プロジェクトを削除します。
$ oc delete project openshift-mtv
CRD を削除します。
$ oc get crd -o name | grep 'forklift' | xargs oc delete
OAuthClient を削除します。
$ oc delete oauthclient/forklift-ui
第9章 トラブルシューティング
このセクションでは、一般的な移行の問題をトラブルシューティングするための情報を提供します。
9.1. エラーメッセージ
本セクションでは、エラーメッセージと、その解決方法を説明します。
warm import retry limit reached
VMware 仮想マシン (VM) が、プレコピーの段階で変更ブロックのトラッキング (CBT) スナップショットの最大数 (28) に達した場合は、ウォーム移行時に warm import retry limit reached
エラーメッセージが表示されます。
この問題を解決するには、仮想マシンから CBT スナップショットの一部を削除して、移行計画を再起動します。
Unable to resize disk image to required size
ターゲットプロバイダーの仮想マシンがブロックストレージの EXT4 ファイルシステムで永続ボリュームを使用しているために移行が失敗すると、Unable to resize disk image to required size
エラーメッセージが表示されます。この問題は、CDI が想定するデフォルトのオーバーヘッドに root パーティション用に予約された場所が完全に含まれていないために発生します。
この問題を解決するには、CDI のファイルシステムのオーバーヘッドを 10% 以上に増やします。
9.2. must-gather ツールの使用
must-gather
ツールを使用して、MTV カスタムリソース (CR) のログおよび情報を収集できます。must-gather
データファイルをすべてのカスタマーケースに割り当てる必要があります。
フィルタリングオプションを使用して、特定の namespace、移行計画、または仮想マシンのデータを収集できます。
フィルターされた must-gather
コマンドで存在しないリソースを指定する場合、アーカイブファイルは作成されません。
前提条件
-
cluster-admin
ロールを持つユーザーとして OpenShift Virtualization クラスターにログインしている。 -
OpenShift Container Platform CLI (
oc
) がインストールされている。
ログおよび CR 情報の収集
-
must-gather
データを保存するディレクトリーに移動します。 oc adm must-gather
コマンドを実行します。$ oc adm must-gather --image=registry.redhat.io/migration-toolkit-virtualization/mtv-must-gather-rhel8:2.3.0
データは
/must-gather/must-gather.tar.gz
として保存されます。このファイルを Red Hat カスタマーポータル で作成したサポートケースにアップロードすることができます。オプション:
oc adm must-gather
コマンドに以下のオプションを指定して実行し、フィルターされたデータを収集します。Namespace:
$ oc adm must-gather --image=registry.redhat.io/migration-toolkit-virtualization/mtv-must-gather-rhel8:2.3.0 \ -- NS=<namespace> /usr/bin/targeted
移行計画:
$ oc adm must-gather --image=registry.redhat.io/migration-toolkit-virtualization/mtv-must-gather-rhel8:2.3.0 \ -- PLAN=<migration_plan> /usr/bin/targeted
仮想マシン:
$ oc adm must-gather --image=registry.redhat.io/migration-toolkit-virtualization/mtv-must-gather-rhel8:2.3.0 \ -- VM=<vm_id> NS=<namespace> /usr/bin/targeted 1
9.3. アーキテクチャー
このセクションでは、MTV カスタムリソース、サービス、およびワークフローについて説明します。
9.3.1. MTV カスタムリソースおよびサービス
Migration Toolkit for Virtualization (MTV) は OpenShift Container Platform Operator として提供されます。以下のカスタムリソース (CR) およびサービスを作成し、管理します。
MTV カスタムリソース
-
Provider
CR は、MTV がソースおよびターゲットプロバイダーに接続し、対話できるようにする属性を保存します。 -
NetworkMapping
CR は、ソースおよびターゲットプロバイダーのネットワークをマッピングします。 -
StorageMapping
CR は、ソースおよびターゲットプロバイダーのストレージをマッピングします。 -
Provisioner
CR は、サポートされているボリューム、アクセスモードなどのストレージプロビジョナーの設定を保存します。 -
Plan
CR には、同じ移行パラメーターと関連するネットワークおよびストレージマッピングを持つ仮想マシンの一覧が含まれます。 Migration
CR は移行計画を実行します。一度に実行できる
Migration
CR は、移行計画ごとに 1 つのみです。単一のPlan
CR に複数のMigration
CR を作成できます。
MTV サービス
Inventory
サービスは以下のアクションを実行します。- ソースプロバイダーおよびターゲットプロバイダーに接続します。
- マッピングおよび計画に関するローカルインベントリーを維持します。
- 仮想マシンの設定を保存します。
-
仮想マシンの設定の変更が検出されたら、
Validation
サービスを実行します。
-
Validation
サービスは、ルールを適用して移行の適合性を確認します。 User Interface
サービスは、以下のアクションを実行します。- MTV CR を作成して設定できます。
- CR のステータスと移行の進捗を表示します。
Migration Controller
サービスは移行のオーケストレーションを行います。移行計画の作成時に、
Migration Controller
サービスは計画を検証し、ステータスラベルを追加します。計画の検証に失敗した場合には、計画のステータスはNot ready
となり、その計画を使用して移行を行うことができません。計画が検証をパスすると、計画のステータスはReady
となり、移行を実行するために使用することができます。移行に成功すると、Migration Controller
サービスは計画のステータスをCompleted
に変更します。-
Kubevirt Controller
およびContainerized Data Import (CDI) Controller
サービスは、ほとんどの技術操作を処理します。
9.3.2. 移行ワークフローの概要
ワークフローの概要では、ユーザーの観点から移行プロセスを示しています。
- ソースプロバイダー、ターゲットプロバイダー、ネットワークマッピング、およびストレージマッピングを作成します。
以下のリソースを含む
Plan
カスタムリソース (CR) を作成します。- ソースプロバイダー
- ターゲットプロバイダー (MTV がターゲットクラスターにインストールされていない場合)
- ネットワークマッピング
- ストレージマッピング
- 1 つ以上の仮想マシン (VM)
Plan
CR を参照するMigration
CR を作成して移行計画を実行します。何らかの理由ですべての VM 移行できない場合は、すべての VM が移行されるまで、同じ
Plan
CR に対して複数のMigration
CR を作成できます。Plan
CR の各 VM について、Migration Controller
サービスはVirtualMachine
CR を作成し、Migration
CR に VR の移行の進捗を記録します。すべての VM が移行されると、
Migration Controller
サービスはPlan
CR のステータスをCompleted
に更新します。各ソース VM の電源状態は、移行後も維持されます。
9.3.3. 移行ワークフローの詳細
詳細な移行ワークフローを使用して、失敗した移行のトラブルシューティングを行うことができます。
ワークフローでは、以下の手順について説明します。
Migration
カスタムリソース (CR) を作成して移行計画を実行すると、Migration Controller
サービスはソース仮想マシン (VM) ごとにVirtualMachine
CR を、ソース VM ディスクごとにDataVolume
CR を作成します。各仮想マシンディスクで以下を実行します。
-
Containerized Data Importer (CDI) Controller
サービスは、DataVolume
CR で指定されるパラメーターに基づいて永続ボリューム要求 (PVC) を作成します。 -
StorageClass
に動的プロビジョナーがある場合、永続ボリューム (PV) はStorageClass
プロビジョナーによって動的にプロビジョニングされます。 -
CDI Controller
サービスはImporter
Pod を作成します。 Importer
Pod は VM ディスクを PV にストリーミングします。仮想マシンディスクの転送後に、以下を実行します。
Migration Controller
サービスは、PVC が割り当てられたconversion
Pod を作成します。Conversion
Pod はvirt-v2v
を実行して、ターゲット VM の PVC にデバイスドライバーをインストールし、設定します。ターゲット VM の電源がオンになると、
KubeVirt Controller
サービスはvirt-launcher
Pod およびVirtualMachineInstance
CR を作成します。virt-launcher
Pod は、VM ディスクとして割り当てられた PVC でQEMU-KVM
を実行します。
9.4. ログとカスタムリソース
トラブルシューティングのためにログおよびカスタムリソース (CR) の情報をダウンロードできます。詳細は、詳細な移行ワークフロー を参照してください。
9.4.1. 収集されるログおよびカスタムリソース情報
MTV Web コンソールまたはコマンドラインインターフェイス (CLI) を使用して、以下のターゲットのログおよびカスタムリソース (CR) yaml
ファイルをダウンロードできます。
- 移行計画: Web コンソールまたは CLI。
- 仮想マシン: Web コンソールまたは CLI。
- namespace: CLI のみ。
must-gather
ツールは、以下のログおよび CR ファイルをアーカイブファイルで収集します。
CR:
-
DataVolume
CR: 移行された VM にマウントされているディスクを表します。 -
VirtualMachine
CR: 移行された VM を表します。 -
Plan
CR: VM およびストレージおよびネットワークマッピングを定義します。 -
Job
CR: オプション: 移行前のフック、移行後のフック、またはその両方を表します。
-
ログ:
-
Importer
Pod: ディスクからデータへのボリューム変換ログ。Importer
Pod の命名規則はimporter-<migration_plan>-<vm_id><5_char_id>
です。たとえば、importer-mig-plan-ed90dfc6-9a17-4a8btnfh
は、ed90dfc6-9a17-4a8
が省略された RHV VM ID、btnfh
は生成された 5 文字の ID です。 -
conversion
Pod: VM の変換ログ。conversion
Pod はvirt-v2v
を実行します。これは、VM の PVC にデバイスドライバーをインストールし、設定します。conversion
Pod の命名規則は<migration_plan>-<vm_id><5_char_id>
です。 -
virt-launcher
Pod: VM ランチャーログ。移行した VM の電源がオンになると、virt-launcher
Pod は VM ディスクとして割り当てられた PVC でQEMU-KVM
を実行します。 -
forklift-controller
Pod: ログはmust-gather
コマンドで指定される移行計画、仮想マシン、または namespace に対してフィルター処理されます。 -
forklift-must-gather-api
Pod: ログはmust-gather
コマンドで指定される移行計画、仮想マシン、または namespace に対してフィルター処理されます。 hook-job
Pod: ログはフックジョブに対してフィルターされます。hook-job
の命名規則は、<migration_plan>-<vm_id><5_char_id> (例:`plan2j-vm-3696-posthook-4mx85
またはplan2j-vm-3696-prehook-mwqnl
) です。注記空または除外されたログファイルは、
must-gather
アーカイブファイルには含まれません。
-
VMware 移行計画の must-gather アーカイブ構造の例
must-gather └── namespaces ├── target-vm-ns │ ├── crs │ │ ├── datavolume │ │ │ ├── mig-plan-vm-7595-tkhdz.yaml │ │ │ ├── mig-plan-vm-7595-5qvqp.yaml │ │ │ └── mig-plan-vm-8325-xccfw.yaml │ │ └── virtualmachine │ │ ├── test-test-rhel8-2disks2nics.yaml │ │ └── test-x2019.yaml │ └── logs │ ├── importer-mig-plan-vm-7595-tkhdz │ │ └── current.log │ ├── importer-mig-plan-vm-7595-5qvqp │ │ └── current.log │ ├── importer-mig-plan-vm-8325-xccfw │ │ └── current.log │ ├── mig-plan-vm-7595-4glzd │ │ └── current.log │ └── mig-plan-vm-8325-4zw49 │ └── current.log └── openshift-mtv ├── crs │ └── plan │ └── mig-plan-cold.yaml └── logs ├── forklift-controller-67656d574-w74md │ └── current.log └── forklift-must-gather-api-89fc7f4b6-hlwb6 └── current.log
9.4.2. Web コンソールからのログおよびカスタムリソース情報のダウンロード
MTV Web コンソールを使用して、完了、失敗、またはキャンセルされた移行計画や移行された仮想マシン (VM) のログとカスタムリソース (CR) に関する情報をダウンロードできます。
手順
- Web コンソールで、Migration plans をクリックします。
- 移行計画名の横にある Get logs をクリックします。
Get logs ウィンドウで Get logs をクリックします。
ログが収集されます。
Log collection complete
メッセージが表示されます。- Download logs をクリックしてアーカイブファイルをダウンロードします。
- 移行された VM のログをダウンロードするには、移行計画名をクリックして、VM の横にある Get logs をクリックします。
9.4.3. コマンドラインインターフェイスからのログおよびカスタムリソース情報へのアクセス
must-gather
ツールを使用して、コマンドラインインターフェイスからカスタムリソース (CR) のログおよび情報にアクセスできます。must-gather
データファイルをすべてのカスタマーケースに割り当てる必要があります。
フィルターオプションを使用して、特定の namespace、完了、失敗、またはキャンセルされた移行計画、移行した仮想マシン (VM) のデータを収集できます。
フィルターされた must-gather
コマンドで存在しないリソースを指定する場合、アーカイブファイルは作成されません。
前提条件
-
cluster-admin
ロールを持つユーザーとして OpenShift Virtualization クラスターにログインしている。 -
OpenShift Container Platform CLI (
oc
) がインストールされている。
手順
-
must-gather
データを保存するディレクトリーに移動します。 oc adm must-gather
コマンドを実行します。$ oc adm must-gather --image=registry.redhat.io/migration-toolkit-virtualization/mtv-must-gather-rhel8:2.3.0
データは
/must-gather/must-gather.tar.gz
として保存されます。このファイルを Red Hat カスタマーポータル で作成したサポートケースにアップロードすることができます。オプション:
oc adm must-gather
コマンドに以下のオプションを指定して実行し、フィルターされたデータを収集します。Namespace:
$ oc adm must-gather --image=registry.redhat.io/migration-toolkit-virtualization/mtv-must-gather-rhel8:2.3.0 \ -- NS=<namespace> /usr/bin/targeted
移行計画:
$ oc adm must-gather --image=registry.redhat.io/migration-toolkit-virtualization/mtv-must-gather-rhel8:2.3.0 \ -- PLAN=<migration_plan> /usr/bin/targeted
仮想マシン:
$ oc adm must-gather --image=registry.redhat.io/migration-toolkit-virtualization/mtv-must-gather-rhel8:2.3.0 \ -- VM=<vm_name> NS=<namespace> /usr/bin/targeted 1
- 1
- VM ID ではなく、
Plan
CR に表示される VM の名前を指定する必要があります。