本節中的資訊可能有助於對移轉期間出現的問題進行疑難排解。

匯入組態問題

問題 解決方案
匯入組態失敗。 按一下重試以再次嘗試匯入。僅重試失敗的匯入步驟。

主機移轉問題

問題 解決方案
由於遺失計算管理程式組態，主機移轉失敗。

計算管理程式組態是移轉的必要條件。但是，如果在移轉開始後從 NSX Manager 移除了計算管理程式組態，則移轉協調器會保留此設定。將繼續執行移轉，直到主機移轉步驟失敗。

將計算管理程式新增至 NSX Manager，然後輸入用於初始 NSX-V 組態匯入的相同 vCenter Server 詳細資料。

由於存在失效的 dvFilter，主機移轉失敗。

錯誤訊息範例：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 的第二個介面已中斷連線。
  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

原因：

邏輯交換器和邏輯交換器連接埠組態會透過移轉協調器進行移轉，這會移轉 SpoofGuard 組態。但是，探索到的連接埠繫結不會透過 vMotion 來移轉。因此，SpoofGuard 會捨棄封包。
如果移轉之前在 NSX-V 中啟用 SpoofGuard，請在執行虛擬機器的 vMotion 後執行下列其中一項因應措施步驟：
  • 停用 SpoofGuard 原則。
  • 將連接埠 IP 和 MAC 位址繫結新增為手動繫結。
  • 如果已啟用 ARP 窺探，請等待 ARP 窺探到虛擬機器 IP 位址。

在前兩個選項中，系統會立即還原網路流量。

在第三個選項中：
  • 在虛擬機器傳送 ARP 要求或回覆之前，觀察到流量停機時間。
  • 如果同時啟用了 DHCP 窺探，且虛擬機器 IP 位址是由 DHCP 伺服器指派，則它最有可能會先被窺探為 ARP，並在稍後窺探為 DHCP 窺探的 IP 位址。

在叢集移轉期間，主機移轉因主機中的某項硬體故障而失敗。

例如，假設叢集有 10 個主機，而有四個主機已成功移轉。第五個主機發生硬體故障，導致主機移轉失敗。
如果無法修正主機硬體故障，請略過對此失敗主機進行移轉的作業，然後重試主機移轉。完成下列因應措施步驟：
  1. 在 vCenter Server UI 中，從詳細目錄中移除失敗的主機。

    等待幾分鐘讓系統移除主機。

  2. 登入正在執行移轉協調器服務的 NSX Manager 應用裝置，然後執行下列 API 要求：

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

  3. 返回 NSX-T NSX Manager UI，然後重新整理瀏覽器。確認失敗的主機已不再顯示。
  4. 按一下重試，重新開始進行主機移轉。
若您基於任何原因而需要重新啟動移轉協調器服務，已移轉至 NSX-T 的叢集在 移轉主機頁面上會再次成為可供移轉的項目。此行為是已知問題。在此情況下，因應措施是執行下列步驟以略過已移轉的叢集：
  1. 對執行移轉協調器服務的 NSX-T NSX Manager 應用裝置開啟 SSH 工作階段。
  2. 編輯 /var/log/migration-coordinator/v2t/clusters-to-migrate.json 檔案，以移除已移轉的叢集。

    例如，如果檔案中有下列內容，且 cluster-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 UI，然後重新整理瀏覽器。移至移轉主機頁面，並確認已從 clusters-to-migrate.json 檔案中移除的叢集顯示為不移轉。
  5. 按一下重試，重新開始進行主機移轉。
接受建議後主機移轉會遭到封鎖，這是因為 NSX-V 控制器虛擬機器處於關閉電源狀態。 在主機移轉步驟中，意見反應建議您中止移轉。如果接受建議，移轉將會失敗。由於 Edge 完全移轉已完成，因此，您可以將動作變更為 skip，然後執行以下步驟以繼續移轉：
  1. 進行以下 API 呼叫，然後搜尋 NoNsxvControllerInRunningSate 的結果，以尋找意見反應要求並取得其識別碼：
    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 中取得的識別碼)：
    PUT https://$NSX_MANAGER_IP/api/v1/migration/feedback-response -d '{"response_list":[{"id": $FEEDBACK_ID, "action": "skip" }]}'

復原移轉

問題 解決方案
對於某些 NSX-V OSPF 部署，如果在 Edge 移轉階段後執行復原，您可能會看到以下錯誤「原因：NSCutover 失敗並顯示 400: NSX Edge 虛擬機器 vm-XXXX 上的組態失敗」。 重新部署相關的 NSX-V Edge 虛擬機器。成功重新部署虛擬機器後，再次執行復原。

重試移轉

問題 解決方案
如果主機在移轉期間因任何原因重新開機，重試移轉將會失敗，並顯示錯誤訊息，如「找不到要求的物件：TransportNode/42178ba8-49fb-9545-2b78-5e9c64fddda7。物件識別碼區分大小寫。」 執行下列步驟：
  1. 從 VC UI 中，將主機從其叢集中移除，並使其成為獨立主機。
  2. 從 NSX Manager UI 中，使用相同的 VDS 在獨立主機上設定 NSX。使傳輸節點加入其他已移轉主機加入的相同覆疊和 VLAN 傳輸區域。
  3. 從 NSX Manager UI 中，返回移轉畫面，重新整理該畫面以確保主機不在正在移轉的叢集中。重試叢集移轉。
  4. 移轉後，將主機新增回到叢集。

移除失效的 VTEP 資料

問題 解決方案
如果在移轉 Edge 服務閘道後中止移轉，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 環境中的安全性原則包含網路自我檢查規則，移轉協調器仍不會在解決組態頁面上顯示服務插入類別的意見反應訊息。

當您從相同合作夥伴移轉 Guest Introspection 和網路自我檢查服務的組合時，即會發生此問題。如果已在 NSX-T 中建立合作夥伴服務的服務設定檔，則移轉協調器不會起始網路自我檢查規則的移轉。
檢查是否已在 NSX-T 環境中建立服務設定檔。如果是，請執行下列步驟：
  1. 復原該移轉。
  2. 刪除 NSX-T 中的合作夥伴服務設定檔和服務參考。
  3. 重新開始移轉。

移轉後的問題

問題 解決方案

在移轉後，當從網路中移除 ESG 之後，NSX-T 會發出警示，指出這些 ESG 的 OSPF 芳鄰已關閉。如果您解決了警示，仍會再次發出。

請確認警示，但不加以解決。這樣可以防止再次發出警示。