NSX for vSphere (NSX-v) features and configurations that can be migrated are listed below.

Platform Support

See the VMware Interoperability Matrix for supported versions of ESXi and vCenter Server.

NSX-v Configuration

Supported

Details

NSX Data Center for vSphere with vSAN or iSCSI on vSphere Distributed Switch

Yes

Pre-existing NSX-T configuration

No

Deploy a new NSX-T Data Center environment to be the destination for the NSX Data Center for vSphere migration.

During the Import Configuration step, all NSX Edge node interfaces in the destination NSX-T Data Center environment are shut down. If the destination NSX-T Data Center environment is already configured and is in use, starting the configuration import will interrupt traffic.

Cross vCenter NSX

(NSX-T 3.1) No

(NSX-T 3.1.1 and later) Yes if the NSX-v deployment has an NSX Manager in primary mode and no secondary NSX Managers.

Starting in NSX-T 3.1.1, migration of a single site NSX for vSphere deployment that contains an NSX Manager in primary mode, no secondary NSX Managers, and with universal objects on the primary site, is supported. Such a single site NSX for vSphere deployment is migrated to a single site NSX-T environment (non-federated) with local objects.

Migration of a true cross-vCenter NSX-V deployment with a primary NSX Manager and multiple secondary NSX Managers is not supported. Migration Coordinator will only migrate from an NSX-V Manager with the role of Primary or Standalone. You can modify the NSX-V environment by changing the status of the secondary managers in order to migrate each NSX-V environment independently.

NSX Data Center for vSphere with a Cloud Management Platform, Integrated Stack Solution, or PaaS Solution

Yes

Migration of NSX for vSphere with vRealize Automation is supported if the integrated environment is configured in a supported topology.

See Topologies Supported for Integration with vRealize Automation for details.

Contact your VMware representative before proceeding with migration. Scripts and integrations might break if you migrate the integrated environments:

For example:

  • NSX for vSphere and VMware Integrated Openstack

  • NSX for vSphere and vCloud Director

  • NSX for vSphere with Integrated Stack Solution

  • NSX for vSphere with PaaS Solution such as Pivotal Cloud Foundry, RedHat OpenShift

  • NSX for vSphere with vRealize Operations workflows

vSphere and ESXi Features

NSX-v Configuration

Supported

Details

ESXi host already in maintenance mode (no VMs)

Yes

Network I/O Control (NIOC) version 3

Yes

Network I/O Control (NIOC) version 2

No

Network I/O Control (NIOC) having vNIC with reservation

No

vSphere Standard Switch

No

VMs and VMkernel interfaces on VSS are not migrated. NSX Data Center for vSphere features applied to the VSS cannot be migrated.

vSphere Distributed Switch

 Yes

Stateless ESXi

No

Host profiles

No

ESXi lockdown mode

No

Not supported in NSX-T.

ESXi host pending maintenance mode task.

No

Disconnected ESXi host in vCenter cluster

No

vSphere FT

No

vSphere DRS fully automated

Yes

Supported starting in vSphere 7.0

vSphere High Availability

Yes (when maintenance mode is used)

Traffic filtering ACL

No

vSphere Health Check

No

SRIOV

No

vmknic pinning to physical NIC

No

Private VLAN

No

Ephemeral dvPortGroup

No

DirectPath IO

No

L2 security

No

Learn switch on virtual wire

No

Hardware Gateway (Tunnel endpoint integration with physical switching hardware)

No

SNMP

No

Disconnected vNIC in VM

No

Due to ESX 6.5 limitation, stale entries might present on DVFilter for disconnected VMs. Reboot the VM as a workaround.

VXLAN port number other than 4789

No

Multicast Filtering Mode

No

Hosts with multiple VTEPs

Yes

NSX Manager Appliance System Configuration

NSX-v Configuration

Supported

Details

NTP server/time setting

Yes

Syslog server configuration

Yes

Backup configuration

Yes

If needed, change NSX Data Center for vSphere passphrase to match NSX-T Data Center requirements. It must be at least 8 characters long and contain the following:

  • At least one lowercase letter

  • At least one uppercase letter

  • At least one numeric character

  • At least one special character

FIPS

No

FIPS on/off not supported by NSX-T.

Locale

No

NSX-T only supports English locale

Appliance certificate

No

Role-Based Access Control

NSX-v Configuration

Supported

Details

Local users

No

NSX roles assigned to a vCenter user added via LDAP

Yes

VMware Identity Manager must be installed and configured to migrate user roles for LDAP users.

NSX roles assigned to a vCenter group

No

Certificates

NSX-v Configuration

Supported

Details

Certificates (Server, CA signed)

Yes

This applies to certificates added through truststore APIs only.

