Detaillierte Funktionsunterstützung für Migration

NSX-V-Funktionen und Konfigurationen, die migriert werden können, werden nachfolgend aufgeführt.

Plattformunterstützung

Weitere Informationen finden Sie in der VMware-Interoperabilitätsmatrix für unterstützte Versionen von ESXi und vCenter Server.

NSX-V-Konfiguration	Unterstützt	Details
NSX-V mit vSAN oder iSCSI auf vSphere Distributed Switch	Ja
Bereits vorhandene NSX-T-Konfiguration	Nein	Sie müssen eine neue NSX-T-Umgebung bereitstellen. Wenn der Migrationsmodus nicht für eine benutzerdefinierte Topologie gilt, werden während des Schritts Konfiguration importieren alle NSX-T Edge-Knotenschnittstellen in der NSX-T-Umgebung heruntergefahren. Wenn die NSX-T-Umgebung verwendet wird, wird der Datenverkehr dadurch unterbrochen.
Cross-vCenter NSX	(NSX-T 3.2.1 und höher) Ja (NSX-T 3.2.0) Ja, aber ohne sekundäre NSX Manager	(NSX-T 3.2.1 und höher) Wird nur unterstützt, wenn Sie den Modus NSX for vSphere migrieren und Benutzerdefinierte Topologie auswählen. (NSX-T 3.2.0) Die Migration einer NSX-V-Bereitstellung auf einer einzelnen Site, die einen NSX Manager im primären Modus, keine sekundären NSX Manager und mit universellen Objekten auf der primären Site enthält, wird unterstützt. Eine solche NSX-V-Bereitstellung auf einer einzelnen Site wird auf eine NSX-T-Umgebung auf einer einzelnen Site (nicht im Verbund) mit lokalen Objekten migriert. Die Migration einer Cross-vCenter NSX-V-Bereitstellung mit einem primären NSX Manager und mehreren sekundären NSX Manager-Instanzen wird nicht unterstützt. Migrationskoordinator migriert nur von einem NSX-V Manager mit der Rolle „Primär“ oder „Eigenständig“. Sie können die NSX-V-Umgebung ändern, indem Sie den Status der sekundären Manager ändern, um jede einzelne NSX-V-Umgebung unabhängig voneinander zu migrieren.
VCF-Arbeitslastdomänen	(NSX-T 3.2.1 und höher) Ja
NSX-V mit einer Cloud Management-Plattform, einer Integrated Stack- oder PaaS-Lösung.	Ja	Die Migration von NSX-V mit vRealize Automation wird unterstützt. Wenden Sie sich an Ihren VMware-Vertreter, bevor Sie mit der Migration fortfahren. Skripts und Integrationen werden bei der Migration der integrierten Umgebungen unter Umständen abgebrochen: Beispiel: NSX-V und vCloud Director NSX-V mit Integrated Stack-Lösung NSX-V mit PaaS-Lösung wie Pivotal Cloud Foundry, RedHat OpenShift NSX-V mit vRealize Operations-Workflows

vSphere- und ESXi-Funktionen

NSX-V-Konfiguration	Unterstützt	Details
ESXi-Host befindet sich bereits im Wartungsmodus (keine VMs)	Ja
Network I/O Control (NIOC) Version 3	Ja
Network I/O Control (NIOC) Version 2	Nein
Network I/O Control (NIOC) mit vNIC mit Reservierung	Nein
vSphere Standard-Switch	Nein	VMs und VMkernel-Schnittstellen auf VSS werden nicht migriert. NSX-V-Funktionen, die auf den VSS angewendet werden, können nicht migriert werden.
vSphere Distributed Switch	Ja
ESXi statusfrei	Nein
Hostprofile	Nein
ESXi-Sperrmodus	Nein	Wird in NSX-T nicht unterstützt.
Wartungsmodusaufgabe des ESXi-Hosts ausstehend.	Nein
Getrennter ESXi-Host im vCenter-Cluster	Nein
vSphere FT	Nein
vSphere DRS vollständig automatisiert	Ja	Unterstützt ab vSphere 7.0
vSphere High Availability	Ja
Zugriffskontrollliste für Datenverkehrsfilterung	Nein
vSphere-Systemdiagnose	Nein
SRIOV	Nein
vmknic an physische Netzwerkkarte anheften	Nein
Privates VLAN	Nein
Flüchtige dvPortGroup	Nein
DirectPath IO	Nein
L2-Sicherheit	Nein
Switch auf virtuellem Kabel erlernen	Nein
Hardware-Gateway (Tunnel-Endpoint-Integration mit physischer Switching-Hardware)	Nein
SNMP	Nein
Getrennte vNIC in VM	Nein	Aufgrund der ESX 6.5-Einschränkung können veraltete Einträge in DVFilter für getrennte VMs vorhanden sein. Starten Sie zur Problemumgehung die VM neu.
Andere VXLAN-Portnummer als 4789	Nein
Multicast-Filtermodus	Nein
Hosts mit mehreren VTEPs	Ja

Systemkonfiguration der NSX Manager-Appliance

NSX-V-Konfiguration	Unterstützt	Details
NTP-Server/Zeiteinstellung	Ja
Syslog-Serverkonfiguration	Ja
Konfiguration sichern	Ja	Ändern Sie bei Bedarf die NSX-V Passphrase entsprechend den NSX-T Anforderungen. Sie muss mindestens 8 Zeichen lang sein und Folgendes enthalten: Mindestens ein Kleinbuchstabe Mindestens ein Großbuchstabe Mindestens ein numerisches Zeichen mindestens ein Sonderzeichen
FIPS	Nein	FIPS ein/aus wird von NSX-T nicht unterstützt.
Gebietsschema	Nein	NSX-T unterstützt nur das englische Gebietsschema
Appliance-Zertifikat	Nein

Rollenbasierte Zugriffssteuerung

NSX-V-Konfiguration	Unterstützt	Details
Lokale Benutzer	Nein
NSX-Rollen, die einem vCenter-Benutzer, der über LDAP hinzugefügt wurde, zugewiesen werden	Ja	VMware Identity Manager muss installiert und konfiguriert sein, um Benutzerrollen für LDAP-Benutzer zu migrieren.
Einer vCenter-Gruppe zugewiesene NSX-Rollen	Nein

Zertifikate

NSX-V-Konfiguration	Unterstützt	Details
Zertifikate (Server, von Zertifizierungsstelle signiert)	Ja	Dies gilt nur für Zertifikate, die nur über Truststore-APIs hinzugefügt werden.
Zertifikatsänderungen während der Migration	(NSX-T 3.2.0) Nein (NSX-T 3.2.1 und höher) Ja	(NSX-T 3.2.1 und höher) Zertifikatsänderungen werden unterstützt, wenn die Migration für alle Migrationsmodi außer der Migration des vSphere-Netzwerks angehalten wird. Wird nicht unterstützt, wenn Hosts und Arbeitslasten migriert werden.

