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-V with vSAN or iSCSI on vSphere Distributed Switch

Yes

Pre-existing NSX-T configuration

No

You must deploy a new NSX-T environment.

If the migration mode is not for a user-defined topology, during the Import Configuration step, all NSX-T Edge node interfaces in the NSX-T environment are shut down. If the NSX-T environment is in use, this will interrupt traffic.

Cross-vCenter NSX

(NSX-T 3.2.1 and later) Yes

(NSX-T 3.2.0) Yes, but with no secondary NSX Managers

(NSX-T 3.2.1 and later) Only supported if you choose the Migrate NSX for vSphere mode and User Defined Topology.

(NSX-T 3.2.0) Migration of a single site NSX-V 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-V deployment is migrated to a single site NSX-T environment (non-federated) with local objects. Migration of a 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-V with a Cloud Management Platform, Integrated Stack Solution, or PaaS Solution

Yes

Migration of NSX-V with vRealize Automation is supported.

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

For example:

  • NSX-V and vCloud Director

  • NSX-V with Integrated Stack Solution

  • NSX-V with PaaS Solution such as Pivotal Cloud Foundry, RedHat OpenShift

  • NSX-V 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-V 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

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-V passphrase to match the NSX-T 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.

Certificate changes during migration

(NSX-T 3.2.0) No

(NSX-T 3.2.1 and later) Yes

(NSX-T 3.2.1 and later) Certificate changes are supported when the migration is paused for all migration modes except migrating vSphere networking. Not supported when hosts and workloads are being migrated.

Operations

Details

Supported

Notes

Discovery protocol CDP

See notes.

 Yes if migrating to VDS 7.0. No if migrating to N-VDS.

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 for in-place migration

No for lift-and-shift migration

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

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-V 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-V transport zones using multicast or hybrid replication mode

No

NSX-V transport zones using unicast replication mode

Yes

NSX Edge Features

NSX-V Configuration

Supported

Details

Routing between Edge Service Gateway and northbound router

Yes

BGP is supported.

Static routes are supported.

OSPF is supported.

Routing between Edge Services Gateway and Distributed Logical Router

Yes

Routes are converted to static routes after migration.

Load balancer

Yes

See Migration Modes for details.

VLAN-backed Micro-Segmentation environment

Yes

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. You can configure syslog and NTP manually on the NSX-T edge nodes.

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 Change the Global MTU Setting 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-V API: GatewayPolicy/action

NSX-T API: SecurityPolicy.action

Firewall Global Configuration

No

Default timeouts are used

Firewall Rule

Yes

NSX-V API: firewallRule

NSX-T API: SecurityPolicy

Firewall Rule: name

Yes

Firewall Rule: rule tag

Yes

NSX-V API: ruleTag

NSX-T API: Rule_tag

Sources and destinations in firewall rules:

  • Grouping objects

  • IP addresses

Yes

NSX-V API:

  • source/groupingObjectId

  • source/ipAddress

NSX-T API:

  • source_groups

NSX-V 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-V 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-V API: logging

NSX-T API: logged

Firewall Rule: Description

Yes

Both APIs: description

Edge NAT

NSX-V Configuration

Supported

Details

NAT rule

Yes

NSX-V API: natRule

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

NAT rule: rule tag

Yes

NSX-V API: ruleTag

NSX-T API: rule_tag

NAT rule: action

Yes

NSX-V API: action

NSX-T API: action

NAT rule: original address (Source address for SNAT

rules, and the destination address for DNAT rules.)

Yes

NSX-V API: originalAddress

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

NAT rule: translatedAddress

Yes

NSX-V 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-V API: loggingEnabled

NSX-T API: logging

NAT rule: enabled

Yes

NSX-V API: enabled

NSX-T API: disabled

NAT rule: description

Yes

NSX-V API: description

NSX-T API: description

NAT rule: protocol

Yes

NSX-V API: protocol

NSX-T API: Service

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

Yes

NSX-V API: originalPort

NSX-T API: Service

NAT rule: translated port

Yes

NSX-V API: translatedPort

NSX-T API: Translated_ports

NAT rule: Source address in DNAT rule

Yes

NSX-V API: dnatMatchSourceAddress

NSX-T API: source_network

NAT rule:

Destination address in SNAT rule

Yes