Operations

Details

Supported

Notes

Discovery protocol CDP

No

Discovery protocol LLDP

Yes

The listen mode is turned on by default and can’t be changed in NSX-T. Only the Advertise mode can be modified.

PortMirroring:

  • Encapsulated remote Mirroring Source (L3)

Yes

Only L3 session type is supported for migration

PortMirroring:

  • Distributed PortMirroring

  • Remote Mirroring Source

  • Remote Mirroring Destination

  • Distributed Port Mirroring (legacy)

No

L2 IPFIX

Yes

LAG with IPFIX is not supported

Distributed Firewall IPFIX

No

MAC Learning

Yes

You must enable (accept) forged transmits.

Hardware VTEP

No

Promiscuous Mode

No

Resource Allocation

No

vNIC enabled with resource allocation is not supported

IPFIX – Internal flows

No

IPFIX with InternalFlows is not supported

Switch

NSX-v Configuration

Supported

Details

L2 Bridging

No

Trunk VLAN

Yes

Trunk uplink portgroups must be configured with a VLAN range of 0-4094.

VLAN Configuration

Yes

Configuration with only VLAN (no VXLAN) is supported.

Teaming and Failover:

  • Load Balancing

  • Uplink Failover Order

Yes

Supported options for load balancing (teaming policy):

  • Use explicit failover order

  • Route based on source MAC hash

  • Source port (starting with NSX-T 3.1.3).

Other load balancing options are not supported.

Teaming and Failover:

  • Network Failure Detection

  • Notify Switches

  • Reverse Policy

  • Rolling Order

No

LACP Yes

For VDS 7.0 and later, the LACP functionality is not modified during migration. For earlier versions of VDS, a new N-VDS switch replaces the VDS. This will lead to traffic loss during host migration.

IPFIX configured on DVS (not DFW IPFIX) is not supported with LACP

Switch Security and IP Discovery

NSX-v Configuration

Supported fro Migration

Details

IP Discovery (ARP, ND, DHCPv4 and DHCPv6)

Yes

The following binding limits apply on NSX-T for migration:

  • 128 for ARP discovered IPs

  • 128 for DHCPv4 discovered IPs

  • 15 for DHCPv6 discovered IPs

  • 15 for ND discovered IPs

SpoofGuard (Manual, TOFU, Disabled)

Yes

Switch Security (BPDU Filter, DHCP client block, DHCP server block, RA guard)

Yes

Migrating datapath bindings from Switch Security module in NSX Data Center for vSphere to Switch security module in NSX-T

Yes

If SpoofGuard is enabled, bindings are migrated from the Switch Security module to support ARP suppression.

VSIP – Switch security not supported as VSIP bindings are migrated as statically configured rules.

Discovery profiles

Yes

The ipdiscovery profiles are created after migration using the IP Discovery configuration for the logical switch and the global and cluster ARP and DHCP configuration.

Central Control Plane

NSX-v Configuration

Supported

Details

VTEP replication per logical switch (VNI) and routing domain

Yes

MAC/IP replication

No

NSX Data Center for vSphere transport zones using multicast or hybrid replication mode

No

NSX Data Center for vSphere transport zones using unicast replication mode

Yes

NSX Edge Features

For full details on supported topologies, see Supported Topologies.

NSX-v Configuration

Supported

Details

Routing between Edge Service Gateway and northbound router or virtual tunnel interface

Yes

BGP is supported.

Static routes are supported.

OSPF is not supported.

Routing between Edge Services Gateway and Distributed Logical Router

Yes

Routes are converted to static routes after migration.

Load balancer

Yes

See Supported Topologies for details.

VLAN-backed Micro-Segmentation environment

Yes

See Supported Topologies for details.

NAT64

No

Not supported in NSX-T.

Node level settings on Edge Services Gateway or Distributed Logical Router

No

Node level settings, for example, syslog or NTP server, are not supported.

IPv6

No

Unicast Reverse Path Filter (URPF) configuration for Edge Services Gateway interfaces

No

URPF on NSX-T gateway interfaces is set to Strict.

Maximum Transmission Unit (MTU) configuration Edge Services Gateway interfaces

No

 See Modify NSX Edge Node Configuration Before Migrating Edges for information about changing the default MTU on NSX-T.

IP Multicast routing

No

Route Redistribution Prefix Filters

No

Default originate

No

Not supported in NSX-T.

Edge Firewall

NSX-v Configuration

Supported

Details

Firewall Section: Display name

Yes

Firewall sections can have a maximum of 1000 rules. If a section contains more than 1000 rules, it is migrated as multiple sections.

Action for default rule

Yes

NSX Data Center for vSphere API: GatewayPolicy/action

