Platform Support

See the VMware Interoperability Matrix for supported versions of ESXi and vCenter Server: http://partnerweb.vmware.com/comp_guide2/sim/interop_matrix.php#interop&175=&1=&2=.

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

No

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

No

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

For example:

  • NSX Data Center for vSphere and vRealize Automation

  • 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

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

No

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 work-around.

VXLAN port number other than 4789

No

Multicast Filtering Mode

No

Hosts with multiple VTEPs

No

Hosts can have only one VTEP interface configured. That is, only one interface with TCP/IP stack vxlan per host is supported for migration.

NSX Manager Appliance System Configuration

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

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

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

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

Only Lag with VLAN configuration is not 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

Switch Security and IP Discovery

Configuration

Supported

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

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.

Configuration

Supported

Details

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

Yes

BGP is supported.

Static routes are supported.

OSFP 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

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

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

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

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

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

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

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

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

Configuration

Supported

Details

Identity-based Firewall

No

Section -

  • Display name

  • Description

  • Tcp_strict

  • Stateless

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

No

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

  • Universal Logical Switch

No

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

  • Universal Logical Switch

No

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.

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

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 for vSphere. 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

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

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

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

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 not migrated.

If the Service Composer status is not in sync, the Resolve Configuration step warns of this.

You can either skip the migration of Service Composer policies by skipping the relevant Distributed Firewall sections. Or 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