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

导入配置问题

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

主机迁移问题

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

计算管理器配置是迁移的必备条件。但是,如果启动迁移后将计算管理器配置从 NSX Manager 中移除,迁移协调器会保留该设置。迁移将继续执行到主机迁移步骤,而该步骤失败。

将计算管理器添加到 NSX Manager 并输入用于初始 NSX-V 配置导入的相同 VMware vCenter 详细信息。

由于存在失效的 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. VMware vCenter UI 中,从清单中移除失败主机。

    等待几分钟,直到移除了该主机。

  2. 登录到运行迁移协调器服务的 NSX Manager 设备,然后运行以下 API 请求:

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

  3. 返回到 NSX NSX Manager UI,并刷新浏览器。可以观察到不再显示失败主机。
  4. 单击重试以重新启动主机迁移。
如果出于任何原因需要重新启动迁移协调器服务,已迁移到 NSX 的集群在 迁移主机页面上再次变为可进行迁移。此行为是一个已知问题。在这种情况下,解决办法是执行以下步骤以跳过迁移的集群:
  1. 打开到运行迁移协调器服务的 NSX 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 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 中可能存在失效的 VTEP 表。如果 NSX 中具有传输节点,则这些失效 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 中创建合作伙伴服务的服务配置文件,则迁移协调器不会启动网络侦测规则迁移。

检查是否已在 NSX 环境中创建服务配置文件。如果是,请执行以下步骤:
  1. 回滚迁移。
  2. NSX 中删除合作伙伴服务配置文件和服务引用。
  3. 重新启动迁移。

迁移后问题

问题 解决方案

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

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