NSX-T API: SecurityPolicy.action

Firewall Global Configuration

No

Default timeouts are used

Firewall Rule

Yes

NSX Data Center for vSphere API: firewallRule

NSX-T API: SecurityPolicy

Firewall Rule: name

Yes

Firewall Rule: rule tag

Yes

NSX Data Center for vSphere API: ruleTag

NSX-T API: Rule_tag

Sources and destinations in firewall rules:

  • Grouping objects

  • IP addresses

Yes

NSX Data Center for vSphere API:

  • source/groupingObjectId

  • source/ipAddress

NSX-T API:

  • source_groups

NSX Data Center for vSphere API:

  • destination/groupingObjectId

  • destination/ipAddress

NSX-T API:

  • destination_groups

Firewall rule sources and destinations:

  • vNIC Group

No

Services (applications) in firewall rules:

  • Service

  • Service Group

  • Protocol/port/source port

Yes

NSX Data Center for vSphere API:

  • application/applicationId

  • application/service/protocol

  • application/service/port

  • application/service/sourcePort

NSX-T API:

  • Services

Firewall Rule: Match translated

No

Match translated must be ‘false’.

Firewall Rule: Direction

Yes

Both APIs: direction

Firewall Rule: Action

Yes

Both APIs: action

Firewall Rule: Enabled

Yes

Both APIs: enabled

Firewall Rule: Logging

Yes

NSX Data Center for vSphere API: logging

NSX-T API: logged

Firewall Rule: Description

Yes

Both APIs: description

Edge NAT

NSX-v Configuration

Supported

Details

NAT rule

Yes

NSX Data Center for vSphere API: natRule

NSX-T API: /nat/USER/nat-rules

NAT rule: rule tag

Yes

NSX Data Center for vSphere API: ruleTag

NSX-T API: rule_tag

NAT rule: action

Yes

NSX Data Center for vSphere API: action

NSX-T API: action

NAT rule: original address (Source address for SNAT

rules, and the destination address for DNAT rules.)

Yes

NSX Data Center for vSphere API: originalAddress

NSX-T API: source_network for SNAT rule or destination_network for DNAT rule

NAT rule: translatedAddress

Yes

NSX Data Center for vSphere API: translatedAddress

NSX-T API: translated_network

NAT rule: Applying NAT rule on a specific interface

No

Applied on must be “any”.

NAT rule: logging

Yes

NSX Data Center for vSphere API: loggingEnabled

NSX-T API: logging

NAT rule: enabled

Yes

NSX Data Center for vSphere API: enabled

NSX-T API: disabled

NAT rule: description

Yes

NSX Data Center for vSphere API: description

NSX-T API: description

NAT rule: protocol

Yes

NSX Data Center for vSphere API: protocol

NSX-T API: Service

NAT rule: original port (source port for SNAT rules, destination port for DNAT rules)

Yes

NSX Data Center for vSphere API: originalPort

NSX-T API: Service

NAT rule: translated port

Yes

NSX Data Center for vSphere API: translatedPort

NSX-T API: Translated_ports

NAT rule: Source address in DNAT rule

Yes

NSX Data Center for vSphere API: dnatMatchSourceAddress

NSX-T API: source_network

NAT rule:

Destination address in SNAT rule

Yes

NSX Data Center for vSphere API: snatMatchDestinationAddress

NSX-T API: destination_network

NAT rule:

Source port in DNAT rule

Yes

NSX Data Center for vSphere API: dnatMatchSourcePort

NSX-T API: Service

NAT rule:

Destination port in SNAT rule

Yes

NSX Data Center for vSphere API: snatMatchDestinationPort

NSX-T API: Service

NAT rule: rule ID

Yes

NSX Data Center for vSphere API: ruleID

NSX-T API: id and display_name

L2VPN

NSX-v Configuration

Supported

Details

L2VPN configuration based on IPSec using pre-shared key (PSK)

Yes

Supported if the networking being stretched over L2VPN is an overlay logical switch. Not supported for VLAN networks.

L2VPN configuration based on IPSec using certificate-based authentication

No

L2VPN configuration based on SSL

No

L2VPN configurations with local egress optimizations

No

L2VPN client mode

No

L3VPN

NSX-v Configuration

Supported

Details

Dead Peer Detection

Yes

Dead Peer Detection supports different options on NSX Data Center for vSphere and NSX-T. You might want to consider using BGP for faster convergence or configure a peer to perform DPD if it is supported.

Changed Dead Peer Detection (dpd) default values for:

  • dpdtimeout

  • dpdaction

No

In NSX-T, dpdaction is set to “restart” and cannot be changed.

If NSX Data Center for vSphere setting for dpdtimeout is set to 0, dpd is disabled in NSX-T. Otherwise, any dpdtimeout settings are ignored and the default value is used.

