12.4. コマンドラインインターフェイスを使用した仮想マシンの移行

前提条件

• ハイパーバイザー： 移行元ホストと移行先ホストはいずれも KVM ハイパーバイザーを使用します。
• ネットワーク接続： 移行元ホストと移行先ホストは、ネットワーク経由で相互に通信できます。ping ユーティリティーを使用してこれを確認します。

• オープンポート： 移行先ホストで次のポートが開いていることを確認します。

  • ポート 22 は、SSH を使用して宛先ホストに接続するために必要です。
  • ポート 16509 は、TLS を使用して宛先ホストに接続するために必要です。
  • ポート 16514 は、TCP を使用して宛先ホストに接続するために必要です。
  • ポート 49152 - 49215 は、QEMU がメモリーおよびディスク移行データを転送するために必要です。
• Hosts: Red Hat が移行に対応できるようにするには、移行元ホストと移行先ホストが特定のオペレーティングシステムおよびマシンタイプを使用している必要があります。これを確認するには、Supported hosts for virtual machine migration を参照してください。
• CPU: VM は移行先ホストの CPU 機能と互換性がある必要があります。これを確認するには、仮想マシン移行のホスト CPU の互換性の確認 を参照してください。

• ストレージ： 移行される仮想マシンのディスクイメージは、移行元ホストと移行先ホストの両方からアクセスできます。オフラインマイグレーションの場合は任意ですが、実行中の仮想マシンの移行に必要になります。両方のホストのストレージアクセスを確保するには、次のいずれかに該当している必要があります。

  • ストレージエリアネットワーク (SAN) 論理ユニット (LUN) を使用している。
  • Ceph Storage クラスター を使用している。
  • ソース仮想マシン ディスクと同じ形式およびサイズのディスクイメージを作成 し、仮想マシンの移行時に the -copy-storage-all パラメーターを使用します。
  • ディスクイメージが別のネットワーク上の場所にある。このような仮想マシンの共有ストレージを設定する手順は、Sharing virtual machine disk images with other hosts を参照してください。

• ネットワーク帯域幅： 実行中の仮想マシンを移行する場合は、ネットワークの帯域幅が、仮想マシンがダーティーメモリーページを生成する速度よりも大きくなければなりません。

  ライブマイグレーションを開始する前に仮想マシンのダーティーページ速度を取得するには、次の手順を実行します。

  • 短期間、仮想マシンのダーティーページ生成速度を監視します。

    # virsh domdirtyrate-calc <example_VM> 30

  • 監視が終了したら、結果を取得します。

    # virsh domstats <example_VM> --dirtyrate
    Domain: 'example-VM'
      dirtyrate.calc_status=2
      dirtyrate.calc_start_time=200942
      dirtyrate.calc_period=30
      dirtyrate.megabytes_per_second=2

    この例では、仮想マシンが 1 秒あたり 2MB のダーティーメモリーページを生成しています。帯域幅が 2MB/s 以下のネットワーク上でこのような仮想マシンをライブマイグレーションしようとすると、仮想マシンを一時停止したり、ワークロードを低くしたりしないと、ライブマイグレーションが進行しません。

    ライブマイグレーションが正常に終了するように、Red Hat では、ネットワークの帯域幅が仮想マシンのダーティーページの生成速度を大幅に上回ることを推奨しています。

    注記

    calc_period オプションの値は、ワークロードとダーティーページ速度により異なる場合があります。いくつかの calc_period 値を試して、環境のダーティーページ速度に合わせた最適な期間を決定できます。

• ブリッジタップネットワークの詳細：パブリックブリッジタップネットワーク内の既存の仮想マシンを移行する場合は、移行元ホストと移行先ホストが同じネットワークに存在する必要があり ます。そうでない場合は、移行後に仮想マシンのネットワークが機能しなくなります。

• 接続プロトコル： 仮想マシンの移行の実行時に、ソースホストの virsh クライアントは、複数のプロトコルの 1 つを使用して、移行先ホストの libvirt デーモンに接続できます。次の手順の例では SSH 接続を使用していますが、別の接続を選択することもできます。

  • libvirt で SSH 接続を使用する場合は、virtqemud ソケットが有効になっていて、宛先ホストで実行されていることを確認してください。

    # systemctl enable --now virtqemud.socket

  • libvirt で TLS 接続を使用する場合は、virtproxyd-tls ソケットが有効になっていて、宛先ホストで実行していることを確認してください。

    # systemctl enable --now virtproxyd-tls.socket

  • libvirt で TCP 接続を使用する場合は、virtproxyd-tcp ソケットが有効になっていて、宛先ホストで実行していることを確認してください。

    # systemctl enable --now virtproxyd-tcp.socket