Betrieb

Details	Unterstützt	Anmerkungen
Discovery-Protokoll CDP	Siehe Hinweise.	Ja, wenn Sie zu VDS 7.0 migrieren. Nein, wenn Sie zu N-VDS migrieren.
Discovery-Protokoll LLDP	Ja	Der Überwachungsmodus ist standardmäßig aktiviert und kann in NSX-T nicht geändert werden. Es kann nur der Advertise-Modus geändert werden.
PortMirroring: Gekapselte Remotespiegelungsquelle (L3)	Ja	Nur L3-Sitzungstyp wird für die Migration unterstützt
PortMirroring: Verteiltes PortMirroring Remotespiegelungsquelle Remotespiegelungsziel Mirroring verteilter Ports (Legacy)	Nein
L2-IPFIX	Ja	LAG mit IPFIX wird nicht unterstützt
Verteilte Firewall und IPFIX	Nein
MAC Learning	Ja	Sie müssen gefälschte Übertragungen aktivieren (akzeptieren).
Hardware-VTEP	Nein
Promiskuitiver Modus	Nein
Ressourcenzuteilung	Nein	vNIC mit aktivierter Ressourcenzuteilung wird nicht unterstützt
IPFIX – Interne Flows	Nein	IPFIX mit InternalFlows wird nicht unterstützt

Switch

NSX-V-Konfiguration	Unterstützt	Details
L2-Bridging	Nein
Trunk-VLAN	Ja für direkte Migration Nein für Lift-and-Shift-Migration	Trunk-Uplink-Portgruppen muss mit einem VLAN-Bereich von 0–4094 konfiguriert werden.
VLAN-Konfiguration	Ja	Die Konfiguration nur mit VLAN (kein VXLAN) wird unterstützt.
Teaming und Failover: Load Balancing Uplink-Failover-Reihenfolge	Ja	Unterstützte Load Balancing-Optionen (Teaming-Richtlinie): Ausdrückliche Failover-Reihenfolge verwenden Anhand des Quell-MAC-Hashs routen Andere Load Balancing-Optionen werden nicht unterstützt.
Teaming und Failover: Netzwerkausfallerkennung Switches benachrichtigen Umkehrrichtlinie Fortlaufende Reihenfolge	Nein
LACP	Ja	Für VDS 7.0 und höher wird die LACP-Funktionalität während der Migration nicht geändert. Bei früheren Versionen von VDS ersetzt ein neuer N-VDS-Switch den VDS. Dies führt während der Hostmigration zu einem Verlust des Datenverkehrs. IPFIX auf DVS (nicht DFW IPFIX) wird mit LACP nicht unterstützt

Switch-Sicherheit und IP Discovery

NSX-V-Konfiguration	Für die Migration unterstützt	Details
IP Discovery (ARP, ND, DHCPv4 und DHCPv6)	Ja	Die folgenden Bindungsgrenzwerte gelten für NSX-T für die Migration: 128 für per ARP erkannte IPs 128 für per DHCPv4 erkannte IPs 15 für per DHCPv6 erkannte IPs 15 für per ND erkannte IPs
SpoofGuard (manuell, TOFU, deaktiviert)	Ja
Switch-Sicherheit (BPDU-Filter, DHCP-Clientblock, DHCP-Serverblock, RA-Guard)	Ja
Migrieren von Datenpfadbindungen vom Switch-Sicherheitsmodul in NSX-V zum Switch-Sicherheitsmodul in NSX-T	Ja	Wenn SpoofGuard aktiviert ist, werden Bindungen aus dem Switch-Sicherheitsmodul migriert, um die ARP-Unterdrückung zu unterstützen. VSIP – Switch-Sicherheit wird nicht unterstützt, da VSIP-Bindungen als statisch konfigurierte Regeln migriert werden.
Ermittlungsprofile	Ja	Die ipdiscovery-Profile werden nach der Migration mithilfe der IP Discovery-Konfiguration für den logischen Switch und der globalen und Cluster-ARP- und DHCP-Konfiguration erstellt.

Zentrale Control Plane

NSX-V-Konfiguration	Unterstützt	Details
VTEP-Replikation pro logischem Switch (VNI) und Routing-Domäne	Ja
MAC/IP-Replikation	Nein
NSX-V-Transportzonen mit Multicast- oder Hybrid-Replikationsmodus	Nein
NSX-V-Transportzonen mit Unicast-Replikationsmodus	Ja

Funktionen von NSX Edge

NSX-V-Konfiguration	Unterstützt	Details
Routing zwischen Edge Service Gateway und Northbound Router	Ja	BGP wird unterstützt. Statische Routen werden unterstützt. OSPF wird unterstützt.
Routing zwischen Edge Services Gateway und Distributed Logical Router	Ja	Routen werden nach der Migration in statische Routen umgewandelt.
Load Balancer	Ja	Einzelheiten dazu finden Sie unter Migrationsmodi.
VLAN-gestützte Mikrosegmentierungs-Umgebung	Ja
NAT64	Nein	Wird in NSX-T nicht unterstützt.
Einstellungen auf Knotenebene auf einem Edge Services Gateway oder einem Distributed Logical Router	Nein	Einstellungen auf Knotenebene, z. B. syslog oder NTP-Server, werden nicht unterstützt. Sie können Syslog und NTP manuell auf den NSX-T Edge-Knoten konfigurieren.
IPv6	Nein
Konfiguration für umgekehrten Unicast-Pfadfilter (URPF) für Edge Services Gateway-Schnittstellen	Nein	URPF auf NSX-T-Gateway-Schnittstellen ist auf „Streng“ festgelegt.
Konfiguration der maximalen Übertragungseinheit (MTU) für Edge Services Gateway-Schnittstellen	Nein	Informationen zum Ändern der Standard-MTU auf NSX-T finden Sie unter Ändern der globalen MTU-Einstellung.
IP-Multicast-Routing	Nein
Präfixfilter für Route Redistribution	Nein
Default Originate	Nein	Wird in NSX-T nicht unterstützt.

Edge-Firewall