Changed Dead Peer Detection (dpd) default values for:

  • dpddelay 

Yes

NSX Data Center for vSphere dpdelay maps to NSX-T dpdinternal.

Overlapping local and peer subnets of two or more sessions.

No

NSX Data Center for vSphere supports policy-based IPSec VPN sessions where the local and peer subnets of two or more sessions overlap with each other. This behavior is not supported on NSX-T. You must reconfigure the subnets so they do not overlap before you start the migration. If this configuration issue is not resolved, the Migrate Configuration step fails.

IPSec sessions with peer endpoint set as any.

No

Configuration is not migrated.

Changes to the extension securelocaltrafficbyip.

No

NSX-T Service Router does not have any local generated traffic that needs to be sent over tunnel.

Changes to these extensions:

auto, sha2_truncbug, sareftrack, leftid, leftsendcert, leftxauthserver, leftxauthclient, leftxauthusername, leftmodecfgserver, leftmodecfgclient, modecfgpull, modecfgdns1, modecfgdns2, modecfgwins1, modecfgwins2, remote_peer_type, nm_configured, forceencaps,overlapip, aggrmode, rekey, rekeymargin, rekeyfuzz, compress, metric,disablearrivalcheck, failureshunt,leftnexthop, keyingtries

No

Those extensions are not supported on NSX-T and changes to them are not migrated.

Load Balancer

NSX-v Configuration

Supported

Details

Monitor / health-checks for:

  • LDAP

  • DNS

  • MSSQL

No

If an unsupported monitor is configured, the monitor is ignored and the associated pool has no monitor configured. You can attach it to a new monitor after migration has finished.

Application rules

No

NSX Data Center for vSphere uses application rules based on HAProxy to support L7. In NSX-T, the rules are based on NGINX. The application rules cannot be migrated. You must create new rules after migration.

L7 virtual server port range

No

IPv6

No

If IPv6 is used in virtual server, the whole virtual server would be ignored.

If IPv6 is used in pool, the pool would be still migrated, however, the related pool member would be removed.

URL, URI, HTTPHEADER algorithms

No

If used in a pool, the pool is not migrated.

Isolated pool

No

The pool is not migrated.

LB pool member with different monitor port

No

The pool member which has different monitor port is not migrated.

Pool member minConn

No

Configuration is not migrated.

Monitor extension

No

Configuration is not migrated.

SSL sessionID persistence / table

No

Configuration is not migrated, and the associated virtual server has no persistence setting.

MSRDP persistence / session table

No

Configuration is not migrated, and the associated virtual server has no persistence setting.

Cookie app session / session table

No

Configuration is not migrated, and the associated virtual server has no persistence setting.

App persistence

No

Configuration is not migrated, and the associated virtual server has no persistence setting.

Monitor for:

  • Explicit escape

  • Quit

  • Delay

No

Monitor for:

  • Send

  • Expect

  • Timeout

  • Interval

  • maxRetries

Yes

Haproxy Tuning/IPVS Tuning

No

Pool IP filter

  • IPv4 addresses

Yes

IPv4 IP addresses are supported.

If Any is used, only the IPv4 addresses of the IP pool are migrated.

Pool IP Filter

  • IPv6 addresses

No

Pool containing unsupported grouping object:

  • Cluster

  • Datacenter

  • Distributed port group

  • MAC set

  • Virtual App

No

If a pool includes an unsupported grouping object, those objects are ignored, and the pool is created with supported grouping object members. If there are no supported grouping object members, then an empty pool is created.

DHCP and DNS

Table 1. DHCP Configuration Topologies

NSX-v Configuration

Supported

Details

DHCP Relay configured on Distributed Logical Router pointing to a DHCP Server configured on a directly connected Edge Services Gateway

Yes

The DHCP Relay server IP must be one of the Edge Services Gateway’s internal interface IPs.

The DHCP Server must be configured on an Edge Services Gateway that is directly connected to the Distributed Logical Router configured with the DHCP relay.

It is not supported to use DNAT to translate a DHCP Relay IP that does not match an Edge Services Gateway internal interface.

DHCP Relay configured on Distributed Logical Router only, no DHCP Server configuration on connected Edge Services Gateway

No

DHCP Server configured on Edge Services Gateway only, no DHCP Relay configuration on connected Distributed Logical Router

No

Table 2. DHCP Features

NSX-v Configuration

Supported

Details

IP Pools

Yes

Static bindings

Yes

DHCP leases

Yes

General DHCP options

Yes

Disabled DHCP service

No

In NSX-T you cannot disable the DHCP service. If there is a disabled DHCP service on NSX Data Center for vSphere it is not migrated.

