第8章 コンピュートノード間の仮想マシンの移行

特定の状況では、仮想マシンをオーバークラウド上のあるコンピュートノードから別のコンピュートノードに移行しなければならない場合があります。以下に例を示します。

  • コンピュートノードのメンテナンス: コンピュートノードを一時的に停止しなければならない場合には、コンピュートノード上で実行中の仮想マシンを別のコンピュートノードに一時的に移行することができます。一般的なシナリオとしては、ハードウェアのメンテナンス、ハードウェアの修理、カーネルのアップグレード、およびソフトウェアの更新などが挙げられます。
  • コンピュートノードの障害: コンピュートノードで障害の発生が予想され、保守または置き換えが必要な場合には、仮想マシンを障害のあるコンピュートノードから正常なコンピュートノードに移行する必要があります。すでに障害が発生しているコンピュートノードについては、『インスタンス&イメージガイド』の「インスタンスの退避」を参照してください。
  • 負荷の再分散: 負荷を再度分散するために、1 つまたは複数の仮想マシンを別のコンピュートノードに移行することを検討できます。たとえば、コンピュートノード上の仮想マシンを 1 つにまとめて電力を節約する、ネットワーク上のリソースに物理的に近いコンピュートノードに仮想マシンを移行してレイテンシーを低減する、全コンピュートノードに仮想マシンを分散してホットスポットをなくし復元力を向上させる、等が可能です。

director は、すべての コンピュートノードがセキュアな移行を提供するように設定します。全コンピュートノードには、各ホストの nova ユーザーが移行プロセス中に他のコンピュートノードにアクセスすることができるようにするための共有 SSH キーも必要です。director は、OS::TripleO::Services::NovaCompute コンポーザブルサービスを使用してこのキーを作成します。このコンポーザブルサービスは、全 Compute ロールにデフォルトで含まれているメインのサービスの 1 つです (『オーバークラウドの高度なカスタマイズ』「コンポーザブルサービスとカスタムロール」を参照)。

移行機能に対するアップデート

Red Hat OpenStack Platform 10 の最新アップデートには、ライブマイグレーション機能に必要な OS::TripleO::Services::Sshd コンポーザブルサービスが含まれています。初期リリースの director のコアテンプレートコレクションには、このサービスは含まれませんでしたが、openstack-tripleo-heat-templates-5.2.0-12 パッケージおよびそれ以降のバージョンに含まれるようになりました。

  • デフォルトのロールを使用している場合は、openstack-tripleo-heat-templates-5.2.0-12 パッケージまたはそれ以降のバージョンからの Heat テンプレートを使用するように環境を更新してください。
  • カスタムロールデータファイルを使用している場合は、openstack-tripleo-heat-templates-5.2.0-12 パッケージまたはそれ以降のバージョンからの Heat テンプレートを使用するように環境を更新し、それぞれのオーバークラウドロールに OS::TripleO::Services::Sshd サービスを含め、続いて新しいサービスが含まれるようにオーバークラウドスタックを更新してください。

詳しくは、「Red Hat OpenStack Platform director (TripleO) CVE-2017-2637 bug and Red Hat OpenStack Platform」を参照してください。

重要

2018 年 2 月 27 日付けの RHSA-2018:0369: セキュリティーアドバイザリー および 2019 年 1 月 16 日付けの RHBA-2019:0074: バグ修正アドバイザリー は、仮想マシンの移行に影響します。

RHSA-2018:0369: セキュリティーアドバイザリー は、ドメイン XML で定義された CPU がすでに使用されているコンピュートノードへの仮想マシンのライブマイグレーションを妨ぎます。RHSA-2018:0369: セキュリティーアドバイザリー は、コールドマイグレーション、退避、サイズ変更、および復元などの操作に同じ制約を不必要に適用します。RHBA-2019:0074: バグ修正アドバイザリー は、これらをオプションにして制約を緩和します。詳細は、このアドバイザリーで導入された新たな cpu_pinning_migration_quick_fail 設定オプションを参照してください。

Red Hat では、両方のアドバイザリーを適用することを推奨します。

移行の制約についてのより詳しい情報は、「移行の制約」を参照してください。

8.1. 移行の種別

OpenStack Platform では、以下の 2 つの移行種別がサポートされます。

ライブマイグレーション

ライブマイグレーションでは、移行先ノードの仮想マシンを起動して移行元ノードの仮想マシンをシャットダウンする操作を、仮想マシンの動作状態を維持しながらシームレスに実施します。

