如果在任何 DFW 规则中配置了“应用对象”(这意味着“应用对象”未设置为“DFW”),请使用该过程。

注: 对于 NSX-VNSX 的迁移,请参见知识库文章 https://kb.vmware.com/s/article/56991 以了解更多信息。

对于 NSXNSX-V 的迁移,可能无法将工作负载虚拟机迁移回 NSX-V,因为 NSX 中的分布式防火墙筛选器始终优先于 NSX-V 中的分布式防火墙筛选器。解决办法是在执行 vMotion 操作之前,将工作负载虚拟机置于 NSX 排除列表中。

前提条件

  • 请确保:
    • 在此迁移涉及的集群中的每个主机的 VMkernel 适配器上启用了 vSphere vMotion。有关在 VMkernel 适配器上启用 vMotion 的详细步骤,请参见 vSphere产品文档。
    • NSX 中的目标主机具有足够的资源来接收迁移的虚拟机。
    • 源主机和目标主机处于运行状态。解决主机的任何问题,包括断开连接状态。

有关 vMotion 的详细信息,请参见 vSphere 产品文档中的通过 vMotion 迁移

过程

  1. 运行脚本,为虚拟机中的每个 vNIC 指定外部 ID,并通过 vMotion 将虚拟机移到正确的逻辑端口。
    迁移协调器已创建逻辑端口。下面的示例代码(以及 github 中的脚本)将确定每个 vNIC 的 external-id,以便 vNIC 连接到所创建的逻辑端口。
    devices = vmObject.config.hardware.device
    nic_devices = [device for device in devices if isinstance(device, vim.Vm.device.VirtualEthernetCard)]
    vnic_changes = []
    for device in nic_devices:
        vif_id = vmObject.config.instanceUuid + ":" + str(device.key)
        vnic_spec = self._get_nsxt_vnic_spec(device, ls_id, vif_id)
        vnic_changes.append(vnic_spec)
    relocate_spec = vim.Vm.RelocateSpec()
    relocate_spec.SetDeviceChange(vnic_changes)
    # set other fields in the relocate_spec
    vmotion_task = vmObject.Relocate(relocate_spec)
    WaitForTask(vmotion_task)
    
    def _get_nsxt_vnic_spec(self, device, ls_id, vif_id):
        nsxt_backing = vim.Vm.Device.VirtualEthernetCard.OpaqueNetworkBackingInfo()
        nsxt_backing.SetOpaqueNetworkId(ls_id)
        nsxt_backing.SetOpaqueNetworkType('nsx.LogicalSwitch')
        device.SetBacking(nsxt_backing)
        device.SetExternalId(vif_id)
        dev_spec = vim.Vm.Device.VirtualDeviceSpec()
        dev_spec.SetOperation(vim.Vm.Device.VirtualDeviceSpec.Operation.edit)
        dev_spec.SetDevice(device)
        return dev_spec

    有关完整脚本的示例,请参见 https://github.com/dixonly/samples/blob/main/vmotion.py

  2. 将安全标记和虚拟机静态成员资格应用于迁移的虚拟机。
    POST https://{nsxt-mgr-ip}/api/v1/migration/vmgroup?action=post_migrate
    具有 post_migrate 操作的 vmgroup API 端点会将 NSX-V 安全标记应用于 NSX 覆盖网络分段上已迁移的工作负载虚拟机。

    有关该 API 的示例请求正文,请参见 NSX Tech Zone 文章的直接迁移过程部分。

  3. 最终完成基础架构以完成迁移。
    POST https://{nsxt-mgr-ip}/api/v1/migration?action=finalize_infra
    此迁移 API 将删除在迁移过程中创建的任何临时对象配置,并确保 NSX 基础架构处于干净状态。例如,将从组中移除临时 IP 集。

    该 POST API 没有请求正文。

  4. 验证是否已将预期的配置项目迁移到 NSX 环境。
    例如,检查是否成功迁移以下配置:
    • 用户定义的分布式防火墙规则。
    • 所有分组对象,例如 IP 集、组、标记等。
    • 在动态组中显示有效的成员。
    • 将标记应用于迁移的工作负载虚拟机。
  5. (可选) NSX 4.1.1 开始,迁移结束后,您可以在单击完成之前单击获取迁移报告,以检查某些对象是否已正确迁移。报告准备就绪后,单击下载报告
    该报告包含以下信息:
    • 迁移前与迁移后,NSX-V 中具有安全标记的虚拟机。如果存在差异,将列出这些差异。
    • 迁移前与迁移后,NSX-V 中的安全组。如果存在差异,将列出这些差异。
  6. 迁移工作负载页面上,单击完成
    将显示一个对话框,用于确认完成迁移。如果完成迁移,则清除所有迁移详细信息。无法再查看此迁移的设置。例如,在 解决配置页面上输入了哪些内容。

下一步做什么

在成功迁移并完全验证工作负载虚拟机和仅 DFW 配置后,请移除第 2 层网桥以释放用于桥接的 NSX Edge。