DHCP option: "other"

No

The "other" field in dhcp options is not supported for migration.

For example, dhcp option '80' is not migrated. 

<dhcpOptions>
  <other>
    <code>80</code>
    <value>2f766172</value> 
  </other>
</dhcpOptions>

Orphaned ip-pools/bindings

No

If ip-pools or static-bindings are configured on a DHCP Server but are not used by any connected logical switches, these objects are skipped from migration.

DHCP configured on Edge Service Gateway with directly connected logical switches

No

During migration, directly connected Edge Service Gateway interfaces are migrated as centralized service ports. However, NSX-T does not support DHCP service on a centralized service port, so the DHCP service configuration is not migrated for these interfaces.

Table 3. DNS Features

NSX-v Configuration

Supported

Details

DNS views

Yes

Only the first dnsView is migrated to the NSX-T default DNS forwarder zone.

DNS configuration

Yes

You must provide available DNS listener IPs for all Edge Nodes. A message is displayed during Resolve Configuration to prompt for this.

DNS – L3 VPN

Yes

You must add the newly configured NSX-T DNS listener IPs into the remote L3 VPN prefix list. A message is displayed during Resolve Configuration to prompt for this.

DNS configured on Edge Service Gateway with directly connected logical switches

No

During migration, directly connected Edge Service Gateway interfaces are migrated as centralized service ports. However, NSX-T does not support DNS Service on a centralized service port, so the DNS Service configuration is not migrated for these interfaces.

Distributed Firewall (DFW)

NSX-v Configuration

Supported

Details

Identity-based Firewall

No

Section -

  • Name

  • Description

  • TCP Strict

  • Stateless Firewall

Yes

If a firewall section has more than 1000 rules, then the migrator will migrate the rules in multiple sections of 1000 rules each.

Universal Sections

(NSX-T 3.1) No

(NSX-T 3.1.1 and later) Yes if the NSX-v deployment has an NSX Manager in primary mode and no secondary NSX Managers.

Rule – Source / Destination:

  • IP Address / Range / CIDR

  • Logical Port

  • Logical Switch

Yes

Rule – Source / Destination:

  • VM

  • Logical Port

  • Security Group / IP Set / MAC Set

Yes

maps to Security Group

Rule – Source / Destination:

  • Cluster

  • Datacenter

  • DVPG

  • vSS

  • Host

No

Rule – Source / Destination:

  • Universal Logical Switch

(NSX-T 3.1) No

(NSX-T 3.1.1 and later) Yes if the NSX-v deployment has an NSX Manager in primary mode and no secondary NSX Managers.

Rule – Applied To:

  • ANY

Yes

maps to Distributed Firewall

Rule – Applied To:

  • Security Group

  • Logical Port

  • Logical Switch

  • VM

Yes

maps to Security Group

Rule – Applied To:

  • Cluster

  • Datacenter

  • DVPG

  • vSS

  • Host

No

Rule – Applied To:

  • Universal Logical Switch

(NSX-T 3.1) No

(NSX-T 3.1.1 and later) Yes if the NSX-v deployment has an NSX Manager in primary mode and no secondary NSX Managers.

Rules Disabled in Distributed Firewall

Yes

Disabling Distributed Firewall on a cluster level

No

When Distributed Firewall is enabled on NSX-T, it is enabled on all clusters. You cannot enable it on some clusters and disable on others.

DFW Exclusion List No DFW exclusion lists are not migrated. You need to re-create them on NSX-T after migration.

Note: When migrating DFW rules, be sure to migrate the objects referenced by the rules also. NSX-T cannot apply a rule if the objects referenced by the rule are not part of the NSX-T network.

Partner Services: East-West Network Introspection

NSX-v Configuration Supported Details

Service

No

Service registration is not migrated. Partner must register the service with NSX-T before migration.

Vendor Template

No

 Vendor template is not migrated. Partner must register the vendor template with NSX-T before migration.

Service Profile

No

Service profiles are not migrated. Either you or the partner must create the service profiles before migration.

In the Resolve Configuration step of the migration, the migration coordinator prompts you to map each NSX for vSphere service profile to an NSX-T service profile. If you skip the mapping of service profiles, the rules that use these service profiles are not migrated.

Migration coordinator creates a service chain in NSX-T for each service profile in NSX for vSphere.

The service chain is created with the following naming convention:

Service-Chain-service_profile_name

The same service profile is used in the forward path and reverse path of the service chain.

Service Instance

No

Partner service virtual machines (SVMs) are not migrated. The NSX for vSphere partner SVMs cannot be used in NSX-T.

For east-west Network Introspection service in NSX-T, partner service VMs must be deployed on an overlay segment.
Section
  • Name
  • ID
  • Description
  • TCP Strict
  • Stateless Firewall

