NSX for vSphere-Funktionen (NSX-v) und -Konfigurationen, die migriert werden können, sind unten 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 Data Center for vSphere mit vSAN oder iSCSI auf vSphere Distributed Switch

Ja

Bereits vorhandene NSX-T-Konfiguration

Nein

Stellen Sie eine neue NSX-T Data Center-Umgebung als Ziel für die NSX Data Center for vSphere-Migration bereit.

Während des Schritts Konfiguration importieren werden alle NSX Edge-Knotenschnittstellen in der NSX-T Data Center-Zielumgebung heruntergefahren. Wenn die NSX-T Data Center-Zielumgebung bereits konfiguriert ist und verwendet wird, wird der Datenverkehr beim Starten des Konfigurationsimports unterbrochen.

Cross-vCenter NSX

(NSX-T 3.1) Nein

(NSX-T 3.1.1 und höher) Ja, wenn die NSX-v-Bereitstellung über einen NSX Manager im primären Modus und keine sekundären NSX Manager verfügt.

Ab NSX-T 3.1.1 wird die Migration einer NSX for vSphere-Bereitstellung auf einer einzelnen Site unterstützt, die einen NSX Manager im primären Modus, keine sekundären NSX Manager und mit universellen Objekten auf dem primären Standort enthält. Eine solche NSX for vSphere-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 echten Cross-vCenter NSX for vSphere-Bereitstellung mit einem primären NSX Manager und mehreren sekundären NSX Manager-Instanzen wird nicht unterstützt. Wenn die primäre oder die sekundäre NSX Manager-Instanz jedoch auf einen eigenständigen oder Transitmodus festgelegt ist, wird die Migration unterstützt.

NSX Data Center for vSphere mit einer Cloud Management-Plattform, einer Integrated Stack- oder PaaS-Lösung.

Ja

Die Migration von NSX for vSphere mit vRealize Automation wird unterstützt, wenn die integrierte Umgebung in einer unterstützten Topologie konfiguriert ist.

Einzelheiten dazu finden Sie unter Für die Integration mit vRealize Automation unterstützte Topologien.

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 for vSphere und VMware Integrated OpenStack

  • NSX for vSphere und vCloud Director

  • NSX for vSphere mit Integrated Stack-Lösung

  • NSX for vSphere mit PaaS-Lösung wie Pivotal Cloud Foundry, RedHat OpenShift

  • NSX for vSphere 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 Data Center for vSphere-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 (wenn der Wartungsmodus verwendet wird)

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 Data Center for vSphere-Passphrase entsprechend den Anforderungen von NSX-T Data Center. 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.

Betrieb

Details

Unterstützt

Anmerkungen

Discovery-Protokoll CDP

Nein

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

Trunk-Uplink-Portgruppen muss mit einem VLAN-Bereich von 0–4094 konfiguriert werden.

VLAN-Konfiguration

Ja

Nur die Verzögerung mit der VLAN-Konfiguration wird nicht 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

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 Data Center for vSphere 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 Data Center for vSphere-Transportzonen mit Multicast- oder Hybrid-Replikationsmodus

Nein

NSX Data Center for vSphere-Transportzonen mit Unicast-Replikationsmodus

Ja

Funktionen von NSX Edge

Ausführliche Informationen zu unterstützten Topologien finden Sie unter Unterstützte Topologien.

NSX-v-Konfiguration

Unterstützt

Details

Routing zwischen Edge Services Gateway und Northbound-Router oder virtueller Tunnelschnittstelle

Ja

BGP wird unterstützt.

Statische Routen werden unterstützt.

OSPF wird nicht unterstützt.

Routing zwischen Edge Services Gateway und Distributed Logical Router

Ja

Routen werden nach der Migration in statische Routen umgewandelt.

Load Balancer

Ja

Weitere Informationen finden Sie unter Unterstützte Topologien.

VLAN-gestützte Mikrosegmentierungs-Umgebung

Ja

Weitere Informationen finden Sie unter Unterstützte Topologien.

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.

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 NSX Edge-Knotenkonfiguration vor dem Migrieren von Edges.

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 Data Center for vSphere-API: GatewayPolicy/action

NSX-T-API: SecurityPolicy.action

Globale Firewallkonfiguration

Nein

Standard-Zeitüberschreitungen werden verwendet

Firewallregel

Ja

NSX Data Center for vSphere-API: firewallRule

NSX-T-API: SecurityPolicy

Firewallregel: Name

Ja

Firewallregel: Regel-Tag

Ja

NSX Data Center for vSphere-API: ruleTag

NSX-T-API: Rule_tag

Quellen und Ziele in Firewallregeln:

  • Objekte werden gruppiert

  • IP-Adressen

Ja

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

Firewallregelquellen und -ziele:

  • vNIC-Gruppe

Nein

