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-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. |
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:
|
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:
|
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:
|
Ja |
Nur L3-Sitzungstyp wird für die Migration unterstützt |
PortMirroring:
|
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 |
Die Konfiguration nur mit VLAN (kein VXLAN) wird unterstützt. |
Teaming und Failover:
|
Ja |
Unterstützte Load Balancing-Optionen (Teaming-Richtlinie):
Andere Load Balancing-Optionen werden nicht unterstützt. |
Teaming und Failover:
|
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:
|
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:
|
Ja |
NSX Data Center for vSphere-API:
NSX-T-API:
NSX Data Center for vSphere-API:
NSX-T-API:
|
Firewallregelquellen und -ziele:
|
Nein |
|
Dienste (Anwendungen) in Firewallregeln:
|
Ja |
NSX Data Center for vSphere-API:
NSX-T-API:
|
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:
|
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:
|
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:
|
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:
|
Nein |
|
Überwachen auf:
|
Ja |
|
Haproxy-Tuning/IPVS-Tuning |
Nein |
|
Pool-IP-Filter
|
Ja |
IPv4-IP-Adressen werden unterstützt. Wenn „Alle“ verwendet wird, werden nur die IPv4-Adressen des IP-Pools migriert. |
Pool-IP-Filter
|
Nein |
|
Pool mit nicht unterstütztem Gruppierungsobjekt:
|
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
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 |
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. |
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 |
Nein |
|
Abschnitt –
|
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:
|
Ja |
|
Regel – Quelle/Ziel:
|
Ja |
wird Sicherheitsgruppe zugewiesen |
Regel – Quelle/Ziel:
|
Nein |
|
Regel – Quelle/Ziel:
|
(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:
|
Ja |
Zuordnung zur verteilten Firewall |
Regel – Angewendet auf:
|
Ja |
wird Sicherheitsgruppe zugewiesen |
Regel – Angewendet auf:
|
Nein |
|
Regel – Angewendet auf:
|
(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. |
DFW-Ausschlussliste | Nein | DFW-Ausschlusslisten werden nicht migriert. Sie müssen diese nach der Migration auf NSX-T erneut erstellen. |
Hinweis: Stellen Sie bei der Migration von DFW-Regeln sicher, dass auch die von den Regeln referenzierten Objekte migriert werden. NSX-T kann eine Regel nicht anwenden, wenn die von der Regel referenzierten Objekte nicht Teil des NSX-T Netzwerks sind.
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
|
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
|
Ja |
|
Dienste/Dienstgruppen |
Ja |
Weitere Informationen finden Sie in der Tabelle „Dienste und Dienstgruppen“. |
Erweiterte Einstellungen
|
Ja |
|
Dienstprofil und Aktion
|
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:
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 auf der NSX-T Manager-Weboberfläche.
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 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.
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 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):
|
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):
|
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):
|
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):
|
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):
|
Ja |
|
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:
|
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:
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:
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.
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 auf der NSX-T Manager-Weboberfläche.
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:
ICMPTypeServiceEntry
|
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. |
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 |