NSX-V-Konfiguration	Unterstützt	Details
Abschnitt "Firewall": Anzeigename	Ja	Firewallabschnitte können maximal 1000 Regel aufweisen. Wenn ein Abschnitt mehr als 1000 Regeln enthält, wird er als mehrere Abschnitte migriert.
Aktion für Standardregel	Ja	NSX-V-API: GatewayPolicy/action NSX-T-API: SecurityPolicy.action
Globale Firewallkonfiguration	Nein	Standard-Zeitüberschreitungen werden verwendet
Firewallregel	Ja	NSX-V-API: firewallRule NSX-T-API: SecurityPolicy
Firewallregel: Name	Ja
Firewallregel: Regel-Tag	Ja	NSX-V-API: ruleTag NSX-T-API: Rule_tag
Quellen und Ziele in Firewallregeln: Objekte werden gruppiert IP-Adressen	Ja	NSX-V-API: source/groupingObjectId source/ipAddress NSX-T-API: source_groups NSX-V-API: destination/groupingObjectId destination/ipAddress NSX-T-API: destination_groups
Firewallregelquellen und -ziele: vNIC-Gruppe	Nein
Dienste (Anwendungen) in Firewallregeln: Dienst Dienstgruppe Protokoll/Port/Quellport	Ja	NSX-V-API: application/applicationId application/service/protocol application/service/port application/service/sourcePort NSX-T-API: Dienste
Firewallregel: Übersetzung zuordnen	Nein	Übersetzungszuordnung muss „false“ sein.
Firewallregel: Richtung	Ja	Beide APIs: direction
Firewallregel: Aktion	Ja	Beide APIs: action
Firewallregel: Aktiviert	Ja	Beide APIs: enabled
Firewallregel: Protokollierung	Ja	NSX-V-API: Protokollierung NSX-T-API: protokolliert
Firewallregel: Beschreibung	Ja	Beide APIs: description

Edge-NAT

NSX-V-Konfiguration	Unterstützt	Details
NAT-Regel	Ja	NSX-V-API: natRule NSX-T-API: /nat/USER/nat-rules
NAT-Regel: Regel-Tag	Ja	NSX-V-API: ruleTag NSX-T-API: rule_tag
NAT-Regel: Aktion	Ja	NSX-V-API: Aktion NSX-T-API: Aktion
NAT-Regel: ursprüngliche Adresse (Quelladresse für SNAT- Regeln und die Zieladresse für DNAT-Regeln.)	Ja	NSX-V-API: originalAddress NSX-T-API: source_network für SNAT-Regel oder destination_network für DNAT-Regel
NAT-Regel: translatedAddress	Ja	NSX-V-API: translatedAddress NSX-T-API: translated_network
NAT-Regel: Anwenden einer NAT-Regel auf eine bestimmte Schnittstelle	Nein	„Angewendet auf“ muss „Alle“ sein.
NAT-Regel: Protokollierung	Ja	NSX-V-API: loggingEnabled NSX-T-API: Protokollierung
NAT-Regel: aktiviert	Ja	NSX-V-API: aktiviert NSX-T-API: deaktiviert
NAT-Regel: Beschreibung	Ja	NSX-V-API: Beschreibung NSX-T-API: Beschreibung
NAT-Regel: Protokoll	Ja	NSX-V-API: Protokoll NSX-T-API: Dienst
NAT-Regel: ursprünglicher Port (Quellport für SNAT-Regeln, Zielport für DNAT-Regeln)	Ja	NSX-V-API: originalPort NSX-T-API: Dienst
NAT-Regel: übersetzter Port	Ja	NSX-V-API: translatedPort NSX-T-API: Translated_ports
NAT-Regel: Quelladresse in DNAT-Regel	Ja	NSX-V-API: dnatMatchSourceAddress NSX-T-API: source_network
NAT-Regel: Zieladresse in SNAT-Regel	Ja	NSX-V-API: snatMatchDestinationAddress NSX-T-API: destination_network
NAT-Regel: Quellport in DNAT-Regel	Ja	NSX-V-API: dnatMatchSourcePort NSX-T-API: Dienst
NAT-Regel: Zielport in SNAT-Regel	Ja	NSX-V-API: snatMatchDestinationPort NSX-T-API: Dienst
NAT-Regel: Regel-ID	Ja	NSX-V-API: ruleID NSX-T-API: ID und display_name

L2 VPN

NSX-V-Konfiguration	Unterstützt	Details
L2VPN-Konfiguration basierend auf IPSec mithilfe von Pre-Shared Key (PSK)	Ja	Wird unterstützt, wenn das Netzwerk, das über L2VPN ausgedehnt wird, ein logischer Overlay-Switch ist. Wird nicht für VLAN-Netzwerke unterstützt.
L2VPN-Konfiguration basierend auf IPSec mithilfe der zertifikatbasierten Authentifizierung	Nein
L2VPN-Konfiguration basierend auf SSL	Nein
L2VPN-Konfigurationen mit lokalen Egress-Optimierungen	Nein
L2VPN-Clientmodus	Nein

L3VPN

NSX-V-Konfiguration	Unterstützt	Details
Erkennung inaktiver Peers	Ja	Die Erkennung inaktiver Peers unterstützt verschiedene Optionen für NSX-V und NSX-T. Möglicherweise sollten Sie die Verwendung von BGP für eine schnellere Konvergenz erwägen oder einen Peer so konfigurieren, dass er DPD ausführt, sofern dies unterstützt wird.
Die Standardwerte für die Erkennung inaktiver Peers (Dead Peer Detection, DPD) wurden geändert für: dpdtimeout dpdaction	Nein	In NSX-T ist dpdaction auf „restart“ festgelegt und kann nicht geändert werden. Wenn die NSX-V-Einstellung für dpdtimeout auf 0 gesetzt ist, ist DPD in NSX-T deaktiviert. Andernfalls werden die dpdtimeout-Einstellungen ignoriert und der Standardwert wird verwendet.
Die Standardwerte für die Erkennung inaktiver Peers (Dead Peer Detection, DPD) wurden geändert für: dpddelay	Ja	NSX-V dpdelay wird NSX-T dpdinternal zugeordnet.
Überlappende lokale und Peer-Subnetze von zwei oder mehr Sitzungen.	Nein	NSX-V unterstützt richtlinienbasierte IPSec-VPN-Sitzungen, in denen lokale und Peer-Subnetze von zwei oder mehr Sitzungen miteinander überlappen. Dieses Verhalten wird in NSX-T nicht unterstützt. Sie müssen die Subnetze vor dem Start der Migration neu konfigurieren, damit sie sich nicht überlappen. Wenn dieses Konfigurationsproblem nicht behoben wird, schlägt der Schritt „Konfiguration migrieren“ fehl.
IPsec-Sitzungen mit Peer-Endpoint als „Alle“ festgelegt.	Nein	Konfiguration wird nicht migriert.
Änderungen an der Erweiterung securelocaltrafficbyip.	Nein	Der NSX-T-Dienstrouter verfügt über keinen lokalen generierten Datenverkehr, der über den Tunnel gesendet werden muss.
Änderungen an diesen Erweiterungen: 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	Nein	Diese Erweiterungen werden von NSX-T nicht unterstützt und Änderungen an ihnen werden nicht migriert.

Load Balancer

Die folgende Tabelle gilt für die Migration des NSX-V-Load Balancers zu NSX-T Load Balancer (NLB) oder NSX-T Advanced Load Balancer (ALB). Informationen zum Migrieren des NSX-V-Load Balancers zu ALB finden Sie unter Migrieren von NSX-V-Load Balancer zu Advanced Load Balancer.