Dienste (Anwendungen) in Firewallregeln:

  • Dienst

  • Dienstgruppe

  • Protokoll/Port/Quellport

Ja

NSX Data Center for vSphere-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 Data Center for vSphere-API: Protokollierung

NSX-T-API: protokolliert

Firewallregel: Beschreibung

Ja

Beide APIs: description

Edge-NAT

NSX-v-Konfiguration

Unterstützt

Details

NAT-Regel

Ja

NSX Data Center for vSphere-API: natRule

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

NAT-Regel: Regel-Tag

Ja

NSX Data Center for vSphere-API: ruleTag

NSX-T-API: rule_tag

NAT-Regel: Aktion

Ja

NSX Data Center for vSphere-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 Data Center for vSphere-API: originalAddress

NSX-T-API: source_network für SNAT-Regel oder destination_network für DNAT-Regel

NAT-Regel: translatedAddress

Ja

NSX Data Center for vSphere-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 Data Center for vSphere-API: loggingEnabled

NSX-T-API: Protokollierung

NAT-Regel: aktiviert

Ja

NSX Data Center for vSphere-API: aktiviert

NSX-T-API: deaktiviert

NAT-Regel: Beschreibung

Ja

NSX Data Center for vSphere-API: Beschreibung

NSX-T-API: Beschreibung

NAT-Regel: Protokoll

Ja

NSX Data Center for vSphere-API: Protokoll

NSX-T-API: Dienst

NAT-Regel: ursprünglicher Port (Quellport für SNAT-Regeln, Zielport für DNAT-Regeln)

Ja

NSX Data Center for vSphere-API: originalPort

NSX-T-API: Dienst

NAT-Regel: übersetzter Port

Ja

NSX Data Center for vSphere-API: translatedPort

NSX-T-API: Translated_ports

NAT-Regel: Quelladresse in DNAT-Regel

Ja

NSX Data Center for vSphere-API: dnatMatchSourceAddress

NSX-T-API: source_network

NAT-Regel:

Zieladresse in SNAT-Regel

Ja

NSX Data Center for vSphere-API: snatMatchDestinationAddress

NSX-T-API: destination_network

NAT-Regel:

Quellport in DNAT-Regel

Ja

NSX Data Center for vSphere-API: dnatMatchSourcePort

NSX-T-API: Dienst

NAT-Regel:

Zielport in SNAT-Regel

Ja

NSX Data Center for vSphere-API: snatMatchDestinationPort

NSX-T-API: Dienst

NAT-Regel: Regel-ID

Ja

NSX Data Center for vSphere-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 Data Center for vSphere 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 Data Center for vSphere-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 Data Center for vSphere dpdelay wird NSX-T dpdinternal zugeordnet.

Überlappende lokale und Peer-Subnetze von zwei oder mehr Sitzungen.

Nein

NSX Data Center for vSphere 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

NSX-v-Konfiguration

Unterstützt

Details

Überwachung/Integritätsprüfungen für:

  • LDAP

  • DNS

  • MSSQL

Nein

Wenn eine nicht unterstützte Überwachung konfiguriert ist, wird die Überwachung ignoriert, und für den zugehörigen Pool ist keine Überwachung konfiguriert. Sie können ihn nach Abschluss der Migration an eine neue Überwachung anbinden.

Anwendungsregeln

Nein

NSX Data Center for vSphere 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

Nein

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

Nein

Bei Verwendung in einem Pool wird der Pool nicht migriert.

Isolierter Pool

Nein

Der Pool wird nicht migriert.

LB-Poolmitglied mit anderem Überwachungsport

Nein

Das Poolmitglied mit dem anderen Überwachungsport wird nicht migriert.

Poolmitglied minConn

Nein

Konfiguration wird nicht migriert.

Überwachungserweiterung

Nein

Konfiguration wird nicht migriert.

SSL-sessionID-Persistenz/-Tabelle

Nein

Die Konfiguration wird nicht migriert, und der zugeordnete virtuelle Server hat keine Persistenzeinstellung.

MSRDP-Persistenz/-Sitzungstabelle

Nein

Die Konfiguration wird nicht migriert, und der zugeordnete virtuelle Server hat keine Persistenzeinstellung.

Cookie-App-Sitzung/-Sitzungstabelle

Nein

Die Konfiguration wird nicht migriert, und der zugeordnete virtuelle Server hat keine Persistenzeinstellung.

App-Persistenz

Nein

Die Konfiguration wird nicht migriert, und der zugeordnete virtuelle Server hat keine Persistenzeinstellung.

Ü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 Data Center for vSphere 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

NSX-v-Konfiguration

Unterstützt

Details

Identitätsbasierte Firewall

Nein

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

(NSX-T 3.1) Nein

(NSX-T 3.1.1 und höher) 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

(NSX-T 3.1) Nein

