NSX Data Center for vSphere の移行を完了する際に、エラーが表示されることがあります。問題の解決に、以下のトラブルシューティング情報が役立つ場合があります。

Migration Coordinator へのアクセス

問題 解決方法
[システム] > [移行] に Migration Coordinator が表示されない。 NSX Manager で Migration Coordinator サービスが実行されているかどうかを確認します。 
manager> get service migration-coordinator
Service name:                     migration-coordinator
Service state:                    running

サービスが実行されていない場合は、start service migration-coordinator を指定して起動します。

Cigration Coordinator サービスに戻ると、進行中の移行が表示されない。
Migration Coordinator は vCenter Server または NSX Manager の認証情報を保存しません。移行が進行中の場合に Migration Coordinator サービスを再起動すると、 [システム] > [移行] ページに古い設定情報が表示されたり、設定情報が表示されなかったりすることがあります。Migration Coordinator サービスの再起動中に最新の移行状態を表示するには、次の操作を実行します。
  1. [システム] > [移行] ページを更新します。
  2. [はじめに] をクリックして、vCenter Server および NSX Manager の認証情報を入力します。

構成の問題のインポート

問題 解決方法
構成のインポートに失敗する。
  1. [再試行] をクリックして、インポートを再試行します。失敗したインポート手順のみが再試行されます。

ホストの移行の問題

問題 解決方法
コンピュート マネージャの構成が見つからないため、ホストの移行が失敗する。

移行するには、コンピュート マネージャの構成が必要です。ただし、移行を開始した後に NSX Manager からコンピュート マネージャの構成が削除された場合は、Migration Coordinator によって設定が維持されます。移行はホストの移行手順まで続行され、そこで失敗します。

NSX Manager にコンピュート マネージャを追加し、NSX-v 構成の最初のインポートに使用された vCenter Server の詳細を入力します。

古い dvFilters が存在するため、ホストの移行に失敗する。

エラーメッセージの例：Stale dvFilters present: ['port 33554463 (disconnected)', 'port 33554464 (disconnected)'] Stale dvfilters present. Aborting ]

移行に失敗したホストにログインし、切断されたポートを特定して、適切な仮想マシンを再起動するか、切断されたポートを接続します。その後、ホストの移行手順を再試行できます。

  1. 移行に失敗したホストのコマンドライン インターフェイスにログインします。
  2. summarize-dvfilter を実行し、エラー メッセージで報告されたポートを検索します。 
    world 1000057161 vmm0:2-vm_RHEL-srv5.6.0.9-32-local-258-963adcb8-ab56-41d6-bd9e-2d1c329e7745 vcUuid:'96 3a dc b8 ab 56 41 d6-bd 9e 2d 1c 32 9e 77 45'
 port 33554463 (disconnected)
  vNic slot 2
  name: nic-1000057161-eth1-vmware-sfw.2
 agentName: vmware-sfw
   state: IOChain Detached
   vmState: Detached
   failurePolicy: failClosed
   slowPathID: none
   filter source: Dynamic Filter Creation
  3. 影響を受ける仮想マシンとポートを特定します。
    たとえば、エラー メッセージには、ポート 33554463 が切断されていると示されています。
    1. このポートに対応する summarize-dvfilter 出力のセクションを探します。このセクションに仮想マシン名が表示されています。この場合は 2-vm_RHEL-srv5.6.0.9-32-local-258-963adcb8-ab56-41d6-bd9e-2d1c329e7745 です。
    2. name エントリを探して、インターフェイスが切断されている仮想マシンを特定します。この場合は eth1 です。したがって、2-vm_RHEL-srv5.6.0.9-32-local-258-963adcb8-ab56-41d6-bd9e-2d1c329e7745 の 2 番目のインターフェイスが切断されています。
  4. このポートの問題を解決します。次の手順のいずれかを実行します。
    • 影響を受ける仮想マシンを再起動します。
    • 切断された vNIC ポートをいずれかのネットワークに接続します。
  5. [ホストの移行] ページで [再試行] をクリックします。

vMotion を使用してホストを移行した後、NSX-v で SpoofGuard が有効になっていると、仮想マシンでトラフィックが停止することがあります。

症状：

/var/run/log/ にあるホストの vmkernel.log ファイルに、SpoofGuard によるトラフィックのドロップが表示されます。

たとえば、ログ ファイルに次の項目が表示されます。WARNING: swsec.throttle: SpoofGuardMatchWL:296:[nsx@6876 comp="nsx-esx" subcomp="swsec"]Filter 0x8000012 [P]DROP sgType 4 vlan 0 mac 00:50:56:84:ee:db

原因：

論理スイッチと論理スイッチ ポートの構成が Migration Coordinator で移行されています。これにより、SpoofGuard の構成が移行されています。ただし、検出されたポートの割り当ては vMotion で移行されません。このため、SpoofGuard はパケットをドロップします。
移行前に NSX-v で SpoofGuard が有効になっている場合は、仮想マシンの vMotion 後に、次のいずれかの回避策を行います。
  • SpoofGuard ポリシーを無効にします。
  • ポートの IP アドレスと MAC アドレスの割り当てを手動割り当てとして追加します。
  • ARP スヌーピングが有効になっている場合は、仮想マシンの IP アドレスが ARP によってスヌーピングされるまで待ちます。