NSX-V-Konfiguration	Unterstützt	Details
Überwachung/Integritätsprüfungen für: LDAP DNS MSSQL	Siehe Details.	(NLB) Die Monitore werden nicht migriert. (ALB) LDAP- und MSSQL-Monitore werden nicht migriert. Die DNS-Überwachung wird migriert, wenn ALB über eine Enterprise-Lizenz verfügt, jedoch nicht, wenn sie über eine Standardlizenz verfügt.
Anwendungsregeln	Nein	NSX-V verwendet Anwendungsregeln auf Basis von HAProxy zur Unterstützung von L7. In NSX-T basieren die Regeln auf NGINX. Die Anwendungsregeln können nicht migriert werden. Nach der Migration müssen Sie neue Regeln erstellen.
Portbereich des virtuellen L7-Servers	(NLB) Nein (ALB) Ja
IPv6	Nein	Wenn IPv6 in einem virtuellen Server verwendet wird, wird der gesamte virtuelle Server ignoriert. Wenn IPv6 im Pool verwendet wird, wird der Pool migriert, aber das zugehörige Poolmitglied entfernt.
URL-, URI-, HTTPHEADER-Algorithmen	Siehe Details.	(NLB) Pools mit diesen Algorithmen werden nicht migriert. (ALB) Wird unterstützt, wenn ALB über eine Enterprise-Lizenz verfügt. Mit einer Standardlizenz erhalten Sie Feedback zur Auswahl eines anderen Algorithmus.
Isolierter Pool	Nein
LB-Poolmitglied mit anderem Überwachungsport	Siehe Details.	(NLB ) Das Poolmitglied mit dem anderen Überwachungsport wird nicht migriert. (ALB) Das Poolmitglied wird migriert, befindet sich aber nicht in der Konfiguration des Überwachungsports.
Poolmitglied minConn	Nein
Überwachungserweiterung	Nein
SSL-sessionID-Persistenz/-Tabelle	(NLB) Nein (ALB) Ja
MSRDP-Persistenz/-Sitzungstabelle	Nein
Cookie-App-Sitzung/-Sitzungstabelle	(NLB) Nein (ALB) Ja
App-Persistenz	(NLB) Nein (ALB) Ja
Überwachen auf: Explizites Escape Beenden Verzögerung	Nein
Überwachen auf: Senden Erwarten Zeitüberschreitung Intervall maxRetries	Ja
Haproxy-Tuning/IPVS-Tuning	Nein
Pool-IP-Filter IPv4-Adressen	Ja	IPv4-IP-Adressen werden unterstützt. Wenn „Alle“ verwendet wird, werden nur die IPv4-Adressen des IP-Pools migriert.
Pool-IP-Filter IPv6-Adressen	Nein
Pool mit nicht unterstütztem Gruppierungsobjekt: Cluster Datencenter Verteilte Portgruppe MAC-Set Virtuelle App	Nein	Wenn ein Pool ein nicht unterstütztes Gruppierungsobjekt enthält, werden diese Objekte ignoriert, und der Pool wird mit unterstützten Gruppierungsobjektmitgliedern erstellt. Wenn keine unterstützten Gruppierungsobjektmitglieder vorhanden sind, wird ein leerer Pool erstellt.

DHCP und DNS

Tabelle 1. DHCP-Konfigurationstopologien

NSX-V-Konfiguration	Unterstützt	Details
DHCP-Relay, das auf Distributed Logical Router konfiguriert ist und auf einen DHCP-Server verweist, der auf einem direkt verbundenen Edge Services Gateway konfiguriert ist	Ja	Die IP des DHCP-Relay-Servers muss eine der internen Schnittstellen-IPs des Edge Services Gateway sein. Der DHCP-Server muss auf einem Edge Services Gateway konfiguriert werden, das direkt mit dem Distributed Logical Router verbunden ist, der mit dem DHCP-Relay konfiguriert ist. DNAT kann nicht zum Übersetzen einer DHCP-Relay-IP verwendet werden, die nicht mit einer internen Schnittstelle des Edge Services Gateway übereinstimmt.
DHCP-Relay, das nur auf Distributed Logical Router konfiguriert ist, keine DHCP-Serverkonfiguration auf verbundenem Edge Services Gateway	Nein
DHCP-Server, der nur auf Edge Services Gateway konfiguriert ist, keine DHCP-Relay-Konfiguration auf verbundenem Distributed Logical Router	Nein

Tabelle 2. DHCP-Funktionen

NSX-V-Konfiguration	Unterstützt	Details
IP-Pools	Ja
Statische Bindungen	Ja
DHCP-Leases	Ja
Allgemeine DHCP-Optionen	Ja
DHCP-Dienst deaktiviert	Nein	In NSX-T können Sie den DHCP-Dienst nicht deaktivieren. Deaktivierte DHCP-Dienste auf NSX-V werden nicht migriert.
DHCP-Option: „Andere“	Nein	Das Feld „Andere“ in den DHCP-Optionen wird für die Migration nicht unterstützt. Beispielsweise wird die DHCP-Option „80“ nicht migriert. <dhcpOptions> <other> <code>80</code> <value>2f766172</value> </other> </dhcpOptions>
Verwaiste IP-Pools/Bindungen	Nein	Wenn IP-Pools oder statische Bindungen auf einem DHCP-Server konfiguriert sind, aber nicht von verbundenen logischen Switches verwendet werden, werden diese Objekte bei der Migration übersprungen.
DHCP, das auf dem Edge Services Gateway mit direkt verbundenen logischen Switches konfiguriert ist	Nein	Während der Migration werden direkt verbundene Edge Services Gateway-Schnittstellen als zentralisierte Dienstports migriert. NSX-T unterstützt jedoch nicht den DHCP-Dienst auf einem zentralisierten Dienstport, sodass die DHCP-Dienstkonfiguration für diese Schnittstellen nicht migriert wird.

Tabelle 3. DNS-Funktionen

NSX-V-Konfiguration	Unterstützt	Details
DNS-Ansichten	Ja	Nur die erste dnsView wird in die standardmäßige DNS-Weiterleitungszone von NSX-T migriert.
DNS-Konfiguration	Ja	Sie müssen verfügbare DNS-Listener-IPs für alle Edge-Knoten bereitstellen. Während „Konfiguration auflösen“ wird eine Meldung angezeigt, die dazu auffordert.
DNS – L3-VPN	Ja	Sie müssen die neu konfigurierten NSX-T-DNS-Listener-IPs der Remote-L3-VPN-Präfixliste hinzufügen. Während „Konfiguration auflösen“ wird eine Meldung angezeigt, die dazu auffordert.
DNS, das auf dem Edge Services Gateway mit direkt verbundenen logischen Switches konfiguriert ist	Nein	Während der Migration werden direkt verbundene Edge Services Gateway-Schnittstellen als zentralisierte Dienstports migriert. NSX-T unterstützt jedoch nicht den DNS-Dienst auf einem zentralisierten Dienstport, sodass die DNS-Dienstkonfiguration für diese Schnittstellen nicht migriert wird.

