10.3. アーキテクチャー


このセクションでは、MTV カスタムリソース、サービス、およびワークフローを説明します。

10.3.1. MTV カスタムリソースおよびサービス

Migration Toolkit for Virtualization (MTV) は、Red Hat OpenShift Operator として提供されます。以下のカスタムリソース (CR) およびサービスを作成し、管理します。

MTV カスタムリソース

  • Provider CR は、MTV がソースおよびターゲットプロバイダーに接続し、対話できるようにする属性を保存します。
  • NetworkMapping CR は、ソースおよびターゲットプロバイダーのネットワークをマッピングします。
  • StorageMapping CR は、ソースおよびターゲットプロバイダーのストレージをマッピングします。
  • Plan CR には、同じ移行パラメーターと関連するネットワークおよびストレージマッピングを持つ仮想マシンのリストが含まれます。
  • Migration CR は移行計画を実行します。

    一度に実行できる Migration CR は、移行計画ごとに 1 つのみです。単一の Plan CR に複数の Migration CR を作成できます。

MTV サービス

  • Inventory サービスは以下のアクションを実行します。

    • 移行元プロバイダーおよびターゲットプロバイダーに接続します。
    • マッピングおよび計画に関するローカルインベントリーを維持します。
    • 仮想マシンの設定を保存します。
    • 仮想マシンの設定の変更が検出されたら、Validation サービスを実行します。
  • Validation サービスは、ルールを適用して移行の適合性を確認します。
  • Migration Controller サービスは移行のオーケストレーションを行います。

    移行計画の作成時に、Migration Controller サービスは計画を検証し、ステータスラベルを追加します。計画の検証に失敗した場合には、計画のステータスは Not ready となり、その計画を使用して移行を行うことができません。計画が検証をパスすると、計画のステータスは Ready となり、移行を実行するために使用できます。移行に成功すると、Migration Controller サービスは計画のステータスを Completed に変更します。

  • Populator Controller サービスは、Volume Populator を使用して、ディスク転送を調整します。
  • Kubevirt Controller および Containerized Data Import (CDI) Controller サービスは、ほとんどの技術操作を処理します。

10.3.2. 移行ワークフローの概要

ワークフローの概要では、ユーザーの観点から移行プロセスを示しています。

  1. 移行元プロバイダー、ターゲットプロバイダー、ネットワークマッピング、およびストレージマッピングを作成します。
  2. 以下のリソースを含む Plan カスタムリソース (CR) を作成します。

    • 移行元プロバイダー
    • ターゲットプロバイダー (MTV がターゲットクラスターにインストールされていない場合)
    • ネットワークマッピング
    • ストレージマッピング
    • 1 つ以上の仮想マシン (VM)
  3. Plan CR を参照する Migration CR を作成して移行計画を実行します。

    何らかの理由ですべての仮想マシン移行できない場合は、すべての仮想マシンが移行されるまで、同じ Plan CR に対して複数の Migration CR を作成できます。

  4. Plan CR の仮想マシンごとに、Migration Controller サービスは仮想マシン移行の進行状況を Migration CR に記録します。
  5. Plan CR 内の各仮想マシンのデータ転送が完了すると、Migration Controller サービスによって VirtualMachine CR が作成されます。

    すべての仮想マシンが移行されると、Migration Controller サービスは Plan CR のステータスを Completed に更新します。各ソース仮想マシンの電源状態は、移行後も維持されます。

10.3.3. 移行ワークフローの詳細

詳細な移行ワークフローを使用して、失敗した移行のトラブルシューティングを行うことができます。

ワークフローでは、以下の手順を説明します。