Live Migration

ライブマイグレーションでは、ほぼゼロダウンタイムで仮想マシンの移行が行われます。状況によっては、仮想マシンがライブマイグレーションを使用 できない 場合があります。移行の制約に関する詳細は、「移行の制約」を参照してください。

コールドマイグレーション

コールドマイグレーション (あるいは、非ライブマイグレーション) では、移行元コンピュートノードから移行先コンピュートノードに仮想マシンを移行する前に、nova が仮想マシンをシャットダウンします。

Cold Migration

コールドマイグレーションでは、仮想マシンに多少のダウンタイムが発生します。ただし、コールドマイグレーションにより移行した仮想マシンは、引き続き同じボリュームおよび IP アドレスにアクセスすることができます。

重要

移行元コンピュートノードですでに障害が発生している場合には、『インスタンス&イメージガイド』の「インスタンスの退避」を参照してください。移行を行うためには、移行元および移行先両方のコンピュートノードが動作状態になければなりません。

8.2. 移行の制約

状況によっては、仮想マシンの移行に追加の制約が生じる場合があります。移行の制約は通常、ブロックマイグレーション、設定ディスク、またはいずれかの仮想マシンがコンピュートノード上の物理ハードウェアにアクセスする場合に生じます。

CPU に関する制約

移行元および移行先コンピュートノードの CPU アーキテクチャーは、同一であることが 必須です。たとえば、Red Hat では、x86_64 CPU から ppc64le CPU への仮想マシンの移行を サポートしません。CPU ホストパススルーを使用する仮想マシン等の場合には、移行元および移行先コンピュートノードの CPU は、完全に同一である 必要があります。すべてのケースで、移行先ノードの CPU 機能は、移行元ノードの CPU 機能の上位セットであることが 必須 です。また、仮想マシンで CPU ピニングが使用されている場合、移行元ノード上で使用されている NUMA ノードが移行先コンピュートノードの同じ NUMA ノードをターゲットにし、NUMA ノードが空である必要があります。

メモリーに関する制約

移行先コンピュートノードは、利用可能な RAM を十分に持つことが 求められます。メモリーのオーバーサブスクリプションが、移行失敗の原因となる 可能性があります。また、NUMA トポロジーを使用する仮想マシンの場合、移行先コンピュートノードの同じ NUMA ノードで十分な RAM が利用可能でなければなりません。

ブロックマイグレーションに関する制約

仮想マシンの使用するディスクがコンピュートノード上にローカルに格納されている場合、その移行には、共有ストレージ (Red Hat Ceph Storage 等) を使用するボリュームベースの仮想マシンよりもはるかに長い時間がかかります。このレイテンシーは、nova がコンピュートノード間でローカルディスクをブロックごとに移行するために発生します。この処理は、デフォルトではコントロールプレーンネットワークを通じて行われます。これとは対照的に、Red Hat Ceph Storage 等の共有ストレージを使用するボリュームベースのインスタンスでは、ボリュームを移行する必要がありません。それぞれのコンピュートノードが、共有ストレージにアクセスできるためです。

注記

大量の RAM を消費するローカルディスクまたは仮想マシンの移行により、コントロールプレーンネットワークに輻輳が生じ、これによりコントロールプレーンネットワークを使用する他のシステム (RabbitMQ 等) のパフォーマンスに悪影響を及ぼす場合があります。

読み取り専用ドライブの移行に関する制約

ドライブの移行は、ドライブに読み取り および 書き込み両方の機能がある場合に 限り サポートされます。たとえば、nova は CD-ROM ドライブまたは読み取り専用のコンフィグドライブを移行することはできません。ただし、nova は、vfat 等のドライブ形式を持つコンフィグドライブなど、読み取りおよび書き込み 両方の 機能を持つドライブを移行することができます。

ライブマイグレーションに関する制約