Verteilte Firewall (Distributed Firewall, DFW)

NSX-V-Konfiguration	Unterstützt	Details
Identitätsbasierte Firewall	Ja
Abschnitt – Name Beschreibung Strenges TCP Stateless Firewall	Ja	Wenn ein Firewallabschnitt über mehr als 1000 Regeln verfügt, migriert der Migrator die Regeln in mehreren Abschnitten von jeweils 1000 Regeln.
Universelle Abschnitte	Ja, wenn die NSX-V-Bereitstellung über einen NSX Manager im primären Modus und keine sekundären NSX Manager verfügt.
Regel – Quelle/Ziel: IP-Adresse/Bereich/CIDR Logischer Port Logischer Switch	Ja
Regel – Quelle/Ziel: VM Logischer Port Sicherheitsgruppe/IP Set/MAC Set	Ja	wird Sicherheitsgruppe zugewiesen
Regel – Quelle/Ziel: Cluster Datencenter DVPG vSS Host	Nein
Regel – Quelle/Ziel: Globaler logischer Switch	Ja, wenn die NSX-V-Bereitstellung über einen NSX Manager im primären Modus und keine sekundären NSX Manager verfügt.
Regel – Quelle/Ziel: VMs nicht auf NSX-V-Hosts	Nein	NSX-T unterstützt keine Referenzobjekte, die nicht mit NSX-T-Portgruppen oder -Netzwerken verbunden sind. Diese Objekte gehen vom Quell- oder Zielort verloren, wenn die Migration abgeschlossen ist. Um dieses Problem zu vermeiden, verwenden Sie IP-Adressen in NSX-V, um vor der Migration auf diese Objekte zu verweisen.
Regel – Angewendet auf: ANY	Ja	Zuordnung zur verteilten Firewall
Regel – Angewendet auf: Sicherheitsgruppe Logischer Port Logischer Switch VM	Ja	wird Sicherheitsgruppe zugewiesen
Regel – Angewendet auf: Cluster Datencenter DVPG vSS Host	Nein
Regel – Angewendet auf: Globaler logischer Switch	Nein Ja, wenn die NSX-V-Bereitstellung über einen NSX Manager im primären Modus und keine sekundären NSX Manager verfügt.
Regeln in verteilter Firewall deaktiviert	Ja
Deaktivieren der verteilten Firewall auf Clusterebene	Nein	Wenn die verteilte Firewall auf NSX-T aktiviert ist, wird sie auf allen Clustern aktiviert. Sie können sie nicht auf einigen Clustern aktivieren und auf anderen deaktivieren.
DFW-Ausschlussliste	Nein	DFW-Ausschlusslisten werden nicht migriert. Sie müssen diese nach der Migration auf NSX-T erneut erstellen.

Partnerdienste: Vertikale Netzwerk-Introspektion

NSX-V-Konfiguration	Unterstützt	Details
Dienst	Nein	Die Dienstregistrierung wird nicht migriert. Der Partner muss den Dienst vor der Migration bei NSX-T registrieren.
Anbietervorlage	Nein	Anbietervorlage wird nicht migriert. Der Partner muss die Anbietervorlage vor der Migration bei NSX-T registrieren.
Dienstprofil	Nein	Dienstprofile werden nicht migriert. Entweder Sie oder der Partner muss vor der Migration die Dienstprofile erstellen. Im Migrationsschritt „Konfiguration auflösen“ werden Sie aufgefordert, alle NSX-V-Dienstprofile einem NSX-T-Dienstprofil zuzuordnen. Wenn Sie die Zuordnung von Dienstprofilen überspringen, werden die Regeln, die diese Dienstprofile verwenden, nicht migriert. Eine Dienstkette in NSX-T wird für jedes Dienstprofil in NSX-V erstellt. Die Dienstkette wird gemäß folgender Namenskonvention erstellt: Service-Chain-service_profile_name Im Weiterleitungspfad und im umgekehrten Pfad der Dienstkette wird dasselbe Dienstprofil verwendet.
Dienstinstanz	Nein	Die virtuellen Maschinen für Partnerdienste (SVMs) werden nicht migriert. Die NSX-V-Partner-SVMs können in NSX-T nicht verwendet werden. Für den horizontalen Netzwerk-Introspektionsdienst in NSX-T müssen die Partner-SVMs auf einem Overlay-Segment bereitgestellt werden.
Abschnitt Name ID Beschreibung Strenges TCP Stateless Firewall	Ja	Ein Abschnitt wird einer Umleitungsrichtlinie zugeordnet. Die ID ist benutzerdefiniert und wird nicht automatisch in NSX-T generiert. Wenn ein Firewallabschnitt in NSX-V über mehr als 1000 Regeln verfügt, werden die Regeln in mehreren Abschnitten von jeweils 1000 Regeln migriert. Wenn z. B. ein Abschnitt 2500 Regeln enthält, werden drei Richtlinien erstellt: Richtlinie 1 mit 1000 Regeln, Richtlinie 2 mit 1000 Regeln und Richtlinie 3 mit 500 Regeln. Stateful oder Stateless Firewallregeln in NSX-V werden als statusbehaftete oder statusfreie Umleitungsregeln in NSX-T migriert.
Partnerdienste: Regeln
Name	Ja
Regel-ID	Ja	Die Regel-ID wird vom System generiert. Sie kann sich von der Regel-ID in NSX-V unterscheiden.
Quelle ablehnen	Ja
Ziel ablehnen	Ja
Quelle/Ziel VM Sicherheitsgruppe IP Set vNIC	Ja
Dienste/Dienstgruppen	Ja	Weitere Informationen finden Sie in der Tabelle „Dienste und Dienstgruppen“.
Erweiterte Einstellungen Richtung Pakettyp Regel-Tag Kommentare Protokoll	Ja
Dienstprofil und Aktion Dienstname Dienstprofil Aktion Dienstprofil-Bindungen	Ja	Eine Dienstprofil-Bindung kann verteilte virtuelle Portgruppen (DVPG), logische Switches und Sicherheitsgruppen als Mitglieder besitzen. Eine Dienstprofil-Bindung in NSX-V wird dem Feld „Angewendet auf“ einer Umleitungsregel in NSX-T zugeordnet. Das Feld „Angewendet auf“ akzeptiert ausschließlich Gruppen. Dieses Feld bestimmt außerdem den Geltungsbereich der Regel. In NSX-T findet die Regelumleitung auf Richtlinienebene statt. Alle in einer Umleitungsrichtlinie enthaltenen Regeln haben denselben Geltungsbereich („Angewendet auf“). Das Feld „Angewendet auf“ in einer NSX-T-Umleitungsregel darf maximal 128 Mitglieder aufweisen. Falls die Anzahl der Mitglieder in einer Dienstprofil-Bindung 128 überschreitet, reduzieren Sie sie auf einen Wert <= 128, bevor Sie die Migration starten. Nehmen wir beispielsweise an, dass eine Dienstprofil-Bindung 140 Mitglieder (Sicherheitsgruppen) aufweist. Führen Sie in NSX-V die folgenden Schritte aus, bevor Sie mit der Migration beginnen: Erstellen Sie eine Dummy-Sicherheitsgruppe Verschieben Sie 13 Sicherheitsgruppen in diese Dummy-Sicherheitsgruppe. Das heißt, die Dummy-Sicherheitsgruppe hat dann 13 Mitglieder. Entfernen Sie die Bindung dieser 13 Sicherheitsgruppen aus dem Dienstprofil. Sie verfügen nun über 127 Mitglieder in der Dienstprofil-Bindung (140-13). Fügen Sie die Dummy-Sicherheitsgruppe zur Dienstprofil-Bindung hinzu. Jetzt beträgt die Gesamtzahl der Mitglieder in der Dienstprofilbindung 128 (127 + 1).
Regel aktivieren/deaktivieren	Ja