ウォームマイグレーションまたはリモート OpenShift クラスターへの移行:

  1. Migration カスタムリソース (CR) を作成して、移行計画を実行すると、Migration Controller サービスはソース仮想マシンディスクごとに DataVolume CR を作成します。

    各仮想マシンディスクで以下を実行します。

  2. Containerized Data Importer (CDI) Controller サービスは、DataVolume CR で指定されるパラメーターに基づいて永続ボリューム要求 (PVC) を作成します。


  3. StorageClass に動的プロビジョナーがある場合、永続ボリューム (PV) は StorageClass プロビジョナーによって動的にプロビジョニングされます。
  4. CDI Controller サービスは Importer Pod を作成します。
  5. Importer Pod は仮想マシンディスクを PV にストリーミングします。

    仮想マシンディスクの転送後に、以下を実行します。

  6. Migration Controller サービスは、VMWare からのインポート時に、PVC が接続された conversion Pod を作成します。

    conversion Pod は virt-v2v を実行して、ターゲット仮想マシンの PVC にデバイスドライバーをインストールし、設定します。

  7. Migration Controller サービスは、PVC に接続されたソース仮想マシン (VM) ごとに VirtualMachine CR を作成します。
  8. 仮想マシンがソース環境で実行されている場合は、Migration Controller が仮想マシンの電源を入れ、KubeVirt Controller サービスが virt-launcher Pod と VirtualMachineInstance CR を作成します。

    virt-launcher Pod は、仮想マシンディスクとして割り当てられた PVC で QEMU-KVM を実行します。

RHV または OpenStack からローカル OpenShift クラスターへのコールド移行:

  1. Migration カスタムリソース (CR) を作成して、移行計画を実行すると、Migration Controller サービスはソース仮想マシンディスクごとに PersistentVolumeClaim CR を作成し、ソースが RHV の場合は OvirtVolumePopulator を作成し、ソースが OpenStack の場合は OpenstackVolumePopulator CR を作成します。

    各仮想マシンディスクで以下を実行します。

  2. Populator Controller サービスは一時的な永続ボリューム要求 (PVC) を作成します。
  3. StorageClass に動的プロビジョナーがある場合、永続ボリューム (PV) は StorageClass プロビジョナーによって動的にプロビジョニングされます。

    • Migration Controller サービスは、ダミー Pod を作成して、すべての PVC をバインドします。Pod の名前には pvcinit が含まれます。
  4. Populator Controller サービスは、populator Pod を作成します。
  5. populator Pod は、ディスクデータを PV に転送します。

    仮想マシンディスクの転送後に、以下を実行します。

  6. 一時的な PVC は削除され、最初の PVC はデータを含む PV を指します。
  7. Migration Controller サービスは、PVC に接続されたソース仮想マシン (VM) ごとに VirtualMachine CR を作成します。
  8. 仮想マシンがソース環境で実行されている場合は、Migration Controller が仮想マシンの電源を入れ、KubeVirt Controller サービスが virt-launcher Pod と VirtualMachineInstance CR を作成します。

    virt-launcher Pod は、仮想マシンディスクとして割り当てられた PVC で QEMU-KVM を実行します。

VMWare からローカル OpenShift クラスターへのコールドマイグレーション:

  1. Migration カスタムリソース (CR) を作成して、移行計画を実行すると、Migration Controller サービスはソース仮想マシンディスクごとに DataVolume CR を作成します。

    各仮想マシンディスクで以下を実行します。

  2. Containerized Data Importer (CDI) Controller サービスは、DataVolume CR に指定されたパラメーターに基づいて、空の永続ボリューム要求 (PVC) を作成します。


  3. StorageClass に動的プロビジョナーがある場合、永続ボリューム (PV) は StorageClass プロビジョナーによって動的にプロビジョニングされます。

すべての仮想マシンディスクの場合:

  1. Migration Controller サービスは、ダミー Pod を作成して、すべての PVC をバインドします。Pod の名前には pvcinit が含まれます。
  2. Migration Controller サービスは、すべての PVC の conversion Pod を作成します。
  3. conversion Pod は virt-v2v を実行します。これにより、仮想マシンが KVM ハイパーバイザーに変換され、ディスクのデータが対応する PV に転送されます。

    仮想マシンディスクの転送後に、以下を実行します。

  4. Migration Controller サービスは、PVC に接続されたソース仮想マシン (VM) ごとに VirtualMachine CR を作成します。
  5. 仮想マシンがソース環境で実行されている場合は、Migration Controller が仮想マシンの電源を入れ、KubeVirt Controller サービスが virt-launcher Pod と VirtualMachineInstance CR を作成します。

    virt-launcher Pod は、仮想マシンディスクとして割り当てられた PVC で QEMU-KVM を実行します。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat, Inc.