最初の 2 つのオプションの場合、ネットワーク トラフィックがすぐにリストアされます。

3 番目のオプションの場合：
  • 仮想マシンが ARP 要求または応答を送信するまでトラフィックのダウンタイムが発生します。
  • DHCP スヌーピングも有効になっていて、仮想マシンの IP アドレスが DHCP サーバによって割り当てられていると、ほとんどの場合、まず ARP としてスヌーピングされ、後で DHCP でスヌーピングされた IP アドレスとしてスヌーピングされます。

クラスタの移行中に、ホストのハードウェア障害が原因で、ホストの移行に失敗しました。

たとえば、クラスタに 10 台のホストがあり、4 台のホストが正常に移行されたとします。5 番目のホストにハードウェア障害が発生し、ホストの移行が失敗します。
ホスト ハードウェアの障害を解決できない場合は、この障害が発生したホストの移行をスキップして、ホストの移行を再試行してください。次の回避策の手順を実行してください。
  1. vCenter Server のユーザー インターフェイスで、障害が発生したホストをインベントリから削除します。

    ホストが削除されるまで数分待ちます。

  2. Migration Coordinator サービスが実行されている NSX-T NSX Manager アプライアンスにログインし、次の API 要求を実行します。

    GET https://{nsxt-policy-ip}/api/v1/migration/migration-unit-groups?component_type=HOST&sync=true

  3. NSX-T NSX Manager のユーザー インターフェイスに戻り、ブラウザを更新します。失敗したホストが表示されなくなったことを確認します。
  4. [再試行] をクリックして、ホストの移行を再開します。
なんらかの理由で Migration Coordinator を再起動する必要がある場合、 [ホストの移行]ページですでに NSX-Tに移行されているクラスタを再度移行に使用できるようになります。この動作は既知の問題です。この場合、回避策として次の手順を実行し、移行されたクラスタをスキップします。
  1. Migration Coordinator サービスが実行されている NSX-T NSX Manager アプライアンスへの SSH セッションを開きます。
  2. /var/log/migration-coordinator/v2t/clusters-to-migrate.json ファイルを編集して、すでに移行されているクラスタを削除します。

    たとえば、ファイルに次の内容が含まれていて、クラスタ-1 が移行されている場合は、要素 {"modId":"domain-c9", "name":"cluster-1"} を削除します。

    "clusters":[
   {
     "modId":"domain-c9",
     "name":"cluster-1"
   },
   {
     "modId":"domain-c19",
     "name":"cluster-2"
   }
 ]
  3. 前の回避策で説明したように、NSX Manager アプライアンスで同じ API 要求を実行します。
  4. NSX-T NSX Manager のユーザー インターフェイスに戻り、ブラウザを更新します。[ホストの移行] ページに移動し、clusters-to-migrate.json ファイルから削除されたクラスタが [移行しない] と表示されることを確認します。
  5. [再試行] をクリックして、ホストの移行を再開します。

移行のキャンセル

問題 解決方法
Edge Services Gateway の移行後に移行をキャンセルすると、NSX-T に古い VTEP テーブルが残る可能性があります。NSX-T にトランスポート ノードが存在する場合、これらの古い VTEP のトンネルは停止状態のままになります。 古い VTEP データを削除するには、次の API 呼び出しを行います。 
GET https://<nsx-manager-IP>/api/v1/global-configs/SwitchingGlobalConfig
結果のペイロードの global_replication_mode_enabled パラメータが true の場合、このペイロードを使用して global_replication_mode_enabled を false に設定し、次の API 呼び出しを行います。 
PUT https://<nsx-manager-IP>/api/v1/global-configs/SwitchingGlobalConfig
。

パートナー サービスの移行に関する問題

問題 解決方法

NSX-v 環境のセキュリティ ポリシーにネットワーク イントロスペクション ルールが含まれていても、Migration Coordinator の [構成の解決] ページに、サービス挿入カテゴリに関するフィードバック メッセージが表示されません。

この問題は、同じパートナーからゲスト イントロスペクションとネットワーク イントロスペクション サービスの両方を移行している場合に発生します。NSX-T にパートナー サービスのサービス プロファイルがすでに作成されている場合、Migration Coordinator はネットワーク イントロスペクション ルールの移行を開始しません。
NSX-T 環境にサービス プロファイルがすでに作成されているかどうかを確認します。作成されている場合は、次の操作を行います。
  1. 移行をロールバックします。
  2. NSX-T でパートナー サービス プロファイルとサービスの参照を削除します。
  3. 移行を再度開始します。

移行後の問題

問題 解決方法

移行後、ESG がネットワークから削除されると、NSX-T は、これらの ESG の OSPF ネイバーが停止していることを示すアラームを生成します。解決しても、アラームは再度発生します。

アラームを確認しますが、解決はしないでください。これにより、アラームが再度発生しなくなります。