Dienstsegment

Ein Dienstsegment wird in der Overlay-Transportzone erstellt, die Sie im Migrationsschritt „Konfiguration auflösen“ auswählen. Wenn in der NSX-V-Umgebung die VXLAN-Transportzone nicht mit NSX-V vorbereitet wurde, haben Sie die Option, die standardmäßige Overlay-Transportzone in NSX-T auszuwählen, um das Dienstsegment zu erstellen. Wenn eine oder mehrere VXLAN-Transportzonen mit NSX-V vorbereitet wurden, müssen Sie eine beliebige Overlay-Transportzone auswählen, um das Dienstsegment in NSX-T zu erstellen.

Dienstprofil-Priorität

In NSX-V besitzt ein Dienstprofil eine Priorität. Wenn ein Dienst über mehrere Dienstprofile verfügt und mehrere Profile an dieselbe vNIC gebunden sind, wird zuerst das Dienstprofil mit der höheren Priorität auf die vNIC angewendet. In NSX-T weist ein Dienstprofil jedoch keine Priorität auf. Wenn mehrere Umleitungsregeln dieselbe „Angewendet auf“-Einstellung besitzen, entscheidet die Reihenfolge der Regeln, welche Regel zuerst ausgeführt wird. Mit anderen Worten: Die Regeln mit einer höheren Profilpriorität werden vor den Regeln mit einer niedrigeren Profilpriorität in der NSX-T-Regeltabelle platziert. Ein detailliertes Beispiel finden Sie in Szenario 2 unter Reihenfolge der migrierten Netzwerk-Introspektionsregeln in NSX-T.

Dienstvorrang

Um den Datenverkehr an mehrere Dienste umzuleiten, verwendet NSX-V im Service Insertion-Pfad mehrere DVFilter-Slots. Ein DVFilter-Slot wird für die Umleitung des Datenverkehrs zu einem Dienst verwendet. Ein Dienst mit hohem Vorrang wird höher im Slot platziert, als ein Dienst mit niedrigem Vorrang. In NSX-T wird nur ein einzelner DVFilter-Slot verwendet, der den Datenverkehr an eine Dienstkette umleitet. Nach der Migration zu NSX-T werden die Regeln, die einen Partnerdienst mit höherem Vorrang verwenden, vor den Regeln platziert, die einen Partnerdienst mit niedrigerem Vorrang verwenden. Ein detailliertes Beispiel finden Sie in Szenario 3 unter Reihenfolge der migrierten Netzwerk-Introspektionsregeln in NSX-T.

Die Umleitung des Datenverkehrs auf einer vNIC zu mehreren Partnerdiensten wird nicht unterstützt. Die Umleitung an einen einzigen Partnerdienst wird unterstützt. Obwohl alle NSX-V-Regeln zu NSX-T migriert werden, verwenden die migrierten Regelkonfigurationen eine Dienstkette mit nur einem Dienstprofil. Eine vorhandene Dienstkette, die in Umleitungsregeln verwendet wird, kann nicht bearbeitet werden.

Problemumgehung: Um den Datenverkehr auf einer vNIC an mehrere Dienste umzuleiten, erstellen Sie eine neue Dienstkette und definieren Sie die Reihenfolge der Dienstprofile in der Dienstkette. Aktualisieren Sie die migrierten Regeln, damit sie diese neue Dienstkette verwenden.

Netzwerk-Introspektionsdienst auf VMs, die mit einem VM-Netzwerk verbunden sind

Wenn in der NSX-V-Umgebung die Regeln des Netzwerk-Introspektionsdienstes auf VMs ausgeführt werden, die mit einem VM-Netzwerk verbunden sind, verlieren diese VMs nach der Hostmigration den Sicherheitsschutz. Um sicherzustellen, dass die Netzwerk-Introspektionsregeln nach der Hostmigration auf den vNICs dieser VMs durchgesetzt werden, müssen Sie diese VMs mit einem NSX-T-Segment verbinden.

Gruppieren von Objekten und Service Composer

IP Sets und MAC Sets werden als Gruppen zu NSX-T migriert. Weitere Informationen finden Sie unter Bestand > Gruppen auf der NSX-T Manager-Weboberfläche.

Tabelle 4. IP Sets und MAC Sets

NSX-V-Konfiguration	Unterstützt	Details
IP Sets	Ja	IP Sets mit bis zu 2 Millionen Mitgliedern (IP-Adressen, Subnetze von IP-Adressen, IP-Bereiche) können migriert werden. IP Sets mit mehr Mitgliedern werden nicht migriert.
Mac Sets	Ja	MAC Sets mit bis zu 2 Millionen Mitgliedern können migriert werden. MAC Sets mit mehr Mitgliedern werden nicht migriert.

Sicherheitsgruppen werden für die Migration mit den aufgeführten Einschränkungen unterstützt. Sicherheitsgruppen werden als Gruppen zu NSX-T migriert. Weitere Informationen finden Sie unter Bestand > Gruppen auf der NSX-T Manager-Weboberfläche.

NSX-V verfügt über systemdefinierte und benutzerdefinierte Sicherheitsgruppen. Diese werden alle als benutzerdefinierte Gruppen zu NSX-T migriert.

Die Gesamtanzahl der „Gruppen“ nach der Migration ist möglicherweise nicht gleich der Anzahl der Sicherheitsgruppen auf NSX-V. Beispielsweise würde eine Regel für eine verteilte Firewall, die eine virtuelle Maschine als Quelle enthält, in eine Regel migriert werden, die eine neue Gruppe mit der VM als Mitglied enthält. Dadurch wird die Gesamtanzahl der Gruppen auf NSX-T nach der Migration erhöht.

