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. |
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:
|
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:
|
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:
|
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 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:
|
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-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:
|
Ja |
NSX-V-API:
NSX-T-API:
NSX-V-API:
NSX-T-API:
|
Firewallregelquellen und -ziele:
|
Nein |
|
Dienste (Anwendungen) in Firewallregeln:
|
Ja |
NSX-V-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-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:
|
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:
|
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:
|
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:
|
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-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. |
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 –
|
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:
|
Ja |
|
Regel – Quelle/Ziel:
|
Ja |
wird Sicherheitsgruppe zugewiesen |
Regel – Quelle/Ziel:
|
Nein |
|
Regel – Quelle/Ziel:
|
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:
|
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:
|
Ja |
Zuordnung zur verteilten Firewall |
Regel – Angewendet auf:
|
Ja |
wird Sicherheitsgruppe zugewiesen |
Regel – Angewendet auf:
|
Nein |
|
Regel – Angewendet auf:
|
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
|
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
|
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-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:
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 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 migriert. Weitere Informationen finden Sie unter 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.
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-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):
|
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-V-Sicherheitsgruppe definieren, können Sie Folgendes konfigurieren:
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:
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.
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 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-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:
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-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. |
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 |