本节中的信息可能有助于对迁移期间出现的问题进行故障排除。

导入配置问题

问题 解决方案
导入配置失败 单击重试，尝试重新导入。仅重试失败的导入步骤。

主机迁移问题

问题 解决方案
由于缺少计算管理器配置，主机迁移失败。

计算管理器配置是迁移的必备条件。但是，如果启动迁移后将计算管理器配置从 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 个主机，并且已成功迁移 4 个主机。第 5 个主机发生硬件故障，而导致主机迁移失败。
如果无法修复主机硬件故障，请跳过该失败主机以进行迁移，然后重试该主机迁移。完成以下解决办法步骤：
  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 的结果，以查找反馈请求并获取其 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 迁移阶段后执行回滚，您可能会看到错误“原因: NSCutover 失败并显示‘400: NSX Edge 虚拟机 vm-XXXX 上的配置失败’”(Reason: NSCutover failed with '400: Configuration failed on NSX Edge VM vm-XXXX)。 重新部署相关的 NSX-V Edge 虚拟机。成功重新部署虚拟机后，再次执行回滚。

重试迁移

问题 解决方案
如果主机在迁移期间出于任何原因重新引导，重试迁移将失败，并显示错误消息，如“找不到请求的对象 TransportNode/42178ba8-49fb-9545-2b78-5e9c64fddda7。对象标识符区分大小写。”(The requested object : TransportNode/42178ba8-49fb-9545-2b78-5e9c64fddda7 could not be found. Object identifiers are case sensitive.) 执行下列步骤：
  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 环境中的安全策略包含网络侦测规则，迁移协调器也不会在解决配置页面上显示服务插入类别的反馈消息。

在迁移来自同一合作伙伴的客户机侦测和网络侦测服务组合时，将会出现该问题。如果已在 NSX-T 中创建合作伙伴服务的服务配置文件，则迁移协调器不会启动网络侦测规则迁移。
检查是否已在 NSX-T 环境中创建服务配置文件。如果是，请执行以下步骤：
  1. 回滚迁移。
  2. 在 NSX-T 中删除合作伙伴服务配置文件和服务引用。
  3. 重新启动迁移。

迁移后问题

问题 解决方案

迁移后并且从网络中移除 ESG 后，NSX-T 会发出有关这些 ESG 的 OSPF 邻居已关闭的警报。如果解决了该警报，系统会再次发出警报。

确认警报，但不解决这些警报。这样可以防止再次发出警报。