Tabelle 5. Sicherheitsgruppen

NSX-V-Konfiguration	Unterstützt	Details
Sicherheitsgruppe mit Mitgliedern, die nicht vorhanden sind	Nein	Wenn eines der Mitglieder der Sicherheitsgruppe nicht vorhanden ist, wird die Sicherheitsgruppe nicht migriert.
Sicherheitsgruppe, die eine Sicherheitsgruppe mit nicht unterstützten Mitgliedern enthält	Nein	Wenn Mitglieder der Sicherheitsgruppe nicht für die Migration unterstützt werden, wird die Sicherheitsgruppe nicht migriert. Wenn eine Sicherheitsgruppe eine Sicherheitsgruppe mit nicht unterstützten Mitgliedern enthält, wird die übergeordnete Sicherheitsgruppe nicht migriert.
Mitgliedschaft in Sicherheitsgruppe ausschließen	Nein	Sicherheitsgruppen mit einem direkt oder indirekt (über Schachtelung) auszuschließenden Mitglied werden nicht migriert
Statische Mitgliedschaft in einer Sicherheitsgruppe	Ja	Eine Sicherheitsgruppe kann bis zu 500 statische Mitglieder enthalten. Allerdings werden vom System generierte statische Mitglieder hinzugefügt, wenn die Sicherheitsgruppe in den Regeln der verteilten Firewall verwendet wird, wodurch der effektive Grenzwert auf 499 oder 498 gesenkt wird. Wenn die Sicherheitsgruppe in Layer-2- oder Layer-3-Regeln verwendet wird, wird ein vom System generiertes statisches Mitglied zur Sicherheitsgruppe hinzugefügt. Wenn die Sicherheitsgruppe sowohl in Layer-2- als auch in Layer-3-Regeln verwendet wird, werden zwei vom System generierte statische Mitglieder hinzugefügt. Wenn Mitglieder während des Schritts „Konfiguration auflösen“ nicht vorhanden sind, wird die Sicherheitsgruppe nicht migriert.
Mitgliedertypen der Sicherheitsgruppe („Statisch“ oder „Entität“ gehört zu): Cluster Datencenter Verzeichnisgruppe Verteilte Portgruppe Legacy-Portgruppe/-Netzwerk Ressourcenpool vApp	Nein	Wenn eine Sicherheitsgruppe einen der nicht unterstützten Mitgliedstypen enthält, wird die Sicherheitsgruppe nicht migriert.
Mitgliedertypen der Sicherheitsgruppe („Statisch“ oder „Entität“ gehört zu): Sicherheitsgruppe IP Sets MAC Sets	Ja	Sicherheitsgruppen, IP Sets und MAC Sets werden als Gruppen zu NSX-T migriert. Wenn eine NSX-V-Sicherheitsgruppe ein IP Set, ein MAC Set oder eine verschachtelte Sicherheitsgruppe als statisches Mitglied enthält, werden die entsprechenden Gruppen der übergeordneten Gruppe hinzugefügt. Wenn eines dieser statischen Mitglieder nicht zu NSX-T migriert wurde, wird die übergeordnete Sicherheitsgruppe nicht zu NSX-T migriert. Beispiel: Ein IP Set mit mehr als 2 Millionen Mitgliedern kann nicht zu NSX-T migriert werden. Aus diesem Grund ist für eine Sicherheitsgruppe, die ein IP Set mit mehr als 2 Millionen Mitgliedern enthält, keine Migration möglich.
Mitgliedertypen der Sicherheitsgruppe („Statisch“ oder „Entität“ gehört zu): Logischer Switch (virtuelle Leitung)	Ja	Wenn eine Sicherheitsgruppe logische Switches enthält, die nicht zu NSX-T-Segmenten migriert werden, wird die Sicherheitsgruppe nicht zu NSX-T migriert.
Mitgliedertypen der Sicherheitsgruppe („Statisch“ oder „Entität“ gehört zu): Sicherheits-Tag	Ja	Wenn der Sicherheitsgruppe ein Sicherheits-Tag als statisches Mitglied oder als dynamisches Mitglied mit „Entität gehört zu“ hinzugefügt wird, muss das Sicherheits-Tag vorhanden sein, damit die Sicherheitsgruppe migriert werden kann. Wenn das Sicherheits-Tag der Sicherheitsgruppe nicht als dynamisches Mitglied hinzugefügt wird (ohne „Entität gehört zu“), wird das Vorhandensein des Sicherheits-Tags vor der Migration der Sicherheitsgruppe nicht überprüft.
Mitgliedertypen der Sicherheitsgruppe („Statisch“ oder „Entität“ gehört zu): vNIC Virtuelle Maschine	Ja	vNICs und VMs werden als ExternalIDExpression migriert. Verwaiste VMs (von Hosts gelöschte VMs) werden bei der Migration von Sicherheitsgruppen ignoriert. Sobald die Gruppen auf NSX-T angezeigt werden, werden die VM- und vNIC-Mitgliedschaften nach einiger Zeit aktualisiert. Während dieser Zwischenzeit können temporäre Gruppen vorhanden sein, und ihre temporären Gruppen werden möglicherweise als Mitglieder angezeigt. Wenn die Hostmigration jedoch abgeschlossen ist, werden diese zusätzlichen temporären Gruppen nicht mehr angezeigt.
Verwenden des Operators „Stimmt mit regulärem Ausdruck überein“ für die dynamische Mitgliedschaft	Nein	Dies betrifft nur das Sicherheits-Tag und den VM-Namen. „Stimmt mit regulärem Ausdruck überein“ ist für andere Attribute nicht verfügbar.
Verwenden anderer verfügbarer Operatoren für dynamische Mitgliedschaftskriterien für Attribute: Sicherheits-Tag VM-Name Computername Name des Computer-Betriebssystems	Ja	Die verfügbaren Operatoren für VM-Name, Computername und Name des Computer-Betriebssystems sind „Enthält“, „Endet mit“, „Gleich“, „Ungleich“, „Beginnt mit“. Die verfügbaren Operatoren für das Sicherheits-Tag sind „Enthält“, „Endet mit“, „Gleich“, „Beginnt mit“.
Kriterien für „Entität gehört zu“	Ja	Dieselben Einschränkungen für die Migration statischer Mitglieder gelten für die Kriterien für „Entität gehört zu“. Wenn beispielsweise eine Sicherheitsgruppe „Entität gehört zu“ für einen Cluster in der Definition verwendet, wird diese Sicherheitsgruppe nicht migriert. Sicherheitsgruppen, die Kriterien für „Entität gehört zu“ enthalten, die mit UND kombiniert werden, werden nicht migriert.
Operatoren für dynamische Mitgliedschaftskriterien (UND, ODER) in der Sicherheitsgruppe	Ja.	Wenn Sie die dynamische Mitgliedschaft für eine NSX-V-Sicherheitsgruppe definieren, können Sie Folgendes konfigurieren: einen oder mehrere dynamische Sätze. Jeder dynamische Satz kann mehrere dynamische Kriterien enthalten. Beispiel: „VM-Name enthält web“. Sie können auswählen, ob beliebige oder alle dynamischen Kriterien innerhalb eines dynamischen Satzes übereinstimmen sollen. Sie können auswählen, ob Sie dynamische Sätze mit UND oder ODER abgleichen. NSX-V begrenzt nicht die Anzahl der dynamischen Kriterien und dynamischen Sätze. Sie können beliebige Kombinationen aus UND und ODER verwenden. In NSX-T können Sie eine Gruppe mit fünf Ausdrücken verwenden. NSX-V-Sicherheitsgruppen, die mehr als fünf Ausdrücke enthalten, werden nicht migriert. Beispiele für Sicherheitsgruppen, die migriert werden können: Bis zu 5 dynamische Sätze, die mit ODER verknüpft sind, bei denen jeder dynamische Satz bis zu 5 dynamische Kriterien beinhaltet, die mit UND verknüpft sind („Alle“ in NSX-V). 1 dynamischer Satz mit 5 dynamischen Kriterien, die mit ODER verknüpft sind („Beliebig“ in NSX-V). 1 dynamischer Satz mit 5 dynamischen Kriterien, die mit UND verknüpft sind („Alle“ in NSX-V). Alle Mitgliedstypen müssen identisch sein. 5 dynamische Sätze, die mit UND verknüpft sind und von denen jeder dynamische Satz genau 1 dynamisches Kriterium enthält. Alle Mitgliedstypen müssen identisch sein. Die Verwendung von Kriterien für „Entität gehört zu“ mit UND-Operatoren wird nicht unterstützt. Alle anderen Kombinationen oder Definitionen einer Sicherheitsgruppe, die nicht unterstützte Szenarien enthält, werden nicht migriert.