Yes

A section maps to a redirection policy.

ID is user-defined, and not auto-generated in NSX-T.

If a firewall section in NSX for vSphere has more than 1000 rules, migration coordinator migrates the rules in multiple sections of 1000 rules each.

For example, if a section contains 2500 rules, the migration coordinator creates three policies: Policy 1 with 1000 rules, Policy 2 with 1000 rules, and Policy 3 with 500 rules.

Stateful or stateless firewall rules in NSX for vSphereare migrated to stateful or stateless redirection rules in NSX-T.

Partner Services: Rules

Name

Yes

Rule ID

Yes

Rule ID is system generated. It can be different from the rule ID in NSX for vSphere.

Negate Source

Yes

Negate Destination

Yes
Source/Destination
  • VM
  • Security Group
  • IP Set
  • vNIC

Yes

Services/Service Groups

Yes

 For details, see the Services and Service Groups table.
Advanced Settings
  • Direction
  • Packet Type
  • Rule Tag
  • Comments
  • Log

Yes
Service Profile and Action
  • Service Name
  • Service Profile
  • Action
  • Service Profile Bindings

Yes

A service profile binding can have Distributed Virtual Port Groups (DVPG), Logical Switches, and Security Groups as its members. A service profile binding in NSX for vSphere maps to the Applied To field of a redirection rule in NSX-T. Applied To field accepts only Groups, and this field determines the scope of the rule.

In NSX-T, rule redirection is at the level of a policy. All rules in a redirection policy have the same scope (Applied To).

Applied To field in an NSX-T redirection rule can have a maximum of 128 members. If the number of members in a service profile binding exceeds 128, reduce them to <= 128 before starting the migration.

For example, assume that a service profile binding has 140 members (Security Groups). Do the following steps in NSX for vSphere before starting the migration:
  1. Create a dummy Security Group.
  2. Move 13 Security Groups to this dummy Security Group. In other words, the dummy Security Group has 13 members.
  3. Remove the binding of these 13 Security Groups from the service profile. You now have 127 members in the service profile binding (140-13).
  4. Add the dummy Security Group to the service profile binding.

Now, the total number of members in the service profile binding is 128 (127 + 1), and it is within the maximum limit of the migration coordinator.

Enable/Disable Rule

Yes
Service Segment
Migration coordinator creates a service segment in the overlay transport zone that you select in the Resolve Configuration step of the migration. In the NSX for vSphere environment, if the VXLAN transport zone is not prepared with NSX for vSphere, the migration coordinator provides you the option to select the default overlay transport zone in NSX-T to create the service segment. If one or multiple VXLAN transport zones are prepared with NSX for vSphere, you must select any one overlay transport zone to create the service segment in NSX-T.
Service Profile Priority
In NSX for vSphere, a service profile has a priority. If a service has multiple service profiles, and multiple profiles are bound to the same vNIC, the service profile with higher priority is applied first on the vNIC. However, in NSX-T, service profile does not have a priority. When multiple redirection rules have the same Applied To setting, the rule order decides which rule is hit first. In other words, the migration coordinator places the rules with a higher profile priority before the rules with a lower profile priority in the NSX-T rule table. For a detailed example, see scenario 2 in Order of Migrated Network Introspection Rules in NSX-T Data Center.
Service Precedence

To redirect traffic to multiple services, NSX for vSphere uses multiple DVFilter slots in the service insertion data path. One DVFilter slot is used to redirect traffic to one service. A service with high precedence is placed higher in the slot compared to a service with low precedence. In NSX-T, only a single DVFilter slot is used and it redirects traffic to a service chain. After migration to NSX-T, the rules that use a partner service with higher precedence are placed before the rules that use a partner service with a lower precedence. For a detailed example, see scenario 3 in Order of Migrated Network Introspection Rules in NSX-T Data Center.

Migration coordinator does not support redirection of traffic on a vNIC to multiple partner services. Redirection to only a single partner service is supported. Although, all the NSX for vSphere rules are migrated to NSX-T, the migrated rule configurations use a service chain with only one service profile. You cannot modify an existing service chain that is used in redirection rules.

Workaround: To redirect traffic on a vNIC to multiple services, create a new service chain and define the order of service profiles in the service chain. Update the migrated rules to use this new service chain.

Network Introspection Service on VMs Connected to a VM Network
In the NSX-v environment, if Network Introspection service rules are running on VMs that are connected to a VM Network, these VMs lose security protection after host migration. To ensure that the Network Introspection rules are enforced on the vNICs of these VMs post host migration, you must connect these VMs to an NSX-T segment.

Grouping Objects and Service Composer

