このセクションの情報は、移行中の問題のトラブルシューティングに役立つ場合があります。

構成の問題のインポート

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

ホストの移行の問題

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

移行するには、コンピュート マネージャの構成が必要です。ただし、移行を開始した後に 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 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. [再試行] をクリックして、ホストの移行を再開します。
NSX-V コントローラ仮想マシンがパワーオフ状態であるため、推奨事項が受け入れられた後に、ホストの移行がブロックされます。 ホストの移行手順で移行を中止することをお勧めします。推奨事項を受け入れると、移行は失敗します。Edge のカットオーバーが実行されるため、アクションを skip に変更し、次の手順で移行を続行できます。
  1. 次の API 呼び出しを実行し、NoNsxvControllerInRunningSate の結果を検索してフィードバック要求を検索して、その ID を取得します。
    GET https://$NSX_MANAGER_IP/api/v1/migration/feedack-requests?state=UNRESOLVED
  2. 次の API 呼び出しを実行して、すべての推奨事項を受け入れます。
    POST https://$NSX_MANAGER_IP/api/v1/migration/feedback-response?action=accept-recommended
  3. 次の API 呼び出しを使用して、アクションが skip のフィードバック応答を提供します（$FEEDBACK_ID は手順 1 で取得した ID です）。
    PUT https://$NSX_MANAGER_IP/api/v1/migration/feedback-response -d '{"response_list":[{"id": $FEEDBACK_ID, "action": "skip" }]}'

移行のロールバック

問題 解決方法
一部の NSX-V OSPF 展開で、Edge の移行フェーズ後にロールバックを実行すると、「Reason: NSCutover failed with '400: Configuration failed on NSX Edge VM vm-XXXX」というエラーが表示されることがあります。 関連する NSX-V Edge 仮想マシンを再展開します。仮想マシンが正常に再展開されたら、ロールバックを再度実行します。

移行の再試行

問題 解決方法
移行中に何らかの理由でホストが再起動すると、次のエラーが返され、移行の再試行が失敗します。「The requested object : TransportNode/42178ba8-49fb-9545-2b78-5e9c64fddda7 could not be found.Object identifiers are case sensitive.」 次の手順を実行してください。
  1. vCenter Server ユーザー インターフェイスで、クラスタからホストを削除し、スタンドアローン ホストにします。
  2. NSX Manager ユーザー インターフェイスから、同じ VDS を使用してスタンドアローン ホストで NSX を構成します。移行された他のホストと同じオーバーレイ トランスポート ゾーンと VLAN トランスポート ゾーンに、トランスポート ノードを参加させます。
  3. NSX Manager ユーザー インターフェイスから移行画面に戻り、画面を更新して、移行中のクラスタにホストが含まれていないことを確認します。クラスタの移行を再試行します。
  4. 移行後、ホストをクラスタに再度追加します。

古い VTEP データの削除

問題 解決方法
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 ネイバーが停止していることを示すアラームを生成します。解決しても、アラームは再度発生します。

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