In NSX-V sind Sicherheits-Tags Objekte, die auf VMs angewendet werden können. Bei der Migration zu NSX-T sind Sicherheits-Tags Attribute einer VM.

Tabelle 6. Sicherheits-Tags

NSX-V-Konfiguration	Unterstützt	Details
Sicherheits-Tags	Ja	Wenn auf eine VM 25 oder weniger Sicherheits-Tags angewendet werden, wird die Migration von Sicherheits-Tags unterstützt. Wenn mehr als 25 Sicherheits-Tags angewendet werden, werden keine Tags migriert. Hinweis: Wenn Sicherheits-Tags nicht migriert werden, ist die VM nicht in Gruppen enthalten, die durch die Tag-Mitgliedschaft definiert sind. Sicherheits-Tags, die nicht auf eine VM angewendet werden, werden nicht migriert.

Dienste und Dienstgruppen werden als Dienste zu NSX-T migriert. Weitere Informationen finden Sie unter Bestand > Dienste auf der NSX-T Manager-Weboberfläche.

Tabelle 7. Dienste und Dienstgruppen

NSX-V-Konfiguration	Unterstützt	Details
Dienste und Dienstgruppen (Anwendungen und Anwendungsgruppen)	Ja	Die meisten Standarddienste und Dienstgruppen werden NSX-T-Diensten zugeordnet. Wenn ein Dienst oder eine Dienstgruppe in NSX-T nicht vorhanden ist, wird ein neuer Dienst in NSX-T erstellt.
APP_ALL- und APP_POP2-Dienstgruppen	Nein	Diese vom System definierten Dienstgruppen werden nicht migriert.
Dienste und Dienstgruppen mit Benennungskonflikten	Ja	Wenn in NSX-T ein Namenskonflikt für einen geänderten Dienst oder eine geänderte Dienstgruppe identifiziert wird, wird ein neuer Dienst in NSX-T mit einem Namen im folgenden Format erstellt: <NSXv-Anwendungsname> migriert aus NSX-v
Dienstgruppen, die Layer-2-Dienste mit Diensten in anderen Layern kombinieren	Nein
Leere Dienstgruppen	Nein	NSX-T unterstützt keine leeren Dienste.
Layer-2-Dienste	Ja	NSX-V Layer 2-Dienste werden als NSX-T-Diensteintrag „EtherTypeServiceEntry“ migriert.
Layer-3-Dienste	Ja	Basierend auf dem Protokoll werden NSX-V Layer-3-Dienste wie folgt zum NSX-T-Diensteintrag migriert: TCP/UDP-Protokoll: L4PortSetServiceEntry ICMP/IPV6ICMP-Protokoll: ICMPTypeServiceEntry IGMP-Protokoll: IGMPTypeServiceEntry Andere Protokolle: IPProtocolServiceEntry
Layer-4-Dienste	Ja	Als NSX-T-Diensteintrag „ALGTypeServiceEntry“ migriert.
Layer-7-Dienste	Ja	Als NSX-T-Diensteintrag „PolicyContextProfile“ migriert. Wenn für eine NSX-V Layer-7-Anwendung ein Port und ein Protokoll definiert sind, wird ein Dienst in NSX-T mit der entsprechenden Port- und Protokollkonfiguration erstellt und dem PolicyContextProfile zugeordnet.
Layer-7-Dienstgruppen	Nein
Regeln für verteilte Firewall, Edge-Firewall oder NAT, die Port und Protokoll enthalten	Ja	NSX-T erfordert einen Dienst zum Erstellen dieser Regeln. Wenn ein angemessener Dienst vorhanden ist, wird er verwendet. Wenn kein angemessener Dienst vorhanden ist, wird ein Dienst mit dem in der Regel angegebenen Port und Protokoll erstellt.

Tabelle 8. Service Composer

NSX-V-Konfiguration	Unterstützt	Details
Service Composer-Sicherheitsrichtlinien	Ja	In einer Sicherheitsrichtlinie definierte Firewallregeln werden als Regeln für eine verteilte Firewall zu NSX-T migriert. Deaktivierte Firewallregeln, die in einer Service Composer-Sicherheitsrichtlinie definiert sind, werden nicht migriert. Guest Introspection-Regeln oder Netzwerk-Introspektionsregeln, die in einer Service Composer-Sicherheitsrichtlinie definiert sind, werden migriert. Wenn der Service Composer-Status nicht synchronisiert ist, wird im Schritt „Konfiguration auflösen“ eine Warnung angezeigt. Sie können die Migration von Service Composer-Richtlinien überspringen, indem Sie die relevanten Abschnitte der verteilten Firewall überspringen. Alternativ können Sie die Migration zurücksetzen, Service Composer mit der verteilten Firewall synchronisieren und die Migration neu starten.
Service Composer-Sicherheitsrichtlinien werden nicht auf Sicherheitsgruppen angewendet	Nein

Active Directory-Serverkonfiguration

Konfiguration	Unterstützt	Details
Active Directory-(AD-)Server	Nein