Red Hat OpenStack Platform では、ライブマイグレーションに関して、さらにいくつかの制約があります。

  • 移行中は新規操作ができない: 移行元および移行先ノードの仮想マシンのコピー間で状態の整合性を確保するために、Red Hat OpenStack Platform ではライブマイグレーション中の新規操作を拒否する必要があります。拒否しないと、ライブマイグレーションでメモリーの状態を複製する前にメモリーへの書き込みが行われた場合、ライブマイグレーションに長い時間がかかる状況や、永久に完了しない状況が発生する可能性があります。
  • Non-Uniform Memory Access (NUMA): 以前のリリースでは、NUMA トポロジーが設定された仮想マシンの移行は推奨されませんでした。現在、いくつかの制約はあるものの、nova は NUMA トポロジーが設定された仮想マシンを適切に移行することができます。
  • CPU ピニング: フレーバーで CPU ピニングが使用される場合、フレーバーは暗黙的に NUMA トポロジーを仮想マシンに適用し、その CPU およびメモリーを特定のホスト CPU およびメモリーにマッピングします。シンプルな NUMA トポロジーと CPU ピニングの違いは、NUMA では CPU コアの 範囲 が指定されるのに対して、CPU ピニングでは特定の CPU コアが使用される点です。詳細は、「NUMA ノードを使用する CPU ピニングの設定」を参照してください。
  • Data Plane Development Kit (DPDK): 仮想マシンが DPDK を使用する場合 (Open vSwitch と dpdk-netdev を組み合わせて実行する仮想マシンなど)、仮想マシンはヒュージページも使用し、nova が仮想マシンを NUMA ノードに固定するような NUMA トポロジーが適用されます。

nova では、NUMA、CPU ピニング、または DPDK を使用する仮想マシンのライブマイグレーションが可能です。ただし、移行先コンピュートノードには、仮想マシンが移行元コンピュートノードで使用するのと同じ NUMA ノード十分な容量がなければなりません。たとえば、仮想マシンが overcloud-compute-0NUMA 0 を使用している場合、仮想マシンを overcloud-compute-1 にライブマイグレーションするには、overcloud-compute-1NUMA 0 に仮想マシンをサポートするのに十分な容量を確保する必要があります。

ライブマイグレーションの妨げとなる制約

Red Hat OpenStack Platform では、仮想マシンの設定によりライブマイグレーションが妨げられるケースがいくつかあります。

  • Single-root Input/Output Virtualization (SR-IOV): 仮想マシンに SR-IOV Virtual Function (VF) を割り当てることができます。ただし、これによりライブマイグレーションが妨げられます。通常のネットワークデバイスとは異なり、SR-IOV VF ネットワークデバイスは、永続的な一意の MAC アドレスを持ちません。コンピュートノードがリブートするたびに、または nova-scheduler が仮想マシンを新しいコンピュートノードに移行する際に、VF ネットワークデバイスには新しい MAC アドレスが割り当てられます。したがって、OpenStack Platform 10 では、nova は SR-IOV を使用する仮想マシンのライブマイグレーションを行うことができません。SR-IOV を使用する仮想マシンでは、コールドマイグレーションを行う必要があります。
  • PCI パススルー: QEMU/KVM ハイパーバイザーでは、コンピュートノード上の PCI デバイスを仮想マシンにアタッチすることができます。PCI パススルーを使用すると、仮想マシンは PCI デバイスに排他的にアクセスすることができ、これらのデバイスが仮想マシンのオペレーティングシステムに物理的に接続されているかのように表示され、動作します。ただし、PCI パススルーには物理アドレスが必要なため、OpenStack Platform 10 では、nova は PCI パススルーを使用する仮想マシンのライブマイグレーションをサポートしません。

8.3. 移行前の操作

1 つまたは複数の仮想マシンを移行する前に、以下の手順を実施します。

手順

  1. アンダークラウドから、移行元コンピュートノードのホスト名および移行先コンピュートノードのホスト名を特定します。

    $ source ~/overcloudrc
    $ openstack compute service list
  2. 移行元コンピュートノード上の仮想マシンを一覧表示し、移行する仮想マシンの ID を探します。

    $ openstack server list --host [source] --all-projects

    [source] を移行元コンピュートノードのホスト名に置き換えてください。

コンピュートノードをメンテナンスするための移行前の操作

メンテナンスのために移行元となるコンピュートノードを停止する場合には、メンテナンス中にスケジューラーが新しい仮想マシンを割り当てないように、アンダークラウドからそのコンピュートノードを無効にします。

$ openstack compute service set [source] nova-compute --disable

[source] を移行元コンピュートノードのホスト名に置き換えてください。

NUMA、CPU ピニング、および DPDK インスタンスの移行前の操作

NUMA、CPU ピニング、または DPDK を使用する仮想マシンを移行する場合、移行先コンピュートノードのハードウェア仕様と設定は、移行元コンピュートノードと同一でなければなりません。また、移行元コンピュートノードの NUMA トポロジーを確保するために、移行先コンピュートノードに実行中の仮想マシンがあってはいけません。

