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 VMware vCenter.
NSX-V Configuration |
Supported |
Details |
---|---|---|
NSX-V with vSAN or iSCSI on vSphere Distributed Switch |
Yes |
|
Pre-existing NSX configuration |
No |
You must deploy a new NSX environment. If the migration mode is not for a user-defined topology, during the Import Configuration step, all NSX Edge node interfaces in the NSX environment are shut down. If the NSX environment is in use, this will interrupt traffic. |
Cross-vCenter NSX |
Yes |
Only supported if you choose the Migrate NSX for vSphere mode and User Defined Topology. |
NSX-V with a Cloud Management Platform, Integrated Stack Solution, or PaaS Solution |
Yes |
Migration of NSX-V with Aria Automation is supported. Contact your VMware representative before proceeding with migration. Scripts and integrations might break if you migrate the integrated environments:
For example:
|
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. |
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 requirements. It must be at least 8 characters long and contain the following:
|
FIPS |
No |
FIPS on/off not supported by NSX. |
Locale |
No |
NSX 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 |
Yes |
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. Only the Advertise mode can be modified. |
PortMirroring:
|
Yes |
Only L3 session type is supported for migration |
PortMirroring:
|
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:
|
Yes |
Supported options for load balancing (teaming policy):
Other load balancing options are not supported. |
Teaming and Failover:
|
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 for migration:
|
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 |
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
For full details on supported topologies, see Supported Topologies.
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 |
|
VLAN-backed Micro-Segmentation environment |
Yes |
See Supported Topologies for details. |
NAT64 |
No |
Not supported in NSX. |
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 edge nodes. |
IPv6 |
No |
|
Unicast Reverse Path Filter (URPF) configuration for Edge Services Gateway interfaces |
No |
URPF on NSX 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. |
IP Multicast routing |
No |
|
Route Redistribution Prefix Filters |
No |
|
Default originate |
No |
Not supported in NSX. |
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 API: SecurityPolicy.action |
Firewall Global Configuration |
No |
Default timeouts are used |
Firewall Rule |
Yes |
NSX-V API: firewallRule NSX API: SecurityPolicy |
Firewall Rule: name |
Yes |
|
Firewall Rule: rule tag |
Yes |
NSX-V API: ruleTag NSX API: Rule_tag |
Sources and destinations in firewall rules:
|
Yes |
NSX-V API:
NSX API:
NSX-V API:
NSX API:
|
Firewall rule sources and destinations:
|
No |
|
Services (applications) in firewall rules:
|
Yes |
NSX-V API:
NSX API:
|
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 API: logged |
Firewall Rule: Description |
Yes |
Both APIs: description |
Edge NAT
NSX-V Configuration |
Supported |
Details |
---|---|---|
NAT rule |
Yes |
NSX-V API: natRule NSX API: /nat/USER/nat-rules |
NAT rule: rule tag |
Yes |
NSX-V API: ruleTag NSX API: rule_tag |
NAT rule: action |
Yes |
NSX-V API: action NSX API: action |
NAT rule: original address (Source address for SNAT rules, and the destination address for DNAT rules.) |
Yes |
NSX-V API: originalAddress NSX API: source_network for SNAT rule or destination_network for DNAT rule |
NAT rule: translatedAddress |
Yes |
NSX-V API: translatedAddress NSX 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 API: logging |
NAT rule: enabled |
Yes |
NSX-V API: enabled NSX API: disabled |
NAT rule: description |
Yes |
NSX-V API: description NSX API: description |
NAT rule: protocol |
Yes |
NSX-V API: protocol NSX API: Service |
NAT rule: original port (source port for SNAT rules, destination port for DNAT rules) |
Yes |
NSX-V API: originalPort NSX API: Service |
NAT rule: translated port |
Yes |
NSX-V API: translatedPort NSX API: Translated_ports |
NAT rule: Source address in DNAT rule |
Yes |
NSX-V API: dnatMatchSourceAddress NSX API: source_network |
NAT rule: Destination address in SNAT rule |
Yes |
NSX-V API: snatMatchDestinationAddress NSX API: destination_network |
NAT rule: Source port in DNAT rule |
Yes |
NSX-V API: dnatMatchSourcePort NSX API: Service |
NAT rule: Destination port in SNAT rule |
Yes |
NSX-V API: snatMatchDestinationPort NSX API: Service |
NAT rule: rule ID |
Yes |
NSX-V API: ruleID NSX 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. 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:
|
No |
In NSX, dpdaction is set to “restart” and cannot be changed. If NSX-V setting for dpdtimeout is set to 0, dpd is disabled in NSX. Otherwise, any dpdtimeout settings are ignored and the default value is used. |
Changed Dead Peer Detection (dpd) default values for:
|
Yes |
NSX-V dpdelay maps to NSX 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. 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 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 and changes to them are not migrated. |
Load Balancer
NSX-V Configuration |
Supported |
Details |
---|---|---|
Monitor / health-checks for:
|
See details. |
The monitors are not migrated. |
Application rules |
No |
NSX-V uses application rules based on HAProxy to support L7. In NSX, 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 |
See details. |
Pools with these algorithms are not migrated. |
Isolated pool |
No |
|
LB pool member with different monitor port |
See details. |
The pool member which has a different monitor port is not migrated. |
Pool member minConn |
No |
|
Monitor extension |
No |
|
SSL sessionID persistence / table |
No |
|
MSRDP persistence / session table |
No |
|
Cookie app session / session table |
No |
|
App persistence |
No |
|
Monitor for:
|
No |
|
Monitor for:
|
Yes |
|
Haproxy Tuning/IPVS Tuning |
No |
|
Pool IP filter
|
Yes |
IPv4 IP addresses are supported. If Any is used, only the IPv4 addresses of the IP pool are migrated. |
Pool IP Filter
|
No |
|
Pool containing unsupported grouping object:
|
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
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 |
NSX-V Configuration |
Supported |
Details |
---|---|---|
IP Pools |
Yes |
|
Static bindings |
Yes |
|
DHCP leases |
Yes |
|
General DHCP options |
Yes |
|
Disabled DHCP service |
No |
In NSX 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 does not support DHCP service on a centralized service port, so the DHCP service configuration is not migrated for these interfaces. |
NSX-V Configuration |
Supported |
Details |
---|---|---|
DNS views |
Yes |
Only the first dnsView is migrated to the NSX 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 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 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 -
|
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:
|
Yes |
|
Rule – Source / Destination:
|
Yes |
maps to Security Group |
Rule – Source / Destination:
|
No |
|
Rule – Source / Destination:
|
Yes if the NSX-V deployment has an NSX Manager in primary mode and no secondary NSX Managers. |
|
Rule – Applied To:
|
Yes |
maps to Distributed Firewall |
Rule – Applied To:
|
Yes |
maps to Security Group |
Rule – Applied To:
|
No |
|
Rule – Applied To:
|
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, 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 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 before migration. |
Vendor Template |
No |
Vendor template is not migrated. Partner must register the vendor template with NSX 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 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 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. For east-west Network Introspection service in NSX, partner service VMs must be deployed on an overlay segment. |
Section
|
Yes |
A section maps to a redirection policy. ID is user-defined, and not auto-generated in NSX. 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. |
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
|
Yes |
|
Services/Service Groups |
Yes |
For details, see the Services and Service Groups table. |
Advanced Settings
|
Yes |
|
Service Profile and Action
|
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. Applied To field accepts only Groups, and this field determines the scope of the rule. In NSX, 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 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:
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 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.
- 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, 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 rule table. For a detailed example, see scenario 2 in Order of Migrated Network Introspection Rules in NSX.
- 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, only a single DVFilter slot is used and it redirects traffic to a service chain. After migration to NSX, 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.
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, 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 segment.
Grouping Objects and Service Composer
IP Sets and MAC Sets are migrated to NSX as groups. See in the NSX Manager web interface.
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 as Groups. See in the NSX Manager web interface.
NSX-V has system-defined and user-defined Security Groups. These are all migrated to NSX 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 after migration.
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 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):
|
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):
|
Yes |
Security groups, IP sets, and MAC sets are migrated to NSX 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, the parent security group does not migrate to NSX. For example, an IP set with more than 2 million members cannot migrate to NSX. 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):
|
Yes |
If a security group contains logical switches that do not migrate to NSX segments, the security group does not migrate to NSX. |
Security Group Member Types (Static or Entity Belongs To):
|
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):
|
Yes |
|
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:
|
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:
NSX-V does not limit the number of dynamic criteria, dynamic sets, and you can have any combinations of AND and OR. In NSX, 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:
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 security tags are attributes of a VM.
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 as Services. See in the NSX Manager web interface.
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 Services. If any Service or Service Group is not present in NSX, a new Service is created in NSX. |
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 for a modified Service or Service Group a new Service is created in NSX 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 does not support empty Services. |
Layer 2 Services |
Yes |
NSX-V layer 2 Services are migrated as NSX Service Entry EtherTypeServiceEntry. |
Layer 3 Services |
Yes |
Based on the protocol, NSX-V layer 3 Services are migrated to NSX Service Entry as follows:
ICMPTypeServiceEntry
|
Layer 4 Services |
Yes |
Migrated as NSX Service Entry ALGTypeServiceEntry. |
Layer 7 Services |
Yes |
Migrated as NSX Service Entry PolicyContextProfile If an NSX-V Layer 7 application has a port and protocol defined, a Service is created in NSX 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 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. |
NSX-V Configuration |
Supported |
Details |
---|---|---|
Service Composer Security Policies |
Yes |
Firewall rules defined in a Security Policy are migrated to NSX 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 |