オフラインマイグレーション

• 以下のコマンドは、SSH トンネルを使用して、シャットダウンオフの example-VM 仮想マシンをローカルホストから example-destination ホストのシステム接続に移行します。

  # virsh migrate --offline --persistent <example_VM> qemu+ssh://example-destination/system

マルチ FD ライブマイグレーション

• ライブマイグレーション中に、移行先ホストへの複数の並列接続を使用できます。これは、複数のファイル記述子（マルチ FD）の移行としても知られています。マルチ FD 移行では、移行プロセスに利用可能なネットワーク帯域幅をすべて利用することで、移行を高速化できます。

  # virsh migrate --live --persistent --parallel --parallel-connections 4 <example_VM> qemu+ssh://<example-destination>/system

  この例では、4 つのマルチ FD チャネルを使用して仮想マシンを <example_VM> 移行します。利用可能なネットワーク帯域幅 10 Gbps ごとに 1 つのチャネルを使用することを推奨します。デフォルト値は 2 チャネルです。

ダウンタイム制限を引き上げたライブマイグレーション

• ライブマイグレーションの信頼性を向上させるために、maxdowntime パラメーターを設定できます。このパラメーターは、ライブマイグレーション中に仮想マシンを一時停止できる最大時間（ミリ秒単位）を指定します。ダウンタイムを大きくすると、移行を正常に完了させることができます。

  # virsh migrate-setmaxdowntime <example_VM> <time_interval_in_milliseconds>

Post-copy migration

• 仮想マシンのメモリーフットプリントが大きい場合は、コピー後 の移行を実行できます。これにより、ソース仮想マシンの CPU 状態が最初に転送され、移行先ホストで移行した仮想マシンがすぐに起動します。ソース仮想マシンのメモリーページは、移行した仮想マシンが移行先ホストですでに実行された後に転送されます。このため、コピー後の移行により、移行した仮想マシンのダウンタイム が短縮される可能性があります。

  ただし、移行先ホストで実行中の仮想マシンがまだ転送されていないメモリーページにアクセスしようとする場合があり、これにより ページフォールト が発生します。移行中に ページフォールト が多すぎると、移行した仮想マシンのパフォーマンスが大幅に低下する可能性があります。

  コピー後 の移行が複雑になる可能性がある場合には、以下のコマンドを使用して、標準的なライブマイグレーションを開始し、指定した時間内にライブマイグレーションを完了できない場合は、コピー後 の移行に切り替えます。

  # virsh migrate --live --persistent --postcopy --timeout <time_interval_in_seconds> --timeout-postcopy <example_VM> qemu+ssh://<example-destination>/system

自動コンバージションのライブマイグレーション

• VM がメモリーの負荷が高い場合は、--auto-converge オプションを使用できます。このオプションでは、仮想マシンの CPU の実行速度が自動的に低下します。その結果、この CPU スロットリングはメモリー書き込みの速度を低下させる可能性があります。つまり、メモリーワークロードが多い仮想マシンでもライブマイグレーションが成功する可能性があります。

  ただし、CPU スロットリングは、メモリー書き込みが CPU の実行速度と直接関係のないワークロードの解決には役立ちず、ライブマイグレーション中の仮想マシンのパフォーマンスに悪影響を及ぼす可能性があります。

  # virsh migrate --live --persistent --auto-converge <example_VM> qemu+ssh://<example-destination>/system

検証

• オフライン 移行の場合：

  • 移行先ホストで、使用可能な仮想マシンを一覧表示し、仮想マシンが正常に移行されたことを確認します。

    # virsh list --all
    Id      Name             State
    ----------------------------------
    10    example-VM-1      shut off

• ライブマイグレーション の場合：

  • 移行先ホストで、使用可能な仮想マシンを一覧表示し、移行先仮想マシンの状態を確認します。

    # virsh list --all
    Id      Name             State
    ----------------------------------
    10    example-VM-1      running

    仮想マシンの状態が running と表示されている場合は、移行が完了したことを意味します。ただし、ライブマイグレーションが進行中の場合は、移行先仮想マシンの状態が 一時停止 として表示されます。

• post-copy の移行の場合：

  1. ソースホストで、利用可能な仮想マシンを一覧表示し、ソース仮想マシンの状態を確認します。

     # virsh list --all
     Id      Name             State
     ----------------------------------
     10    example-VM-1      shut off

  2. 移行先ホストで、使用可能な仮想マシンを一覧表示し、移行先仮想マシンの状態を確認します。

     # virsh list --all
     Id      Name             State
     ----------------------------------
     10    example-VM-1      running

     移行元仮想マシンの状態が 停止 と表示され、移行先仮想マシンの状態が running と表示されている場合は、移行が完了したことを意味します。