Use this procedure if "Applied To" is configured in any of the DFW rules (this means that "Applied To" is not set to "DFW").

Note: For NSX-V to NSX migration, see the KB article https://kb.vmware.com/s/article/56991 for more information.

For NSX to NSX-V migration, migrating a workload VM back to NSX-V might not work because the distributed firewall filter in NSX is always higher than in NSX-V. The workaround is to place the workload VM in the NSX exclusion list prior to vMotion.

Prerequisites

  • Ensure that:
    • vSphere vMotion is enabled on the VMkernel adapter of each host in the cluster that is involved in this migration. For detailed steps about enabling vMotion on the VMkernel adapter, see the vSphere product documentation.
    • The destination host in NSX has sufficient resources to receive the migrated VMs.
    • The source and destination hosts are in an operational state. Resolve any problems with hosts including disconnected states.

For more information about vMotion, see Migration with vMotion in the vSphere product documentation.

Procedure

  1. Run a script to specify an external-id for each vNIC in a VM and to vMotion the VM to the correct logical port..
    The logical port was already created by Migration Coordinator. The sample code below (and the script in github) determines the external-id for each vNIC so that the vNIC will connect to the logical port that was created. 
    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

    For an example of a complete script, see https://github.com/dixonly/samples/blob/main/vmotion.py

  2. Apply the Security Tags and VM static membership to the migrated VMs.
    POST https://{nsxt-mgr-ip}/api/v1/migration/vmgroup?action=post_migrate
    The vmgroup API endpoint with post_migrate action applies the NSX-V Security Tags to the migrated workload VMs on the NSX overlay segment.

    For an example request body of this API, see the Lift and Shift Migration Process section of the NSX Tech Zone article.

  3. Finalize the infrastructure to finish the migration.
    POST https://{nsxt-mgr-ip}/api/v1/migration?action=finalize_infra
    This migration API deletes any temporary object configurations that were created during the migration, and ensures that the NSX infrastructure is in a clean state. For example, temporary IP Sets are removed from the Groups.

    This POST API does not have a request body.

  4. Verify that the expected configuration items have been migrated to the NSX environment.
    For example, check whether the following configurations are migrated successfully:
    • User-defined Distributed Firewall rules.
    • All Grouping objects, such as IP Sets, Groups, Tags, and so on.
    • Effective members are displayed in the dynamic Groups.
    • Tags are applied to migrated workload VMs.
  5. (Optional) Starting with NSX 4.1.1, when the migration is completed and before you click Finish, you can click Get Migration Report to see if certain objects were migrated correctly. When the report is ready, click Download Report.
    The report contains the following information:
    • VMs with security tags in NSX-V and after being migrated. If there are differences, they will be listed.
    • Security groups in NSX-V and after being migrated. If there are differences, they will be listed.
  6. On the Migrate Workloads page, click Finish.
    A dialog box appears to confirm finishing the migration. If you finish the migration, all migration details are cleared. You can no longer review the settings of this migration. For example, which inputs were made on the Resolve Configuration page.

What to do next

After the migration of workload VMs and the DFW-only configuration is successful and thoroughly verified, remove the Layer 2 bridge to release the NSX Edge that you used for bridging.