注記

NUMA、CPU ピニング、または DPDK を使用する仮想マシンを移行する場合、/etc/nova/nova.conf ファイルの scheduler_default_filters 設定には、AggregateInstanceExtraSpecFilter および NUMATopologyFilter 等の適切な値を設定する必要があります。そのためには、環境ファイルの NovaSchedulerDefaultFilters heat パラメーターを設定します。

  1. NUMA、CPU ピニング、または DPDK 仮想マシンの移行先コンピュートノードが無効ではない場合には、これを無効にしてスケジューラーがそのノードに仮想マシンを割り当てるのを防ぎます。

    $ openstack compute service set [dest] nova-compute --disable

    [dest] を移行先コンピュートノードのホスト名に置き換えてください。

  2. 複数の DPDK または NUMA 仮想マシンを移行する場合に移行元コンピュートノードから先に移行していた仮想マシンを除き、移行先コンピュートノードには仮想マシンが存在しないようにしてください。

    $ openstack server list --host [dest] --all-projects

    [dest] を移行先コンピュートノードのホスト名に置き換えてください。

  3. 移行先コンピュートノードに、NUMA、CPU ピニング、または DPDK 仮想マシンを実行するのに十分なリソースを確保するようにしてください。

    $ openstack host show overcloud-compute-n
    $ ssh overcloud-compute-n
    $ numactl --hardware
    $ exit

    overcloud-compute-n を移行先コンピュートノードのホスト名に置き換えてください。

  4. 移行元または移行先コンピュートノードの NUMA 情報を検出するには、必要に応じて以下のコマンドを実行します。

    $ ssh root@overcloud-compute-n
    # lscpu && lscpu | grep NUMA
    # virsh nodeinfo
    # virsh capabilities
    # exit

    ssh を使用して、overcloud-compute-n に接続します。ここで、overcloud-compute-n は移行元または移行先コンピュートノードです。

  5. 仮想マシンが NUMA を使用しているかどうか不明な場合は、仮想マシンのフレーバーを確認してください。

    $ openstack server list -c Name -c Flavor --name [vm]

    [vm] を仮想マシンの名前または ID に置き換えてください。

    続いてフレーバーを確認します。

    $ openstack flavor show [flavor]

    [flavor] をフレーバーの名前または ID に置き換えてください。表示される properties フィールドの hw:mem_page_size の値が any 以外 (2MB2048、または 1GB) の場合、仮想マシンは NUMA トポロジーを持ちます。properties フィールドに aggregate_instance_extra_specs:pinned='true' が含まれる場合、仮想マシンは CPU ピニングを使用しています。properties フィールドに hw:numa_nodes が含まれる場合、nova は仮想マシンを特定の NUMA ノードに制限します。

  6. NUMA を使用する各仮想マシンについて、移行完了後に移行先コンピュートノードの NUMA トポロジーが移行元コンピュートノードの NUMA トポロジーを反映していることを確認できるように、ベースとなるコンピュートノードから NUMA トポロジーに関する情報を取得することを検討してください。

    $ ssh root@overcloud-compute-n
    # virsh vcpuinfo [vm]
    # virsh numatune [vm]
    # exit

    [vm] を仮想マシンの名前に置き換えてください。vcpuinfo コマンドにより、NUMA および CPU ピニングに関する詳細が表示されます。numatune コマンドにより、仮想マシンが使用している NUMA ノードが表示されます。

8.4. 仮想マシンのライブマイグレーション

ライブマイグレーションでは、ダウンタイムを最小限に抑えて、仮想マシンを移行元コンピュートノードから移行先コンピュートノードに移動します。ただし、ライブマイグレーションがすべての仮想マシンに適しているとは限りません。補足情報は、「移行の制約」を参照してください。