IP Sets and MAC Sets are migrated to NSX-T Data Center as groups. See Inventory > Groups in the NSX-T Manager web interface.

Table 4. IP Sets and MAC Sets

NSX-v Configuration

Supported

Details

IP Sets

Yes

IP sets with up to 2 million members (IP addresses, IP address subnets, IP ranges) can be migrated. IP sets with more members are not migrated.

Mac Sets

Yes

MAC sets with up to 2 million members can be migrated. MAC sets with more members are not migrated.

Security Groups are supported for migration with the limitations listed. Security Groups are migrated to NSX-T Data Center as Groups. See Inventory > Groups in the NSX-T Manager web interface.

NSX Data Center for vSphere has system-defined and user-defined Security Groups. These are all migrated to NSX-T as user-defined Groups.

The total number of ‘Groups’ after migration might not be equal to the number of Security Groups on NSX-v. For example, a Distributed Firewall rule containing a VM as its source would be migrated into a rule containing a new Group with the VM as its member. This increases the total number of groups on NSX-T after migration.

Table 5. Security Groups

NSX-v Configuration

Supported

Details

Security Group with members that don’t exist

No

If any of the members of the Security Group do not exist, then the Security Group is not migrated.

Security Group that contains a Security Group with unsupported members

No

If any members of the Security Group are not supported for migration, the Security Group is not migrated.

If a Security Group contains a Security Group with unsupported members, the parent Security Group is not migrated.

Exclude membership in Security Group

No

Security Groups with an exclude member directly or indirectly (via nesting) are not migrated

Security Group Static Membership

Yes

A Security Group can contain up to 500 static members. However, system-generated static members are added if the Security Group is used in Distributed Firewall rules, lowering the effective limit to 499 or 498.

  • If the Security Group is used in either layer 2 or layer 3 rules, one system-generated static member is added to the Security Group.

  • If the Security Group is used in both layer 2 and layer 3 rules, two system-generated static members are added.

If any members do not exist during the Resolve Configuration step, the security group is not migrated.

Security Group Member Types (Static or Entity Belongs To):

  • Cluster

  • Datacenter

  • Directory Group

  • Distributed Port Group

  • Legacy Port Group / Network

  • Resource Pool

  • vApp

No

If a security group contains any of the unsupported member types, the security group is not migrated.

Security Group Member Types (Static or Entity Belongs To):

  • Security Group

  • IP Sets

  • MAC Sets

Yes

Security groups, IP sets, and MAC sets are migrated to NSX-T as Groups. If an NSX for vSphere security group contains an IP set, MAC set, or nested security group as a static member, the corresponding Groups are added to the parent Group.

If one of these static members was not migrated to NSX-T, the parent security group does not migrate to NSX-T.

For example, an IP set with more than 2 million members cannot migrate to NSX-T. Therefore, a security group that contains an IP set with more than 2 million members cannot migrate.

Security Group Member Types (Static or Entity Belongs To):

  • Logical Switch (Virtual Wire)

Yes

If a security group contains logical switches that do not migrate to NSX-T segments, the security group does not migrate to NSX-T.

Security Group Member Types (Static or Entity Belongs To):

  • Security Tag

Yes

If a security tag is added to the security group as a static member or as a dynamic member using Entity Belongs To, the security tag must exist for the security group to be migrated.

If the security tag is added to the security group as a dynamic member (not using Entity Belongs To), the existence of the security tag is not checked before migrating the security group.

Security Group Member Types (Static or Entity Belongs To):

  • vNIC

  • Virtual Machine

Yes

  • vNICs and VMs are migrated as an ExternalIDExpression.

  • Orphaned VMs (VMs deleted from hosts) are ignored during Security Group migration.

  • Once the Groups appear on NSX-T, the VM and vNIC memberships are updated after some time. During this intermediate time, there can be temporary groups and their temporary groups might appear as members. However, once the Host Migration has finished, these extra temporary groups are no longer seen.

Using “Matches regular expression” operator for dynamic membership

No

This affects Security Tag and VM Name only. “Matches regular expression” is not available for other attributes.

Using other available operators for dynamic membership criteria for attributes:

  • Security Tag

  • VM Name

  • Computer Name

  • Computer OS Name

Yes

Available operators for VM Name, Computer Name, and Computer OS Name are Contains, Ends with, Equals to, Not equals to, Starts with.

Available operators for Security Tag are Contains, Ends with, Equals to, Starts with.

Entity Belongs to criteria

Yes

The same limitations for migrating static members apply to Entity Belongs to criteria. For example, if you have a Security Group that uses Entity Belongs to a cluster in the definition, the Security Group is not migrated.

Security Groups that contain Entity Belongs to criteria that are combined with AND are not migrated.

