When Security Policies in your NSX-V environment use only a Network Introspection service that is provided by a partner, two approaches are available to migrate the NSX-V prepared hosts to NSX.
Both the approaches discussed in this topic assume that the partner service virtual machines (SVMs) in your NSX-V environment are not deleted before starting the migration coordinator. Depending on how much security protection downtime you are willing to accept during host migration, choose the host migration approach that best suits your needs.
When only Network Introspection service is running on your NSX-V hosts, In-Place host migration mode is not supported. Only Maintenance migration mode is supported. However, Automated Maintenance migration mode is recommended.
- Approach 1: Involves more security protection downtime
-
This approach is the simpler of the two host migration approaches. However, it involves more security protection downtime compared to Approach 2. Let us say that you have three clusters in your NSX-V environment: Cluster 1, Cluster 2, and Cluster 3.
In this approach, enable the Pause between groups migration setting and migrate Cluster 1 by using the standard host migration procedure that is explained in Migrate NSX-V Hosts. After Cluster 1 is migrated to NSX, the migration pauses. Deploy the partner service in Cluster 1 by doing either a host-based or a clustered service deployment. Now, disable the Pause between groups migration setting, and continue migrating Clusters 2 and 3. After the workload VMs in Clusters 2 and 3 are migrated to NSX, these workloads can start redirecting packets to the partner service virtual machines (SVM) in Cluster 1.
In this approach, security protection downtime is expected during migration of Cluster 1.
When workload VMs migrate to an NSX host, existing data traffic during a host migration is expected to have a security protection downtime. However, new data traffic does not have a security protection downtime.
- Approach 2: Involves minimal security protection downtime
-
This approach requires some manual intervention with an NSX API to create a temporary host group. Enable the Pause between groups migration setting and migrate any one host from Cluster 1. After this host in Cluster 1 is migrated to NSX, the migration coordinator pauses. Deploy a partner service on this migrated host by doing a clustered service deployment. Continue migrating the remaining hosts in Cluster 1. After all the hosts in Cluster 1 are migrated to NSX, you can optionally deploy additional partner SVMs in Cluster 1 by doing either a host-based or a clustered service deployment.
The detailed procedure in this topic explains the host migration workflow for a single NSX-V prepared cluster, which has three hosts, as shown in the following figure. The procedure uses Approach 2 to migrate this Cluster 1 to NSX.
Example:
All hosts in this cluster are ESXi hosts. The Security Policies in your NSX-V environment redirect data traffic to partner service virtual appliances that provide a network introspection service to workloads. As NSX-V supports only a host-based service deployment, each host has a single partner service VM.
- Host migration mode is set to Automated Maintenance.
- Pause between groups is enabled.
- Migration order across groups is set to serial.
Prerequisites
- Verify that Edge migration has finished and all routing and services are working correctly.
- In the vCenter Server UI, go to the Hosts and Clusters page, and verify that all ESXi hosts are in an operational state. Address any problems with hosts including disconnected states. There must be no pending reboots or pending tasks for entering and exiting maintenance mode.
- Enable vSphere DRS on the cluster that is being migrated.
- Enable vMotion on the VMkernel adapter of each host in the cluster.
- Ensure that adequate spare capacity is available in the NSX-V cluster so that the migrating hosts can enter into a maintenance mode. If enough spare capacity is unavailable to migrate NSX-V workload VMs to other hosts in the cluster, additional security protection downtime is expected.
Procedure
What to do next
- Log in to the vSphere Client and navigate to .
- Select the deployed partner service, and click Delete.