手順

  1. 仮想マシンのライブマイグレーションを行うには、仮想マシンおよび移行先コンピュートノードを指定します。

    $ openstack server migrate [vm] --live [dest] --wait

    [vm] を仮想マシンの名前または ID に置き換えてください。[dest] を移行先コンピュートノードのホスト名に置き換えてください。ローカルに確保されたボリュームを移行する場合には、--block-migration フラグを指定します。

  2. 移行が完了するまで待ちます。移行のステータスを確認するには、「移行ステータスの確認」を参照してください。
  3. 正常に移行したことを確認します。

    $ openstack server list --host [dest] --all-projects

    [dest] を移行先コンピュートノードのホスト名に置き換えてください。

  4. NUMA、CPU ピニング、または DPDK を使用する仮想マシンについて、コンピュートノードから NUMA トポロジーに関する情報を取得して、移行前の操作中に取得した NUMA トポロジーと比較することを検討してください。

    $ ssh root@overcloud-compute-n
    # virsh vcpuinfo [vm]
    # virsh numatune [vm]
    # exit

    overcloud-compute-n をコンピュートノードのホスト名に置き換えてください。[vm] を仮想マシンの名前に置き換えてください。移行元および移行先コンピュートノードの NUMA トポロジーを比較すると、移行元および移行先コンピュートノードが同じ NUMA トポロジーを使用することを確認するのに役立ちます。

  5. 移行するその他の仮想マシンごとに、この手順を繰り返します。

仮想マシンの移行が終了したら、「移行後の操作」に進んでください。

8.5. 仮想マシンのコールドマイグレーション

仮想マシンのコールドマイグレーションでは、仮想マシンを停止して、別のコンピュートノードに移動します。コールドマイグレーションは、PCI パススルーまたは Single-Root Input/Output Virtualization (SR-IOV) を使用する仮想マシンの移行など、ライブマイグレーションでは対応することのできない移行シナリオに対応します。移行先コンピュートノードは、スケジューラーにより自動的に選択されます。補足情報は、「移行の制約」を参照してください。

手順

  1. 仮想マシンを移行するには、仮想マシンを指定します。

    $ openstack server migrate [vm] --wait

    [vm] を仮想マシンの ID に置き換えてください。ローカルに確保されたボリュームを移行する場合には、--block-migration フラグを指定します。

  2. 移行が完了するまで待ちます。移行のステータスを確認するには、「移行ステータスの確認」を参照してください。
  3. 移行が正常に完了したことを確認します。

    $ openstack server list --all-projects

仮想マシンの移行が終了したら、「移行後の操作」に進んでください。

8.6. 移行ステータスの確認

移行が完了するまでに、さまざまな移行状態を遷移します。正常な移行では、通常、移行状態は以下のように遷移します。

  1. Queued: nova は仮想マシン移行の要求を受け入れ、移行は保留中です。
  2. Preparing: nova は仮想マシン移行の準備中です。
  3. Running: nova は仮想マシンの移行プロセスを実行中です。
  4. Post-migrating: nova は仮想マシンを移行先コンピュートノードにビルドし、移行元コンピュートノードのリソースを解放しています。
  5. Completed: nova は仮想マシンの移行を完了し、移行元コンピュートノードのリソース解放を終了しています。

手順

  1. 仮想マシンの移行の一覧を取得します。

    $ nova server-migration-list [vm]

    [vm] を仮想マシンの名前または ID に置き換えてください。

  2. 移行のステータスを表示します。

    $ nova server-migration-show [vm] [migration]

    [vm] を仮想マシンの名前または ID に置き換えてください。[migration] を移行の ID に置き換えてください。

仮想マシンの移行に長い時間がかったり、エラーが発生したりする場合があります。詳しくは、「移行に関するトラブルシューティング」を参照してください。

8.7. 移行後の操作

1 つまたは複数の仮想マシンを移行したら以下の手順を確認し、必要に応じてそれらの手順を実施します。

コンピュートノードのメンテナンスに関する移行後の操作

メンテナンスのために移行元コンピュートノードを停止し、メンテナンスが完了したら、スケジューラーが新しい仮想マシンを移行元コンピュートノードに割り当てられるように、アンダークラウドから移行元コンピュートノードを再度有効にすることができます。

$ source ~/overcloudrc
$ openstack compute service set [source] nova-compute --enable

[source] を移行元コンピュートノードのホスト名に置き換えてください。

NUMA、CPU ピニング、または DPDK インスタンスの移行後の操作

NUMA、CPU ピニング、または DPDK を使用する仮想マシンを移行したら、アンダークラウドから移行先コンピュートノードを再度有効にしなければならない場合があります。

$ source ~/overcloudrc
$ openstack compute service set [dest] nova-compute --enable

[dest] を移行先コンピュートノードのホスト名に置き換えてください。

8.8. 移行に関するトラブルシューティング