(NSX-T 3.1.1 und höher) Ja, wenn die NSX-v-Bereitstellung über einen NSX Manager im primären Modus und keine sekundären NSX Manager verfügt.

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

(NSX-T 3.1) Nein

(NSX-T 3.1.1 und höher) 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.

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 vom Migrationskoordinator aufgefordert, alle NSX for vSphere-Dienstprofile einem NSX-T-Dienstprofil zuzuordnen. Wenn Sie die Zuordnung von Dienstprofilen überspringen, werden die Regeln, die diese Dienstprofile verwenden, nicht migriert.

Der Migrationskoordinator erstellt für jedes Dienstprofil in NSX for vSphere eine Dienstkette in NSX-T.

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 for vSphere-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 for vSphere über mehr als 1000 Regeln verfügt, migriert der Migrationskoordinator die Regeln in Abschnitten von jeweils 1000 Regeln.

Wenn z. B. ein Abschnitt 2500 Regeln enthält, erstellt der Migrationskoordinator drei Richtlinien: Richtlinie 1 mit 1000 Regeln, Richtlinie 2 mit 1000 Regeln und Richtlinie 3 mit 500 Regeln.

Statusbehaftete oder statusfreie Firewallregeln in NSX for vSphere 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 for vSphere 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 for vSphere 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 for vSphere die folgenden Schritte aus, bevor Sie mit der Migration beginnen:
  1. Erstellen Sie eine Dummy-Sicherheitsgruppe
  2. Verschieben Sie 13 Sicherheitsgruppen in diese Dummy-Sicherheitsgruppe. Das heißt, die Dummy-Sicherheitsgruppe hat dann 13 Mitglieder.
  3. Entfernen Sie die Bindung dieser 13 Sicherheitsgruppen aus dem Dienstprofil. Sie verfügen nun über 127 Mitglieder in der Dienstprofil-Bindung (140-13).
  4. Fügen Sie die Dummy-Sicherheitsgruppe zur Dienstprofil-Bindung hinzu.

Jetzt beträgt die Gesamtzahl der Mitglieder in der Dienstprofil-Bindung 128 (127 + 1) und hält die Obergrenze des Migrationskoordinators ein.

Regel aktivieren/deaktivieren

Ja

Dienstsegment
Der Migrationskoordinator erstellt ein Dienstsegment in der Overlay-Transportzone, die Sie im Migrationsschritt „Konfiguration auflösen“ auswählen. Wenn in der NSX for vSphere-Umgebung die VXLAN-Transportzone nicht mit NSX for vSphere vorbereitet wurde, bietet Ihnen der Migrationskoordinator 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 for vSphere vorbereitet wurden, müssen Sie eine beliebige Overlay-Transportzone auswählen, um das Dienstsegment in NSX-T zu erstellen.
Dienstprofil-Priorität
In NSX for vSphere 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. Das heißt, der Migrationskoordinator platziert in der NSX-T-Regeltabelle die Regeln mit einer höheren Profilpriorität vor den Regeln mit einer niedrigeren Profilpriorität. Ein detailliertes Beispiel finden Sie in Szenario 2 unter Reihenfolge der migrierten Netzwerk-Introspektionsregeln in NSX-T Data Center.
Dienstvorrang

Um den Datenverkehr an mehrere Dienste umzuleiten, verwendet NSX for vSphere 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 Data Center.

Der Migrationskoordinator unterstützt keine Umleitung des Datenverkehrs auf einer vNIC an mehrere Partnerdienste. Die Umleitung an einen einzigen Partnerdienst wird unterstützt. Obwohl alle NSX for vSphere-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 Data Center 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 Data Center migriert. Weitere Informationen finden Sie unter Bestand > Gruppen auf der NSX-T Manager-Weboberfläche.

NSX Data Center for vSphere 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 for vSphere-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 Data Center for vSphere-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 Data Center for vSphere begrenzt nicht die Anzahl der dynamischen Kriterien und dynamischen Sätze. Sie können beliebige Kombinationen aus UND und ODER verwenden.

In NSX-T Data Center können Sie eine Gruppe mit fünf Ausdrücken verwenden. NSX Data Center for vSphere-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 Data Center for vSphere).

  • 1 dynamischer Satz mit 5 dynamischen Kriterien, die mit ODER verknüpft sind („Beliebig“ in NSX Data Center for vSphere).

  • 1 dynamischer Satz mit 5 dynamischen Kriterien, die mit UND verknüpft sind („Alle“ in NSX Data Center for vSphere). 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 Data Center for vSphere 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.

Dienste und Dienstgruppen werden als Dienste zu NSX-T Data Center 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 Data Center for vSphere Layer 2-Dienste werden als NSX-T-Diensteintrag „EtherTypeServiceEntry“ migriert.

Layer-3-Dienste

Ja

Basierend auf dem Protokoll werden NSX Data Center for vSphere 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 Data Center for vSphere 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 abbrechen, 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