Dynamic membership criteria operators (AND, OR) in Security Group

Yes.

When you define dynamic membership for an NSX Data Center for vSphere Security Group, you can configure the following:

  • One or more dynamic sets.

  • Each dynamic set can contain one or more dynamic criteria. For example, “VM Name Contains web”.

  • You can select whether to match Any or All dynamic criteria within a dynamic set.

  • You can select to match with AND or OR across dynamic sets.

NSX Data Center for vSphere does not limit the number of dynamic criteria, dynamic sets, and you can have any combinations of AND and OR.

In NSX-T Data Center, you can have a group with five expressions. NSX Data Center for vSphere security groups which contain more than five expressions are not migrated.

Examples of security groups that can be migrated:

  • Up to 5 dynamic sets related with OR where each dynamic set contains up to 5 dynamic criteria related with AND (All in NSX Data Center for vSphere).

  • 1 dynamic set containing 5 dynamic criteria related with OR (Any in NSX Data Center for vSphere).

  • 1 dynamic set containing 5 dynamic criteria related with AND (All in NSX Data Center for vSphere). All member types must be the same.

  • 5 dynamic sets related with AND and each dynamic set containing exactly 1 dynamic criteria. All member types must be the same.

Using “Entity belongs to” criteria with AND operators is not supported.

All other combinations or definitions of a security group containing unsupported scenarios are not migrated.

In NSX Data Center for vSphere, security tags are objects which can be applied to VMs. When migrated to NSX-T security tags are attributes of a VM.

Table 6. Security Tags

NSX-v Configuration

Supported

Details

Security Tags

Yes

If a VM has 25 or fewer security tags applied, migration of security tags is supported. If more than 25 security tags are applied, no tags are migrated.

Note: If security tags are not migrated, the VM is not included in any groups defined by tag membership.

Services and Service Groups are migrated to NSX-T Data Center as Services. See Inventory > Services in the NSX-T Manager web interface.

Table 7. Services and Service Groups

NSX-v Configuration

Supported

Details

Services and Service Groups (Applications and Application Groups)

Yes

Most of the default Services and Service Groups are mapped to NSX-T Services. If any Service or Service Group is not present in NSX-T, a new Service is created in NSX-T.

APP_ALL and APP_POP2 Service Groups

No

These system-defined service groups are not migrated.

Services and Service Groups with naming conflicts

Yes

If a name conflict is identified in NSX-T for a modified Service or Service Group a new Service is created in NSX-T with a name in format: <NSXv-Application-Name> migrated from NSX-V

Service Groups that combine layer 2 services with services in other layers

No

Empty Service Groups

No

NSX-T does not support empty Services.

Layer 2 Services

Yes

NSX Data Center for vSphere layer 2 Services are migrated as NSX-T Service Entry EtherTypeServiceEntry.

Layer 3 Services

Yes

Based on the protocol, NSX Data Center for vSphere layer 3 Services are migrated to NSX-T Service Entry as follows:

  • TCP/UDP protocol: L4PortSetServiceEntry

  • ICMP / IPV6ICMP protocol:

ICMPTypeServiceEntry

  • IGMP protocol: IGMPTypeServiceEntry

  • Other protocols: IPProtocolServiceEntry

Layer 4 Services

Yes

Migrated as NSX-T Service Entry ALGTypeServiceEntry.

Layer 7 Services

Yes

Migrated as NSX-T Service Entry PolicyContextProfile

If an NSX Data Center for vSphere Layer 7 application has a port and protocol defined, a Service is created in NSX-T with the appropriate port and protocol configuration and mapped to the PolicyContextProfile.

Layer 7 Service Groups

No

Distributed Firewall, Edge Firewall, or NAT rules that contain port and protocol

Yes

NSX-T requires a Service to create these rules. If an appropriate Service exists, it is used. If no appropriate Service exists, a Service is created using the port and protocol specified in the rule.

Table 8. Service Composer

NSX-v Configuration

Supported

Details

Service Composer Security Policies

Yes

Firewall rules defined in a Security Policy are migrated to NSX-T as Distributed Firewall rules.

Disabled firewall rules defined in a Service Composer Security Policy are not migrated.

Guest Introspection rules or Network Introspection rules defined in a Service Composer Security Policy are migrated.

If the Service Composer status is not in sync, the Resolve Configuration step shows a warning.

You can either skip the migration of Service Composer policies by skipping the relevant Distributed Firewall sections. Alternatively, you can cancel the migration, get Service Composer in sync with Distributed Firewall, and restart the migration.

Service Composer Security Policies not applied to any Security Groups

No

Active Directory Server Configuration

Configuration

Supported

Details

Active Directory (AD) server

No