仮想マシンの移行時には、さまざまな問題が発生する可能性があります。

  1. 移行プロセスでエラーが生じる。
  2. 移行プロセスが終了しない。
  3. 移行後に仮想マシンのパフォーマンスが低下する。

移行中のエラー

以下の問題が発生すると、移行操作が error 状態に遷移します。

  1. 異なるバージョンの OpenStack が存在するクラスターを実行する。
  2. 指定した仮想マシン ID が見つからない。
  3. 移行を試みている仮想マシンが error 状態にある。
  4. Compute サービスが停止している。
  5. 競合状態が発生する。
  6. ライブマイグレーションが failed 状態に移行する。

ライブマイグレーションが failed 状態に移行すると、通常は error 状態になります。failed 状態の原因となる可能性のある典型的な問題を以下に示します。

  1. 移行先コンピュートホストが利用可能な状態にない。
  2. スケジューラーの例外が発生する。
  3. コンピューティングリソースが不十分なため、再ビルドプロセスに失敗する。
  4. サーバーグループの確認に失敗する。
  5. 移行先コンピュートノードへの移行が完了する前に、移行元コンピュートノードの仮想マシンが削除される。

ライブマイグレーションのスタック

ライブマイグレーションが時間どおりに完了せず、永久に running 状態のままになる可能性があります。ライブマイグレーションが永久に完了しない一般的な理由は、nova が仮想マシンの変更を移行先コンピュートノードに複製するより早く、クライアントのリクエストにより移行元コンピュートノード上で実行中の仮想マシンに変更が生じることです。

この状況に対処する方法はいくつかあります。

  1. ライブマイグレーションを中止する。
  2. ライブマイグレーションを強制的に完了させる。

ライブマイグレーションの中止

移行プロセスが仮想マシンの状態の変化を移行先ノードにコピーするより早く仮想マシンの状態が変化する状況で、仮想マシンの動作を一時的に中断したくない場合には、ライブマイグレーションの手順を中止することができます。

  1. 仮想マシンの移行の一覧を取得します。

    $ nova server-migration-list [vm]

    [vm] を仮想マシンの名前または ID に置き換えてください。

  2. ライブマイグレーションを中止します。

    $ nova live-migration-abort [vm] [migration]

    [vm] を仮想マシンの名前または ID に、[migration] を移行の ID に、それぞれ置き換えてください。

ライブマイグレーション完了の強制

移行プロセスが仮想マシンの状態の変化を移行先ノードにコピーするより早く仮想マシンの状態が変化する状況で、仮想マシンの動作を一時的に中断して移行を強制的に完了させたい場合には、ライブマイグレーションの手順を強制的に完了させることができます。

重要

ライブマイグレーションを強制的に完了させると、かなりのダウンタイムが発生する可能性があります。

  1. 仮想マシンの移行の一覧を取得します。

    $ nova server-migration-list [vm]

    [vm] を仮想マシンの名前または ID に置き換えてください。

  2. ライブマイグレーションを強制的に完了させます。

    $ nova live-migration-force-complete [vm] [migration]

    [vm] を仮想マシンの名前または ID に置き換えてください。[migration] を移行の ID に置き換えてください。

移行後の仮想マシンのパフォーマンス低下

NUMA トポロジーを使用する仮想マシンの場合、移行元および移行先コンピュートノードの NUMA トポロジーおよび設定は同一でなければなりません。移行先コンピュートノードの NUMA トポロジーでは、十分なリソースが利用可能でなければなりません。移行元および移行先コンピュートノード間で NUMA 設定が同一でない場合、ライブマイグレーションは成功するが仮想マシンのパフォーマンスが低下する可能性があります。たとえば、移行元コンピュートノードは NIC 1 を NUMA ノード 0 にマッピングするが、移行先コンピュートノードは NIC 1 を NUMA ノード 5 にマッピングする場合、移行後に仮想マシンはバス内の最初の CPU からのネットワークトラフィックを NUMA ノード 5 の別の CPU にルーティングし、トラフィックを NIC 1 にルーティングする可能性があります。その結果、予想されたとおりに動作はしますが、パフォーマンスが低下します。同様に、移行元コンピュートノードの NUMA ノード 0 では十分な CPU および RAM が利用可能だが、移行先コンピュートノードの NUMA ノード 0 にリソースの一部を使用する仮想マシンがすでに存在する場合、仮想マシンは正常に動作するがパフォーマンスが低下する可能性があります。補足情報は、「移行の制約」を参照してください。