NSX-V API: snatMatchDestinationAddress

NSX-T API: destination_network

NAT rule:

Source port in DNAT rule

Yes

NSX-V API: dnatMatchSourcePort

NSX-T API: Service

NAT rule:

Destination port in SNAT rule

Yes

NSX-V API: snatMatchDestinationPort

NSX-T API: Service

NAT rule: rule ID

Yes

NSX-V 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-V 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-V 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-V dpdelay maps to NSX-T dpdinternal.

Overlapping local and peer subnets of two or more sessions.

No

NSX-V 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

The following table applies to migrating NSX-V load balancer to NSX-T load balancer (NLB) or NSX-T Advanced Load Balancer (ALB). For information about migrating NSX-V load balancer to ALB, see Migrating NSX-V Load Balancer to Advanced Load Balancer.

NSX-V Configuration

Supported

Details

Monitor / health-checks for:

  • LDAP

  • DNS

  • MSSQL

See details.

(NLB) The monitors are not migrated.

(ALB) LDAP and MSSQL monitors are not migrated. DNS monitor is migrated if ALB has an enterprise license, but not if it has a basic license.

Application rules

No

NSX-V 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

(NLB) No

(ALB) Yes

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

See details.

(NLB) Pools with these algorithms are not migrated.

(ALB) Supported if ALB has an enterprise license. With a basic license, you will be provided feedback to select a different algorithm.

Isolated pool

No

LB pool member with different monitor port

See details.

(NLB) The pool member which has a different monitor port is not migrated.

(ALB) The pool member is migrated but will not be in the monitor port configuration.

Pool member minConn

No

Monitor extension

No

SSL sessionID persistence / table

(NLB) No

(ALB) Yes

MSRDP persistence / session table

No

Cookie app session / session table

(NLB) No

(ALB) Yes

App persistence

(NLB) No

(ALB) Yes

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-V 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 Firewall

Yes

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

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

Yes if the NSX-V deployment has an NSX Manager in primary mode and no secondary NSX Managers.

Rule – Source / Destination:

  • VMs not on NSX-V hosts

 No NSX-T does not support referencing objects not connected to NSX-T portgroups or networks. Those objects will be lost from the source or destination when migration is completed. To avoid this issue use IP addresses in NSX-V to reference those objects before migration.

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

No

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.

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, you will be prompted to map each NSX-V 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.

A service chain in NSX-T will be created for each service profile in NSX-V. 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-V 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-V has more than 1000 rules, the rules will be migrated in multiple sections of 1000 rules each. For example, if a section contains 2500 rules, three policies will be created: Policy 1 with 1000 rules, Policy 2 with 1000 rules, and Policy 3 with 500 rules.

Stateful or stateless firewall rules in NSX-V are 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-V.

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-V 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-V 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).

Enable/Disable Rule

Yes
Service Segment
A service segment will be created in the overlay transport zone that you select in the Resolve Configuration step of the migration. In the NSX-V environment, if the VXLAN transport zone is not prepared with NSX-V, you have 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-V, you must select any one overlay transport zone to create the service segment in NSX-T.
Service Profile Priority
In NSX-V, 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 rules with a higher profile priority will be placed 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.
Service Precedence

To redirect traffic to multiple services, NSX-V 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.

Redirection of traffic on a vNIC to multiple partner services is not supported. Redirection to only a single partner service is supported. Although, all the NSX-V 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 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 as Groups. See Inventory > Groups in the NSX-T Manager web interface.

NSX-V 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-V 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-V 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-V does not limit the number of dynamic criteria, dynamic sets, and you can have any combinations of AND and OR.

In NSX-T, you can have a group with five expressions. NSX-V 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-V).

  • 1 dynamic set containing 5 dynamic criteria related with OR (Any in NSX-V).

  • 1 dynamic set containing 5 dynamic criteria related with AND (All in NSX-V). 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-V, 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.

Security tags that are not applied to any VM are not migrated.

Services and Service Groups are migrated to NSX-T 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-V layer 2 Services are migrated as NSX-T Service Entry EtherTypeServiceEntry.

Layer 3 Services

Yes

Based on the protocol, NSX-V 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-V 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 skip the migration of Service Composer policies by skipping the relevant Distributed Firewall sections. Alternatively, you can roll back 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