VMware NSX Data Center for vSphere 6.4.6 | Veröffentlicht am Freitag, 10. Oktober 2019 | Build 14819921

Siehe den Revisionsverlauf dieses Dokuments.

Inhalt dieser Versionshinweise

Diese Versionshinweise decken die folgenden Themen ab:

Neuigkeiten in NSX Data Center for vSphere 6.4.6

Wichtiger Hinweis: NSX for vSphere wird nun als NSX Data Center for vSphere bezeichnet.

In NSX Data Center for vSphere 6.4.6 wurden Verbesserungen in Bezug auf Nutzbarkeit und Betriebsfähigkeit vorgenommen, und einige von Kunden gemeldete Probleme wurden behoben. Weitere Informationen dazu finden Sie unter Behobene Probleme.

Änderungen in NSX Data Center for vSphere 6.4.6:

  • VMware NSX – Funktionalitätsaktualisierungen für vSphere Client (HTML): Die folgenden VMware NSX-Funktionen sind jetzt über den vSphere Client verfügbar: Edge-Dienste (Edge-Firewall, L2-VPN, IPSEC-VPN, NSX-Konfigurationen). Eine Liste der unterstützten Funktionalität finden Sie unter VMware NSX for vSphere-UI-Plug-In-Funktionalität im vSphere Client.
  • Die Auditor-Rolle von NSX Manager verfügt jetzt über die Berechtigung, Support-Protokollpakete von NSX Edge mithilfe von Skyline Log Assist zu erfassen. Mit dieser Berechtigungserweiterung kann ein Benutzer mit einer Auditor-Rolle das Support-Protokollpaket von NSX Manager- und Edge-Knoten ohne Einschränkung herunterladen. Die vollständige Liste der Rollen und Berechtigungen finden Sie im Administratorhandbuch für NSX.

Versionen, Systemanforderungen und Installation

Hinweis:

  • In der folgenden Tabelle sind empfohlene Versionen von VMware-Software aufgelistet. Diese Empfehlungen sind allgemeiner Natur. Umgebungsspezifische Empfehlungen haben demgegenüber Vorrang. Diese Informationen sind auf dem Stand des Veröffentlichungsdatums dieses Dokuments.

  • Die unterstützten Mindestversionen von NSX und anderen VMware-Produkten entnehmen Sie der VMware-Produkt-Interoperabilitätsmatrix. Die Einstufung als unterstützte Mindestversionen durch VMware erfolgt auf der Basis interner Tests.

Produkt oder Komponente Version
NSX Data Center for vSphere

VMware empfiehlt die neueste NSX-Version für neue Bereitstellungen.

Wenn Sie für vorhandene Bereitstellungen ein Upgrade durchführen möchten, lesen Sie bitte die Versionshinweise zu NSX Data Center for vSphere oder wenden Sie sich an einen Mitarbeiter des technischen Supports von VMware für weitere Informationen zu spezifischen Problemen, bevor Sie ein Upgrade planen.

vSphere

Für vSphere 6.0:
Empfohlen: 6.0 Update 3
vSphere 6.0 Update 3 behebt das Problem der doppelten VTEPs in ESXi-Hosts nach dem Neustart von vCenter Server. Weitere Informationen dazu enthält der VMware-Knowledgebase-Artikel 2144605.

Für vSphere 6.5:
Empfohlen: 6.5 Update 3
Hinweis: vSphere 6.5 Update 1 behebt das Problem des OutOfMemory-Fehlers bei EAM. Weitere Informationen dazu enthält der VMware-Knowledgebase-Artikel 2135378.
Wichtiger Hinweis:

  • Wenn Sie Multicast-Routing mit vSphere 6.5 verwenden, wird das vSphere 6.5-Update 2 oder höher empfohlen.
  • Bei Verwendung von NSX Guest Introspection auf vSphere 6.5 wird vSphere 6.5 P03 oder höher empfohlen.

Für vSphere 6.7:
Empfohlen: 6.7 Update 2
Wichtiger Hinweis: 

  • Wenn Sie NSX Guest Introspection auf vSphere 6.7 verwenden, lesen Sie den Knowledgebase-Artikel 57248, bevor Sie NSX 6.4.6 installieren, und wenden Sie sich an den VMware-Kundensupport.

Hinweis: vSphere 5.5 wird mit NSX 6.4 nicht unterstützt.
Guest Introspection für Windows

Es wird empfohlen, VMware Tools vor dem Upgrade von NSX for vSphere auf 10.3.10 zu aktualisieren.
Guest Introspection für Linux Diese NSX-Version unterstützt die folgenden Linux-Versionen:
  • RHEL 7 GA (64 Bit)
  • SLES 12 GA (64 Bit)
  • Ubuntu 14.04 LTS (64 Bit)

Systemanforderungen und Installation

Eine vollständige Liste der NSX-Installationsvoraussetzungen finden Sie im Abschnitt Systemvoraussetzungen für NSX im Installationshandbuch für NSX.

Anweisungen zur Installation erhalten Sie im Installationshandbuch für NSX oder im Installationshandbuch zu Cross-vCenter NSX.

Eingestellte und nicht fortgeführte Funktionalität

Warnungen zum Ende der Lebensdauer und des Supports

Informationen zu NSX- und anderen VMware-Produkten, für die demnächst ein Upgrade durchgeführt werden muss, finden Sie unter der VMware-Lebenszyklus-Produktmatrix.

  • Für NSX for vSphere 6.1.x gilt als Ende der Verfügbarkeit (EOA, End of Availability) und des allgemeinen Supports (EOGS, End of General Support) der 15. Januar 2017. (Informationen hierzu finden Sie auch im VMware-Knowledgebase-Artikel 2144769.)

  • vCNS-Edges werden nicht mehr unterstützt. Vor dem Upgrade auf NSX 6.3 oder höher müssen Sie zuerst ein Upgrade auf ein NSX Edge durchführen.

  • NSX for vSphere 6.2.x erreicht das Ende des allgemeinen Supports (End of General Support, EOGS) am 20. August 2018.

  • Gemäß Sicherheitsempfehlungen wird 3DES als Verschlüsselungsalgorithmus im NSX Edge-IPsec-VPN-Dienst nicht mehr unterstützt.
    Es wird empfohlen, dass Sie zu einer der sicheren im IPsec-Dienst verfügbaren Verschlüsselungen wechseln. Diese Änderung in Bezug auf den Verschlüsselungsalgorithmus gilt für IKE SA (Phase 1) als auch für die Aushandlung der IPSec SA (Phase 2) für eine IPSec-Site.
     
    Wenn der 3DES-Verschlüsselungsalgorithmus zum Zeitpunkt des Upgrades auf die Version, in der er nicht mehr unterstützt wird, vom NSX Edge-IPSec-Dienst verwendet wird, wird er durch eine andere empfohlene Verschlüsselung ersetzt. IPSec-Sites, die 3DES verwenden, werden deshalb nicht gestartet, solange die Konfiguration auf dem Remote-Peer nicht so geändert wird, dass der Verschlüsselungsalgorithmus mit dem in NSX Edge verwendeten Verschlüsselungsalgorithmus übereinstimmt.
     
    Wenn Sie 3DES-Verschlüsselung verwenden, passen Sie den Verschlüsselungsalgorithmus in der IPsec-Site-Konfiguration an, um 3DES durch eine der unterstützten AES-Varianten zu ersetzen (AES/AES256/AES-GCM). So sollte beispielsweise in jeder IPSec-Site-Konfiguration mit 3DES als Verschlüsselungsalgorithmus dieser durch AES ersetzt werden. Aktualisieren Sie entsprechend die IPSec-Konfiguration am Peer-Endpoint.

Allgemeine Änderungen des Verhaltens

Wenn Sie über mehr als einen vSphere Distributed Switch verfügen und wenn VXLAN auf einem von ihnen konfiguriert ist, müssen Sie alle Distributed Logical Router-Schnittstellen mit Portgruppen auf diesem vSphere Distributed Switch verbinden. Ab der Version NSX 6.4.1 wird diese Konfiguration in der Benutzeroberfläche und API erzwungen. In früheren Versionen wurden Sie nicht daran gehindert, eine ungültige Konfiguration zu erstellen.  Wenn Sie ein Upgrade auf NSX 6.4.1 oder höher durchführen und über falsch verbundene DLR-Schnittstellen verfügen, müssen Sie dieses Problem beheben. Nähere Informationen dazu finden Sie in den Upgrade-Hinweisen.

Entfernung von Elementen und Änderungen an der Benutzeroberfläche

In NSX 6.4.1 wurde die Service Composer-Arbeitsfläche entfernt.

Änderungen am Installationsverhalten

Ab Version 6.4.2 ist die empfangsseitige Skalierung (Receive Side Scaling, RSS) bei einer Installation von NSX Data Center for vSphere auf Hosts, die über physische Netzwerkkarten (NICs) mit ixgbe-Treibern verfügen, auf den ixgbe-Treibern nicht standardmäßig aktiviert. Sie müssen RSS manuell auf den Hosts aktivieren, bevor Sie NSX Data Center installieren. Achten Sie darauf, RSS nur auf den Hosts zu aktivieren, die Netzwerkkarten (NICs) mit ixgbe-Treibern haben. Detaillierte Anweisungen zum Aktivieren von RSS finden Sie im VMware-Knowledgebase-Artikel https://kb.vmware.com/s/article/2034676. In diesem Knowledgebase-Artikel werden die empfohlenen RSS-Einstellungen für verbesserten VXLAN-Paketdurchsatz beschrieben.

Dieses neue Verhalten tritt nur auf, wenn Sie eine Neuinstallation von Kernel-Modulen (VIB-Dateien) auf den ESXi-Hosts durchführen. Es sind keine Änderungen erforderlich, wenn Sie für von NSX verwaltete Hosts ein Upgrade auf 6.4.2 durchführen.

Entfernung von APIs und Änderungen des Verhaltens

Veraltete Elemente in NSX 6.4.2

Das folgende Element ist veraltet und wird in einer künftigen Version möglicherweise entfernt:

  • GET/POST/DELETE /api/2.0/vdn/controller/{controllerId}/syslog. Verwenden Sie stattdessen GET/PUT /api/2.0/vdn/controller/cluster/syslog.

Änderungen des Verhaltens in NSX 6.4.1

Wenn Sie einen neuen IP-Pool mit POST /api/2.0/services/ipam/pools/scope/globalroot-0 erstellen oder einen bestehenden IP-Pool mit PUT /api/2.0/services/ipam/pools/ ändern und im Pool mehrere IP-Bereiche definiert sind, erfolgt eine Validierung, um sicherzustellen, dass die Bereiche sich nicht überlappen. Diese Validierung wurde zuvor nicht durchgeführt.

Veraltete Elemente in NSX 6.4.0
Die folgenden Elemente sind veraltet und werden in einer künftigen Versionen möglicherweise entfernt.

  • Der Parameter systemStatus in GET /api/4.0/edges/edgeID/status ist veraltet.
  • GET /api/2.0/services/policy/serviceprovider/firewall/ ist veraltet. Verwenden Sie stattdessen GET /api/2.0/services/policy/serviceprovider/firewall/info.
  • Die Einstellung tcpStrict im globalen Konfigurationsbereich von „Verteilte Firewall“ ist veraltet. Ab Version NSX 6.4.0 wird tcpStrict auf Abschnittsebene definiert. Anmerkung: Wenn Sie ein Upgrade auf NSX 6.4.0 oder höher durchführen, wird die globale Konfigurationseinstellung für tcpStrict verwendet, um tcpStrict in jedem bestehenden Abschnitt der Ebene 3 zu konfigurieren. tcpStrict wird in Abschnitten der Ebene 2 und in Umleitungsabschnitten der Ebene 3 auf „false“ gesetzt. Weitere Informationen finden Sie im API-Handbuch zu NSX im Abschnitt zum Arbeiten mit der Konfiguration der verteilten Firewall.

Änderungen des Verhaltens in NSX 6.4.0
In NSX 6.4.0 ist der Parameter <name> erforderlich, wenn Sie einen Controller mit POST /api/2.0/vdn/controller erstellen.

In NSX 6.4.0 werden folgende Änderungen in Bezug auf die Fehlerbehandlung eingeführt:

  • Bisher gab POST /api/2.0/vdn/controller die Antwort 201 Created zurück, um anzugeben, dass der Auftrag zum Erstellen des Controllers durchgeführt wurde. Doch das Erstellen des Controllers konnte trotzdem fehlgeschlagen sein. Ab Version NSX 6.4.0 lautet die Antwort 202 Accepted.
  • Wenn Sie bisher eine API-Anforderung gesendet haben, die im Übergangsmodus oder im eigenständigen Modus nicht zulässig ist, lautete der Antwortstatus 400 Bad Request. Ab Version 6.4.0 lautet der Antwortstatus 403 Forbidden.

Entfernungen von CLI und Änderungen des Verhaltens

Verwenden Sie keine nicht unterstützten Befehle auf NSX Controller-Knoten
Es sind nicht dokumentierte Befehle zur Konfiguration von NTP und DNS auf NSX Controller-Knoten vorhanden. Diese Befehle werden nicht unterstützt und dürfen nicht auf NSX Controller-Knoten verwendet werden. Es stehen nur diejenigen Befehle zur Verfügung, die im NSX-CLI-Handbuch dokumentiert sind.

Upgrade-Hinweise

Hinweis: Eine Liste der bekannten Probleme, die Auswirkungen auf die Installation und auf Upgrades haben, finden Sie unter Bekannte Installations- und Upgrade-Probleme.

Allgemeine Upgrade-Hinweise

  • Für das Upgrade von NSX müssen Sie ein vollständiges NSX-Upgrade einschließlich eines Hostcluster-Upgrades durchführen (wobei die Host-VIBs aktualisiert werden). Anweisungen hierzu erhalten Sie im Upgrade-Handbuch für NSX im Abschnitt Aktualisieren der Hostcluster.

  • Ein Upgrade von NSX-VIBs auf Host-Clustern mithilfe von VUM wird nicht unterstützt. Verwenden Sie zum Durchführen des Upgrades von NSX-VIBs auf Host-Clustern den Upgrade-Koordinator, die Hostvorbereitung oder die zugehörigen REST-APIs.

  • Systemvoraussetzungen: Die Informationen zu den Systemanforderungen für die Installation und das Upgrade von NSX werden im Abschnitt Systemvoraussetzungen für NSX der NSX-Dokumentation dargestellt.

  • Upgrade-Pfad für NSX: Die VMware-Produkt-Interoperabilitätsmatrix bietet Details zu den Upgrade-Pfaden von VMware NSX.

  • Das Upgrade für Cross-vCenter NSX wird im Upgrade-Handbuch für NSX erläutert.

  • Herabstufungen werden nicht unterstützt:

    • Führen Sie vor der Durchführung eines Upgrades immer eine Sicherung von NSX Manager durch.

    • Nach einem erfolgreichen Upgrade von NSX ist kein Downgrade von NSX möglich.

  • Zur Überprüfung, ob Ihr Upgrade auf NSX 6.4.x erfolgreich durchgeführt wurde, finden Sie Erläuterungen im Knowledgebase-Artikel 2134525.

  • Upgrades von vCloud Networking and Security auf NSX 6.4.x werden nicht unterstützt. Sie müssen zuerst ein Upgrade auf eine unterstützte 6.2.x-Version durchführen.

  • Interoperabilität: Überprüfen Sie vor dem Upgrade die VMware-Produkt-Interoperabilitätsmatrix für alle betreffenden VMware-Produkte.
    • Upgrade auf NSX Data Center for vSphere 6.4: NSX 6.4 ist nicht mit vSphere 5.5 kompatibel.
    • Upgrade auf NSX Data Center for vSphere 6.4.5: Wenn NSX mit VMware Integrated OpenStack (VIO) bereitgestellt wird, aktualisieren Sie VIO auf 4.1.2.2 oder 5.1.0.1, da 6.4.5 aufgrund des Spring-Updates des Pakets auf Version 5.0 nicht mit früheren Versionen kompatibel ist.
    • Upgrade auf vSphere 6.5: Wenn Sie ein Upgrade auf vSphere 6.5a oder höhere 6.5-Versionen durchführen möchten, müssen Sie zuerst ein Upgrade auf NSX 6.3.0 oder höher vornehmen. NSX 6.2.x ist nicht mit vSphere 6.5 kompatibel. Weitere Informationen dazu finden Sie unter Upgrade von vSphere in einer NSX-Umgebung im Upgrade-Handbuch für NSX.
    • Upgrade auf vSphere 6.7: Wenn Sie ein Upgrade auf vSphere 6.7 durchführen möchten, müssen Sie zuerst ein Upgrade auf NSX 6.4.1 oder höher vornehmen. Frühere Versionen von NSX sind nicht mit vSphere 6.7 kompatibel. Weitere Informationen dazu finden Sie unter Upgrade von vSphere in einer NSX-Umgebung im Upgrade-Handbuch für NSX. 
  • Kompatibilität mit Partnerdiensten: Wenn Ihre Site VMware-Partnerdienste für Guest Introspection oder für die Netzwerk-Introspektion verwendet, müssen Sie mithilfe des VMware-Kompatibilitäts-Handbuchs vor dem Upgrade prüfen, ob der Dienst Ihres Anbieters mit dieser NSX-Version kompatibel ist.
  • Networking & Security-Plug-In: Nach dem Upgrade von NSX Manager müssen Sie sich vom vSphere Web Client abmelden und wieder bei ihm anmelden. Wenn das NSX-Plug-In nicht ordnungsgemäß angezeigt wird, löschen Sie den Browser-Cache und den Verlauf. Wenn das Networking & Security-Plug-In nicht im vSphere Web Client angezeigt wird, setzen Sie den vSphere Web Client-Server wie im Upgrade-Handbuch für NSX beschrieben zurück.
  • Zustandsfreie Umgebungen: Bei NSX-Upgrades in einer statusfreien Hostumgebung werden die neuen VIBs während des NSX-Upgrades im Vorfeld zum Host-Image-Profil hinzugefügt. Das Verfahren von NSX-Upgrades auf statusfreien Hosts muss daher in folgender Reihenfolge durchgeführt werden:

    In Versionen vor NSX 6.2.0 wurde eine einzelne URL in NSX Manager verwendet, über die VIBs für eine bestimmte Version von ESX Host ermittelt werden konnten. (Der Administrator musste also nur eine einzige URL kennen, unabhängig von der NSX-Version.) In NSX 6.2.0 und höher sind die neuen NSX-VIBs über mehrere URLs verfügbar. Führen Sie die folgenden Schritte aus, um die richtigen VIBs zu ermitteln:

    1. Suchen Sie unter https://<nsxmanager>/bin/vdn/nwfabric.properties nach der neuen VIB-URL.
    2. Rufen Sie die VIBs der erforderlichen ESX-Hostversion über die jeweilige URL ab.
    3. Fügen Sie sie zu einem Image-Profil hinzu.

Upgrade-Hinweise für NSX-Komponenten

Unterstützung für VM-Hardwareversion 11 für NSX-Komponenten

  • Für neue Installationen von NSX Data Center for vSphere 6.4.2 gilt für die NSX-Komponenten (Manager, Controller, Edge, Guest Introspection) die VM-Hardwareversion 11.
  • Bei Upgrades auf NSX Data Center for vSphere 6.4.2 wird für die NSX Edge- und Guest Introspection-Komponenten automatisch ein Upgrade auf VM-Hardwareversion 11 vorgenommen. Die NSX Manager- und NSX Controller-Komponenten weisen auch nach einem Upgrade die VM-Hardwareversion 8 auf. Benutzer haben die Möglichkeit, für die VM-Hardware ein Upgrade auf Version 11 vorzunehmen. Informationen zum Upgrade von VM-Hardwareversionen finden Sie in der KB (https://kb.vmware.com/s/article/1010675).
  • Für neue Installationen von NSX 6.3.x, 6.4.0 und 6.4.1 gilt für die NSX-Komponenten (Manager, Controller, Edge, Guest Introspection) die VM-Hardwareversion 8.

NSX Manager-Upgrade

  • Wichtiger Hinweis: Wenn Sie für NSX 6.2.0, 6.2.1 oder 6.2.2 ein Upgrade auf NSX 6.3.5 oder höher durchführen, müssen Sie vor Beginn des Upgrades eine Problemumgehung durchführen. Details finden Sie im VMware-Knowledgebase-Artikel 000051624.

  • Wenn Sie ein Upgrade von NSX 6.3.3 auf NSX 6.3.4 oder höher durchführen möchten, müssen Sie zunächst die Anweisungen zur Problemumgehung im VMware-Knowledgebase-Artikel 2151719 befolgen.

  • Wenn Sie SFTP für NSX-Sicherungen verwenden, ändern Sie nach dem Upgrade auf Version 6.3.0 oder höher den Sicherheitsalgorithmus auf hmac-sha2-256, da hmac-sha1 nicht unterstützt wird. Eine Liste der unterstützten Sicherheitsalgorithmen finden Sie im VMware-Knowledgebase-Artikel 2149282 .

  • Beim Upgrade von NSX Manager auf NSX 6.4.1 wird automatisch eine Sicherung erstellt und als Teil des Upgrade-Vorgangs lokal gespeichert. Weitere Informationen finden Sie unter Upgrade von NSX Manager.

  • Wenn Sie ein Upgrade auf NSX 6.4.0 durchführen, werden die TLS-Einstellungen beibehalten. Wenn Sie nur TLS 1.0 aktiviert haben, werden die NSX-Plug-Ins in vSphere Web Client angezeigt, NSX Manager sind aber nicht sichtbar. Dies hat keine Auswirkung auf den Datenpfad, es kann jedoch auch keine NSX Manager-Konfiguration geändert werden. Melden Sie sich bei der Web-Benutzeroberfläche für das NSX-Appliance-Management unter https://nsx-mgr-ip/ an und aktivieren Sie TLS 1.1 und TLS 1.2. Damit wird die NSX Manager-Appliance neu gestartet.

Controller-Upgrade

  • Der NSX Controller-Cluster muss drei Controller-Knoten enthalten. Bei weniger als drei Controllern müssen Sie die entsprechende Anzahl an Controllern vor dem Start des Upgrades hinzufügen. Weitere Informationen finden Sie unter Bereitstellen des NSX Controller-Clusters.

  • In NSX 6.3.3 hat sich das zugrunde liegende Betriebssystem des NSX Controllers geändert. Bei einem Upgrade von NSX 6.3.2 oder früher auf NSX 6.3.3 oder höher wird deshalb nicht die vorhandene Software aktualisiert. Es werden stattdessen die bestehenden Controller einzeln nacheinander gelöscht und neue Photon OS-basierte Controller bereitgestellt, die dieselben IP-Adressen verwenden.

    Wenn die Controller gelöscht werden, werden auch alle zugehörigen DRS-Anti-Affinitätsregeln gelöscht. Sie müssen neue Anti-Affinitätsregeln in vCenter erstellen, um zu verhindern, dass sich die neuen Controller-VMs auf demselben Host befinden.

    Weitere Informationen zu Controller-Upgrades finden Sie unter Upgrade von NSX Controller-Clustern.

Hostcluster-Upgrade

  • Wenn Sie ein Upgrade von NSX 6.3.2 oder früher auf NSX 6.3.3 oder höher durchführen, ändern sich die NSX-VIB-Namen.
    Die esx-vxlan- und esx-vsip-VIBs werden mit esx-nsxv ersetzt, wenn Sie über NSX 6.3.3 oder höher verfügen, das auf ESXi 6.0 oder höher installiert ist.

  • Upgrade ohne Neustart und Deinstallation auf den Hosts: Bei vSphere 6.0 und höher ist nach einem Upgrade von NSX 6.2.x auf NSX 6.3.x oder höher für alle nachfolgenden NSX-VIB-Änderungen kein Neustart erforderlich. Stattdessen müssen die Hosts in den Wartungsmodus wechseln, um die VIB-Änderung abzuschließen. Dies betrifft sowohl das NSX-Hostcluster-Upgrade als auch das ESXi-Upgrade. Weitere Informationen dazu finden Sie im Upgrade-Handbuch für NSX.

​Upgrade von NSX Edge

  • Validierung in NSX 6.4.1 hinzugefügt, um ungültige Distributed Logical Router-Konfigurationen nicht zuzulassen: In Umgebungen, in denen VXLAN konfiguriert ist und mehr als ein vSphere Distributed Switch vorhanden ist, dürfen Distributed Logical Router-Schnittstellen nur mit dem VXLAN-konfigurierten vSphere Distributed Switch verbunden werden. Ein Upgrade von DLR auf NSX 6.4.1 oder höher schlägt in diesen Umgebungen fehl, wenn der DLR über Schnittstellen verfügt, die mit dem nicht für VXLAN konfigurierten vSphere Distributed Switch verbunden sind. Verwenden Sie die API für die Verbindung fälschlicherweise konfigurierter Schnittstellen mit Portgruppen am VXLAN-konfigurierten vSphere Distributed Switch. Sobald die Konfiguration gültig ist, wiederholen Sie das Upgrade. Sie können die Schnittstellenkonfiguration unter Verwendung von PUT /api/4.0/edges/{edgeId} oder PUT /api/4.0/edges/{edgeId}/interfaces/{index} ändern. Weitere Informationen dazu finden Sie im API-Handbuch zu NSX.

  • Löschen Sie die UDLR-Kontroll-VM vom vCenter Server, die mit dem sekundären NSX Manager verknüpft ist, bevor Sie UDLR von 6.2.7 auf 6.4.5 aktualisieren:
    Wenn Sie in einer Multi-vCenter-Umgebung NSX-UDLRs von 6.2.7 auf 6.4.5 aktualisieren, schlägt das Upgrade der virtuellen UDLR-Appliance (UDLR-Kontroll-VM) auf dem sekundären NSX Manager fehl, wenn HA auf der UDLR-Kontroll-VM aktiviert ist. Während des Upgrades wird die VM mit dem HA-Index #0 im HA-Paar aus der NSX-Datenbank entfernt. Diese VM ist jedoch weiterhin auf dem vCenter Server vorhanden. Wenn daher die UDLR-Kontroll-VM auf dem sekundären NSX Manager aktualisiert wird, schlägt das Upgrade fehl, da der Name der VM mit einer vorhandenen VM auf dem vCenter Server kollidiert. Um dieses Problem zu beheben, löschen Sie die Kontroll-VM vom vCenter Server, die mit dem UDLR auf dem sekundären NSX Manager verknüpft ist, und aktualisieren Sie UDLR dann von 6.2.7 auf 6.4.5.

  • Host-Cluster müssen vor dem Upgrade von NSX Edge-Appliances für NSX vorbereitet werden: Ab 6.3.0 wird eine Kommunikation der Managementebene zwischen NSX Manager und Edge über den VIX-Kanal ist nicht mehr unterstützt. Es wird nur der Nachrichtenbuskanal unterstützt. Wenn Sie ein Upgrade von NSX 6.2.x oder früher auf NSX 6.3.0 oder höher durchführen, müssen Sie sicherstellen, dass die Hostcluster, auf denen NSX Edge-Appliances bereitgestellt werden, für NSX vorbereitet sind und dass für die Messaging-Infrastruktur der Status GRÜN (GREEN) gilt. Wenn die Hostcluster nicht für NSX vorbereitet sind, schlägt das Upgrade der NSX Edge-Appliance fehl. Ausführliche Informationen finden Sie unter Upgrade von NSX Edge im Upgrade-Handbuch für NSX.

  • Upgrade von Edge Services Gateway (ESG):
    Ab Version NSX 6.2.5 wird die Ressourcenreservierung gleichzeitig mit dem NSX Edge-Upgrade vorgenommen. Wenn vSphere HA auf einem Cluster aktiviert wird, der nicht über ausreichende Ressourcen verfügt, schlägt der Upgrade-Vorgang möglicherweise fehl, da vSphere HA-Einschränkungen verletzt werden.

    Um derartige Upgrade-Fehler zu vermeiden, führen Sie die folgenden Schritte durch, bevor Sie ein ESG-Upgrade vornehmen:

    Die folgenden Ressourcenreservierungen werden vom NSX Manager verwendet, sofern Sie nicht bei der Installation oder beim Upgrade ausdrücklich andere Werte festgelegt haben.

    NSX Edge
    Formfaktor    		 CPU-Reservierung Arbeitsspeicherreservierung
    KOMPAKT 1000 MHz 512 MB
    GROSS 2000 MHz 1024 MB
    QUADLARGE 4000 MHz 2048 MB
    X-LARGE 6000 MHz 8192 MB

    1. Stellen Sie grundsätzlich sicher, dass Ihre Installation den Empfehlungen für vSphere HA entspricht. Erläuterungen dazu finden Sie im VMware-Knowledgebase-Artikel 1002080.

    2. Verwenden Sie die NSX-API für die Feinabstimmung der Konfiguration:
      PUT https://<nsxmanager>/api/4.0/edgePublish/tuningConfiguration
      Stellen Sie dabei sicher, dass die Werte für edgeVCpuReservationPercentage und edgeMemoryReservationPercentage in die verfügbaren Ressourcen für den Formfaktor passen (siehe Standardwerte in der Tabelle oben).

  • Deaktivieren Sie die Startoption für die virtuelle Maschine von vSphere, sofern vSphere HA aktiviert ist und Edges bereitgestellt sind. Nach dem Upgrade von NSX Edges 6.2.4 oder früher auf die Version 6.2.5 oder höher müssen Sie die Startoption für die virtuelle Maschine von vSphere für jede NSX Edge-Instanz in einem Cluster deaktivieren, für den vSphere HA aktiviert ist und Edges bereitgestellt sind. Dazu müssen Sie den vSphere Web Client öffnen, den ESXi-Host ermitteln, auf dem sich die NSX Edge-VM befindet, auf „Verwalten“ > „Einstellungen“ klicken und unter „Virtuelle Maschinen“ die Option „VM starten/herunterfahren“ auswählen. Klicken Sie auf „Bearbeiten“ und stellen Sie sicher, dass sich die virtuelle Maschine im manuellen Modus befindet (d. h., sie darf nicht in der Liste „Automatisches Starten/Herunterfahren“ enthalten sein).

  • Bevor Sie ein Upgrade auf NSX 6.2.5 oder höher vornehmen, stellen Sie sicher, dass alle Load-Balancer-Verschlüsselungslisten durch Doppelpunkte getrennt sind. Falls in Ihrer Verschlüsselungsliste ein anderes Trennzeichen als ein Komma verwendet wird, führen Sie einen PUT-Aufruf für https://nsxmgr_ip/api/4.0/edges/EdgeID/loadbalancer/config/applicationprofiles durch und ersetzen Sie jede <ciphers> </ciphers>-Liste in <clientssl> </clientssl> und <serverssl> </serverssl> durch eine durch Kommas getrennte Liste. Beispielsweise kann das betreffende Segment des Anforderungstextes das im Folgenden dargestellte Aussehen haben. Wiederholen Sie diesen Vorgang für alle Anwendungsprofile:

    <applicationProfile>
  <name>https-profile</name>
  <insertXForwardedFor>false</insertXForwardedFor>
  <sslPassthrough>false</sslPassthrough>
  <template>HTTPS</template>
  <serverSslEnabled>true</serverSslEnabled>
  <clientSsl>
    <ciphers>AES128-SHA:AES256-SHA:ECDHE-ECDSA-AES256-SHA</ciphers>
    <clientAuth>ignore</clientAuth>
    <serviceCertificate>certificate-4</serviceCertificate>
  </clientSsl>
  <serverSsl>
    <ciphers>AES128-SHA:AES256-SHA:ECDHE-ECDSA-AES256-SHA</ciphers>
    <serviceCertificate>certificate-4</serviceCertificate>
  </serverSsl>
  ...
</applicationProfile>
  • Legen Sie die richtige Verschlüsselungsversion für Clients mit Lastausgleichsdienst auf vROPs-Versionen vor 6.2.0 fest: vROPs-Poolmitglieder auf vROPs-Versionen vor 6.2.0 verwenden TLS-Version 1.0, weshalb Sie explizit einen Wert für die Überwachungserweiterung festlegen müssen, indem Sie die Einstellung "ssl-version=10" in der NSX-Load-Balancer-Konfiguration festlegen. Anweisungen dazu finden Sie unter Erstellen eines Dienstmonitors im Administratorhandbuch für NSX.
    {
    "expected" : null,
    "extension" : "ssl-version=10",
    "send" : null,
    "maxRetries" : 2,
    "name" : "sm_vrops",
    "url" : "/suite-api/api/deployment/node/status",
    "timeout" : 5,
    "type" : "https",
    "receive" : null,
    "interval" : 60,
    "method" : "GET"
}

  • Nach dem Upgrade auf NSX 6.4.6 können L2-Bridges und -Schnittstellen auf einem DLR keine Verbindungen zu logischen Switches herstellen, die zu unterschiedlichen Transportzonen gehören:  In NSX 6.4.5 oder früheren Versionen unterstützen L2-Bridge-Instanzen und -Schnittstellen auf einem Distributed Logical Router (DLR) die Verwendung logischer Switches, die zu verschiedenen Transportzonen gehörten. Ab NSX 6.4.6 wird diese Konfiguration nicht mehr unterstützt. Die L2-Bridge-Instanzen und -Schnittstellen auf einem DLR müssen mit logischen Switches verbunden sein, die sich in einer einzelnen Transportzone befinden. Wenn logische Switches aus mehreren Transportzonen verwendet werden, wird das Edge-Upgrade während Validierungsüberprüfungen vor dem Upgrade blockiert, wenn Sie NSX auf 6.4.6 aktualisieren. Um dieses Problem mit dem Edge-Upgrade zu beheben, stellen Sie sicher, dass die Bridge-Instanzen und Schnittstellen auf einem DLR mit logischen Switches in einer einzelnen Transportzone verbunden sind.

Upgrade-Hinweise für FIPS

Wenn Sie ein Upgrade von einer NSX-Version vor NSX 6.3.0 auf NSX 6.3.0 oder höher durchführen möchten, dürfen Sie den FIPS-Modus nicht vor dem Abschluss des Upgrades aktivieren. Wenn Sie den FIPS-Modus vor Abschluss des Upgrades aktivieren, wird die Kommunikation zwischen aktualisierten und nicht aktualisierten Komponenten unterbrochen. Weitere Informationen dazu finden Sie unter Grundlegendes zum FIPS-Modus und zum NSX-Upgrade im Upgrade-Handbuch für NSX.

  • Auf OS X Yosemite und OS X El Capitan unterstützte Verschlüsselungen: Wenn Sie auf OS X 10.11 (EL Capitan) einen SSL-VPN-Client verwenden, können Sie mit den Verschlüsselungen AES128-GCM-SHA256, ECDHE-RSA-AES128-GCM-SHA256, ECDHE-RSA-AES256-GCM-SHA38, AES256-SHA und AES128-SHA eine Verbindung herstellen. Auf OS X 10.10 (Yosemite) haben Sie nur mit den Verschlüsselungen AES256-SHA und AES128-SHA die Möglichkeit, eine Verbindung herzustellen.

  • Aktivieren Sie den FIPS-Modus erst, wenn das Upgrade auf NSX 6.3.x abgeschlossen ist. Weitere Informationen dazu finden Sie unter Grundlegendes zum FIPS-Modus und zum NSX-Upgrade im Upgrade-Handbuch für NSX.

  • Vor der Aktivierung des FIPS-Modus müssen Sie sicherstellen, dass die Partnerlösungen für den FIPS-Modus zertifiziert sind. Informationen dazu finden Sie im VMware-Kompatibilitäts-Handbuch und in der jeweiligen Partnerdokumentation.

FIPS-Konformität

NSX 6.4 verwendet FIPS 140-2-validierte kryptografische Module für die gesamte sicherheitsbezogene Kryptografie, wenn diese korrekt konfiguriert sind.

Hinweis:

  • Controller und Clustering-VPN: Der NSX Controller verwendet das IPSec-VPN zur Herstellung einer Verbindung mit Controller-Clustern. Das IPSec-VPN verwendet das VMware-Verschlüsselungsmodul für den Linux-Kernel (VMware Photon OS 1.0-Umgebung), das gerade der CMVP-Validierung unterzogen wird.
  • Edge-IPSec-VPN: Das NSX Edge-IPSec-VPN verwendet das VMware-Verschlüsselungsmodul für den Linux-Kernel (VMware Photon OS 4.4-Umgebung), das gerade der CMVP-Validierung unterzogen wird.

Revisionsverlauf der Dokumente

10. Oktober 2019: Erste Auflage.
6. November 2019. Zweite Auflage. Bekanntes Problem 2442884 und zugehöriger Upgradehinweis wurden hinzugefügt.
3. Dezember 2019. Dritte Auflage. Link zur Problemumgehung für bekanntes Problem 2367906 wurde hinzugefügt.
9. Januar 2020. Vierte Auflage. Bekanntes Problem 2449643 wurde hinzugefügt.
18. Mai 2020. Fünfte Auflage. Hinzugefügte bekannte Probleme: 2444275, 2445183, 2445396, 2448235, 2448449, 2451586, 2452833, 2458746, 2459936, 2493095, 2498988, 2502739, 2509224, 2513773, 2536058, 2551523.
25. Mai 2020. Sechste Auflage. Behobenes Problem 2379274 – Hinweis bzgl. des Edge-Upgrades wurde hinzugefügt.

Behobene Probleme

  • Behobenes Problem 1648578 – NSX erzwingt das Hinzufügen von Cluster/Netzwerk/Speicher, wenn eine neue Host-basierte NetX-Dienstinstanz erstellt wird.
    Wenn Sie über den vSphere Web Client eine neue Dienstinstanz für Host-basierte NetX-Dienste, beispielsweise eine Firewall, IDS und IPS, erstellen, werden Sie gezwungen, Cluster/Netzwerk/Speicher hinzuzufügen, auch wenn diese nicht erforderlich sind.
  • Behobenes Problem 2001988 – Während eines NSX-Hostcluster-Upgrades wechselt der Installationsstatus für den gesamten Cluster auf der Registerkarte „Hostvorbereitung“ zwischen „Nicht bereit“ und „Wird installiert“, wenn jeder Host im Cluster aktualisiert wird.

    Während eines NSX-Upgrades wird durch Klicken auf „Upgrade verfügbar“ ein Host-Upgrade für NSX-vorbereitete Cluster ausgelöst. Bei als „DRS FULL AUTOMATIC“ konfigurierten Clustern wechselt der Installationsstatus zwischen „Wird installiert“ und „Nicht bereit“, obwohl die Hosts im Hintergrund problemlos aktualisiert werden.

  • Behobenes Problem 2005973 – Routing-Daemon MSR verliert die gesamte Routing-Konfiguration, nachdem einige GRE-Tunnel gelöscht wurden und anschließend eine Synchronisierung des Edge-Knotens über die Managementebene erzwungen wurde.

    Dieses Problem kann auf einem Edge mit BGP-Sitzungen über GRE-Tunnel auftreten. Wenn einige GRE-Tunnel gelöscht werden und dann eine erzwungene Synchronisierung des Edge über die Managementebene durchgeführt wird, verliert das Edge die gesamte Routing-Konfiguration.

  • Behobenes Problem 2005900 – Routing-Daemon MSR auf Edge bleibt bei 100 % CPU-Auslastung stehen, wenn alle GRE-Tunnel in einer Skalierungstopologie mit 8-Wege-iBGP/Multihop-BGP-ECMP fluktuieren.

    Dieses Problem kann in einer Skalierungstopologie auftreten, für die iBGP oder Multihop-BGP auf ESG mit mehreren Nachbarn über viele GRE-Tunnel konfiguriert ist. Wenn mehrere GRE-Tunnel fluktuieren, bleibt MSR möglicherweise für unbestimmte Zeit bei 100 % der CPU-Auslastung hängen.

  • Behobenes Problem 2118255 – Die DLR-Kontroll-VM nimmt nicht am Multicast-Routing teil.

    DLR-Kontroll-VM nimmt nicht an Multicast-Routing teil. Für die gesamte mit Multicast in Verbindung stehende CLI wird in der Kontroll-VM eine leere CLI-Anzeige aufgeführt.

  • Behobenes Problem 2189417 – Anzahl der Ereignisprotokolle, die den unterstützten Grenzwert überschreiten.

    Bei umfangreichen Ereignissen gehen einige verloren, was zu einem Verlust von IDFW-Funktionalität führt (nur bei physischen Arbeitslasten).

  • Behobenes Problem 2312793 – ETag-Wert in der HTTP-Kopfzeile ist von doppelten Anführungszeichen umschlossen.

    Die REST API schlägt fehl, wenn der ETag-Wert in der Antwort verwendet wird.

  • Behobenes Problem 2279045 – Blockieren der Ende-zu-Ende-Latenz beim Verbinden der vNIC mit der VLAN-gestützten dvportgroup.

    Ende-zu-Ende-Latenz unterstützt keine VLAN-gestützte dvportgroup. Wenn die Latenz-Konfiguration auf einer solchen Portgruppe festgelegt wird, wird eine Ausnahme angezeigt. Nur die Overlay-gestützte dvportgroup kann verwendet werden.

  • Behobenes Problem 2265909 – Keine Unterstützung mehr für doppelten Schrägstrich in REST API-URI.

    REST API-Aufrufe schlagen mit FEHLER 500 fehl: Interner Serverfehler. REST-APIs schlagen fehl, wenn URI einen doppelten Schrägstrich enthält.

  • Behobenes Problem 2319867 – Ende-zu-Ende-Latenz ist auf einem neuen Host nicht automatisch konfiguriert, wenn ein neuer Host zum VDS mit aktivierter Ende-zu-Ende-Latenz hinzugefügt wird.

    Wenn die Ende-zu-Ende-Latenz bereits auf einem VDS konfiguriert ist und ein neuer Host hinzugefügt wird, wird die Ende-zu-Ende-Latenz auf dem neuen Host nicht automatisch konfiguriert. Die Latenz auf diesem Host kann nicht überwacht werden.

  • Behobenes Problem 2442884 – NSX Version 6.4.6 ist nicht mit VMware Integrated OpenStack kompatibel.

    Ab NSX 6.4.6 können Sie keine Firewallregel mit einer Ziel-IP von 0.0.0.0/0 mehr erstellen. Dies führt zu einer Inkompatibilität zwischen NSX 6.4.6 und allen Versionen von vSphere Integrated OpenStack. Informationen zu den kompatiblen Versionen finden Sie in der VMware-Produkt-Interoperabilitätsmatrix.

  • Behobenes Problem 2331068 – NSX Edge ist aufgrund von zu vielen Firewall-Gruppierungsobjekt-Aktualisierungsmeldungen nicht mehr verwaltbar.

    NSX Edge ist nicht mehr verwaltbar. Die Datenebene funktioniert jedoch ordnungsgemäß. Administratoren können keine Konfigurationsänderungen vornehmen und den Edge-Status nicht abfragen.

  • Behobenes Problem 2320171 – Ressourcenreservierung der Edge-Appliance wird auf „Keine Reservierung“ zurückgesetzt, wenn die Edge-Appliance in einen anderen Cluster oder Ressourcenpool verschoben wird.

    Nach dem Verschieben der Edge-Appliance in einen anderen Cluster oder Ressourcenpool müssen Administratoren die Reservierung der Edge-Appliance manuell zurücksetzen, indem Sie eine API-Anforderung durchführen.

  • Behobenes Problem 2349110 – Die Funktion „Kennwort speichern“ funktioniert nicht im SSL-VPN-Plus Client auf Mac-Computern.

    SSL-VPN-Benutzer müssen Benutzernamen und Kennwort erneut eingeben, um sich beim SSL-VPN-Server anzumelden, auch wenn die Option „Kennwort speichern“ ausgewählt ist.

  • Behobenes Problem 2360114 – In einer Cross-VC-NSX-Umgebung mit mehreren Standorten ist die Route Redistribution-Seite für ein Edge, das von einem sekundären NSX Manager verwaltet wird, nicht verfügbar. 

    Dieses Problem bestand nur beim HTML5-basierten vSphere Client. vSphere Web Client hatte dieses Problem nicht.

  • Behobenes Problem 2337437 – CPU-Kernel-Absturz für längere Zeit.

    CPU empfängt für N Sek. kein Taktsignal und es kommt zu Leistungsbeeinträchtigungen.

  • Behobenes Problem 2305079 – NSX-Identitäts-Firewall funktioniert zeitweise. NSX-Kontext-Engine wird auf einem ESXi-Host nicht ausgeführt.

    Bei der Verwendung von NSX Guest Introspection zum Erkennen von Netzwerkereignissen funktioniert die NSX-Identitäts-Firewall zeitweise. Wenn die NSX-Kontext-Engine auf einem ESXi-Host ausgeführt wird, funktioniert die Identitäts-Firewall wie vorgesehen. Wenn die Kontext-Engine jedoch nicht ausgeführt wird, funktioniert die Identitäts-Firewall nicht.

  • Behobenes Problem 2375249 – Firewall-Regeln können nicht veröffentlicht werden, wenn in den Feldern „Quell-IP-Adresse“ und „Ziel-IP-Adresse“ zusätzliche Leerzeichen vorhanden sind.

    Die vsfwd-Protokolldatei zeigt die ungültige Firewall-Konfiguration mit der Funktion „string2ip“ an.

  • Behobenes Problem 2305989 – Im dcsms-Prozess tritt ein Arbeitsspeicherverlust auf, wenn die CLI-Befehle „IP-BGP anzeigen“ und „IP-BGP-Nachbarn anzeigen“ ausgeführt werden.

    Der dcsms-Prozess (Dynamic Clustering Secure Mobile Multicast) erreicht eine sehr hohe Arbeitsspeichernutzung und die normale Verarbeitung wird beeinträchtigt. Edge geht in die Situation für unzureichenden Arbeitsspeicher über, was dazu führt, dass das Edge neu geladen wird.

  • Behobenes Problem 2379274 – Wenn Schnittstellen oder Bridges eines DLR mit logischen Switches verbunden sind, die sich in unterschiedlichen Transportzonen befinden, fehlen VDR-Instanzen auf einigen Hosts.

    VMs können nicht auf ihr Standard-Gateway zugreifen und der Datenpfadverkehr fällt aus.

  • Behobenes Problem 2291285 – Wenn eine Bridge auf einer Schnittstelle eines DLR konfiguriert ist, für die Multicast bereits konfiguriert ist, wird diese Schnittstelle nicht aus den konfigurierten Multicast-Schnittstellen entfernt.

    In der vCenter-Benutzeroberfläche wird die Schnittstelle des DLR, die für Multicast-IGMP und Bridging als Quelle konfiguriert ist, als „getrennt“ angezeigt.

  • Behobenes Problem 2377057 – Die Veröffentlichung von Regeln für verteilte Firewalls verursacht einen Ausfall des NSX Managers aufgrund einer hohen CPU-Auslastung.

    Eine hohe CPU-Auslastung auf dem NSX Manager führt zu Leistungsbeeinträchtigungen.

  • Behobenes Problem 2391802 – VMs verschwinden aus der NSX-Ausschlussliste, wenn neue VMs zur Liste hinzugefügt werden.

    Wenn Sie eine neue VM hinzufügen, bevor die Liste der vorhandenen VMs auf der Ausschlussliste in die Benutzeroberfläche geladen wird, werden die vorhandenen VMs auf der Ausschlussliste entfernt.

  • Behobenes Problem 2389897 – log4j- und log4j2-Konfigurationskonflikt aufgrund der Verwendung von log4j durch Drittanbieterbibliotheken.

    Von NSX generierte Protokolle fehlen in vsm.log. Das Fehlen von NSX-Protokollen erhöht die Schwierigkeit von Debugging-Problemen.

  • Behobenes Problem 2273837: Firewallregeln, die IP Sets, Anwendungen oder Anwendungsgruppen mit dem Bereich „Datencenter“ verwenden, werden nicht angezeigt, wenn NSX auf 6.4.0 oder höher aktualisiert wird.

    Die folgende Fehlermeldung wird in den NSX-Protokollen angezeigt, wenn Firewallregeln ein IP Set, eine Anwendung oder eine Anwendungsgruppe mit dem Bereich „Datencenter“ in NSX 6.4.0 und höher verwenden:
    [Firewall] Ungültige Gruppierungs-ObjectId. Dieses Objekt ist nicht vorhanden oder nicht verfügbar.

  • Behobenes Problem 2319561 – Synchronisierungsfehler auf dem primären NSX Manager.

    Die folgende Fehlermeldung wird in der Benutzeroberfläche und den NSX-Protokollen angezeigt: 
    REST-API fehlgeschlagen: Das uuid-Format von instance_uuid ist ungültig.

  • Behobenes Problem 2327330 – TLS 1.1 ist auf RabbitMQ-Port 5671 aktiviert.

    TLS 1.1-Unterstützung ist aus Gründen der Abwärtskompatibilität vorhanden. Benutzer können TLS 1.1 gezielt entfernen, wenn Sie es nicht benötigen.
    Um TLS 1.1 zu entfernen, bearbeiten Sie die Datei rabbitmq.config unter /etc/rabbitmq/ und starten Sie den Broker auf dem Manager neu.

  • Behobenes Problem 2341214 – Eine Edge-Appliance wird mit aktivierter HA bereitgestellt und alle Kriterien für die HA-Aktivierung sind erfüllt. HA bleibt jedoch auf dem Edge deaktiviert, bis eine zweite Konfigurationsänderung in der Edge-Appliance veröffentlicht wird.

    Wenn ein Edge (ESG/DLR/UDLR) mit aktivierter HA erstellt und Appliances bereitgestellt werden (Massenkonfiguration mit anderen konfigurierten Funktionen), wird die Konfiguration auf Edge-Appliances mit deaktivierter HA veröffentlicht. Die Managementebene zeigt HA als aktiviert an, aber sie ist auf den Edge-Appliances tatsächlich deaktiviert.

  • Behobenes Problem 2392371 – Virtuelle Edge-Appliance kann nicht neu gestartet werden, wenn VMware Tools nicht auf der Edge-Appliance ausgeführt wird.

    Der Neustart der Edge-Appliance kann in einigen Szenarios fehlschlagen. Zum Beispiel bei Aktivierung bzw. Deaktivierung von FIPS, wenn ForceSync auf dem Edge versucht wird, das einen ungültigen Systemstatus meldet.

  • Behobenes Problem 2273242 – Beim Empfangen eines SYN in einer festgelegten Sitzung senden Filter mit NETX keine ACK für diese Verbindung.

    Wenn NetX aktiviert ist, wird das SYN-Paket in einer festgelegten Sitzung an die Dienstinstanz weitergeleitet. TCP-Sitzungen hängen möglicherweise.

  • Behobenes Problem 2285624 – proxy_set schlägt fehl, wenn es von Linux ausgeführt wird.

    Proxy-Unterstützung war auf dem Linux-sslvpn-Client nicht vorhanden.

  • Behobenes Problem 2287017 – ESX zeigt PSOD mit ARP-Stürmen an möglicherweise unbekannten Zielen.

    Mit ARP-Stürmen an unbekannten Zielen zeigt ESX beim Replizieren von Broadcast-ARPs auf viele VMs im Netzwerk PSOD an.

  • Behobenes Problem 2287578 – Das Erfassen von Regelstatistiken führt dazu, dass der verteilte Firewall(DFW)-Datenpfad langsamer wird.

    Wenn eine Regelveröffentlichung oder -statistikerfassung erfolgt, kann eine von der DFW geschützte VM eine herabgestufte VM-Netzwerkleistung aufweisen.

  • Behobenes Problem 2315879 – Mehrere IPSec-Sites mit demselben lokalen Endpoint, Peer-Endpoint und Peer-Subnetz, aber unterschiedlichen lokalen Subnetzen führen dazu, dass Edge keinen Datenverkehr weiterleitet.

    Fehlende Routen oder Routen nicht installiert. Edge leitet keinen Datenverkehr weiter.

  • Behobenes Problem 2329851 – RSA SecureID-Authentifizierung mit Radius für SSLVPN Plus Client schlägt mit der Meldung „internen Seitenfehler“ fehl.

    Nach der Anmeldung auf dem sslvpn-Portal wird der Fehler „Seite nicht gefunden“ angezeigt. RSA mit Radius-Server schlägt fehl.

  • Behobenes Problem 2331796 – Der Wert „HA-Totzeit“ wird in der HA-Konfiguration nicht festgelegt, auch wenn der Wert während der Bereitstellung eines eigenständigen Edge angegeben wird.

    Nach der Bereitstellung des eigenständigen Edge wird in der HA-Konfiguration fälschlicherweise der Wert „HA-Totzeit“ im Feld „HA-Taktsignal-Intervall“ angezeigt. Benutzer können den Wert „HA-Totzeit“ auch nicht mithilfe der Befehlszeilenschnittstelle neu konfigurieren. Stattdessen wird das „HA-Taktsignal-Intervall“ festgelegt.

  • Behobenes Problem 2332763 – Edge-Upgrade auf NSX 6.4.2 oder höher schlägt fehl, wenn die Systemsteuerungseigenschaft „sysctl.net.ipv4.tcp_tw_recycle“ konfiguriert ist.

    Die Veröffentlichung der Edge-Appliance schlägt mit der folgenden Fehlermeldung fehl:
    FEHLER :: VseCommandHandler :: Befehl schließlich fehlgeschlagen. Fehler: [C_UTILS][73001][65280] sysctl net.ipv4.tcp_tw_recycle="0" fehlgeschlagen : sysctl: cannot stat /proc/sys/net/ipv4/tcp_tw_recycle: Datei oder Dateipfad nicht vorhanden.

  • Behobenes Problem 2342497 – VTEPs kann nicht ordnungsgemäß ausgeführt werden, wenn die IP-Hash-Gruppierungsrichtlinie verwendet wird.

    NSX-VTEPs können nicht miteinander kommunizieren.

  • Behobenes Problem 2350465 – Paketverlust und Neustarts des Edge aufgrund unzureichenden Arbeitsspeichers.

    Nicht genügend Arbeitsspeicher in Situationen mit hohem Datenverkehr und wenn IPSec aktiviert ist.

  • Behobenes Problem 2351224 – SSL VPN-Plus Client wird erfolgreich auf einer Linux-Maschine installiert, der Client funktioniert jedoch nicht.

    Net-Tools-Paket fehlt auf der Linux-Maschine.

  • Behobenes Problem 2367084 – Overlay-VMs sind auf einer Bridge nicht von VLAN-gestützten VMs aus erreichbar.

    Wenn sich sowohl die DLR-Kontroll-VM als auch die Overlay-VMs auf demselben ESXi-Host befinden, können VMs in den VLANs ARP-Anforderungen von VMs in den Overlay-Netzwerken nicht auflösen.

  • Behobenes Problem – SynFloodProtection führt dazu, dass die Firewall-Regeln umgangen werden.

    Wenn SynFloodProtection auf dem NSX Edge aktiviert ist, wird die Überprüfung der Firewall-Regel umgangen, wenn der Datenverkehr für das Edge selbst bestimmt ist.

  • Behobenes Problem 2381632 – Statische Routen können in einem DLR nicht hinzugefügt werden, für den keine Edge-Appliance-VM bereitgestellt wurde.

    vSphere Web Client zeigt einen Wert in „admin distance“ für einen DLR an, für den keine Edge-Appliance-VM bereitgestellt ist.

  • Behobenes Problem 2385541 – NSX Edge läuft in Split-Brain-Bedingung, wenn „clear ForceStandby flag“ an die falsche VM gesendet wird.

    Wenn ForceSync versucht und VMs neu gestartet werden, wird „clear ForceStandby“ an eine falsche VM gesendet. Für den entsprechenden Peer wird ForceStandby festgelegt.
    Das Löschen der ForceStandby-Flags schlägt fehl, wodurch die ForceSync-Aufgabe aufgerufen wird. Die VMs werden als Teil des ForceSync-Vorgangs neu gestartet, da das Edge einen Systemfehlerstatus meldet.

  • Behobenes Problem 2385739 – Deadlock in NSX Manager.

    Zookeeper löst Fehler aus, was dazu führt, dass NSX Manager nicht mehr reagiert. Der Replikator löscht und erstellt NSX-Controller auf dem sekundären NSX Manager neu. Deadlock tritt im letzten Schritt auf.

  • Behobenes Problem 2387720 – „Suite-B-GMAC-128“- und „Suite-B-GMAC-256“-Konformitäts-Suites in der IPSec-VPN-Konfiguration bieten keine Datenverschlüsselung.

    Diese Suites verwenden die Null-Verschlüsselung, was sehr unsicher ist. Ab NSX 6.4.6 sind diese beiden Konformitäts-Suites veraltet.

  • Behobenes Problem 2390308 – Bei der Bereitstellung eines FIPS-aktivierten Edge ist nach dem ersten Start ein Neustart erforderlich. Der Neustartvorgang schlägt jedoch manchmal fehl.

    Die folgende Fehlermeldung wird in den NSX-Ereignisprotokollen angezeigt:
    Der Vorgang kann nicht abgeschlossen werden, weil VMware Tools auf dieser virtuellen Maschine nicht ausgeführt wird.

  • Behobenes Problem 2406853 – Beim Hinzufügen einer Trunk-Schnittstelle auf einem Edge ist die standardmäßige MTU-Größe in der Benutzeroberfläche fälschlicherweise auf 1500 festgelegt.

    Der Datenebenenverkehr, der die Edge-Schnittstelle überschreitet, wird aufgrund der reduzierten Standard-MTU-Größe beeinträchtigt.

  • Veraltete Einträge sind in den DLR-Routing-Tabellen in folgenden Situationen vorhanden: dvportgroup wird in logischen DLR-Schnittstellen verwendet, Bridge wird aus vCenter gelöscht, Virtual Distributed Switch wird migriert oder gelöscht.

    DLR-Upgrade schlägt fehl. Erneute Edge-Bereitstellung schlägt fehl, wenn Edge-Upgrade verfügbar ist. Edge-Konfigurationsaktualisierungen schlagen möglicherweise fehl.

  • Behobenes Problem 2412632 – Ein Load-Balancer-Anwendungsprofil des Typs „HTTPS-Ende-zu-Ende“ kann nicht gespeichert werden, ohne dass ein Dienstzertifikat in den Server-SSL-Einstellungen ausgewählt wurde.

    Dieses Problem tritt nach dem Upgrade eines NSX Edge von 6.4.4 auf 6.4.5 auf. Bei NSX 6.4.5 wurde die Auswahl eines Dienstzertifikats bei der Angabe der Server-SSL-Einstellungen als obligatorisch festgelegt.

  • Behobenes Problem 2314438 – Synchronisierungsprobleme beim primären NSX Manager mit Fehler „REST-API fehlgeschlagen: Das uuid-Format von instance_uuid ist ungültig“.

    Bestimmte VMs werden in einer Multi-VC-Umgebung nicht auf sekundäre repliziert, obwohl Sie mit globalen Tags auf der primären VM getaggt sind.

  • Behobenes Problem VMSA-2019-0010 – Linux-Kernel-Schwachstellen in der TCP-selektiven Bestätigung (SACK) CVE-2019-11477, CVE-2019-11478

    Alle NSX-V 6.4.6-Komponenten enthalten den Fix für Linux-Kernel-Schwachstellen in der TCP-selektiven Bestätigung (SACK) CVE-2019-11477, CVE-2019-11478. Kunden können für die oben erwähnten CVE-Versionen ein Upgrade auf 6.4.6 und höhere Versionen durchführen. KB-Artikel 71311 enthält zusätzliche Informationen zu diesem Problem.

  • Behobenes Problem 2324338: Wenn die DFW-Regel konfiguriert ist, die eine effektive vNIC mit IPv4- und IPv6-Adressen hat, löschen Updates bei einem der Adresstypen auch andere IP-Adressen, was dazu führt, dass die entsprechende DFW-Regel ein unerwartetes Verhalten aufweist.

    Jede Änderung eines IP-Adresstyps überschreibt beide vorhandenen IP-Adresstypen. Wenn eine Aktualisierung erfolgt, die nur eine IPv6-Adresse beinhaltet, wird der DB-Datensatz aktualisiert und sowohl die vorhandene IPv4- als auch die IPv6-Adresse werden nur durch die neue IPv6-Adresse ersetzt.

Bekannte Probleme

Die bekannten Probleme gliedern sich in folgende Gruppen.

Bekannte Installations- und Upgrade-Probleme

Bevor Sie das Upgrade durchführen, lesen Sie den Abschnitt Upgrade-Hinweise weiter oben in diesem Dokument.

  • Problem 1859572 – Bei der Deinstallation von NSX-VIBs der Version 6.3.x auf ESXi-Hosts, die von vCenter Version 6.0.0 verwaltet werden, verbleibt der Host im Wartungsmodus.
    Wenn Sie die NSX-VIBs der Version 6.3.x auf einem Cluster deinstallieren, gehört zum Workflow das Versetzen der Hosts in den Wartungsmodus, das Deinstallieren der VIBs und das anschließende Beenden des Wartungsmodus für die Hosts durch den EAM-Dienst. Wenn jedoch solche Hosts von vCenter Server Version 6.0.0 verwaltet werden, führt dies dazu, dass die Hosts nach der Deinstallation der VIBs im Wartungsmodus verbleiben. Der für die Deinstallation der VIBs vorgesehene EAM-Dienst versetzt die Hosts in den Wartungsmodus, ist aber nicht in der Lage, den Wartungsmodus für die Hosts wieder zu deaktivieren.

    Problemumgehung: Beenden Sie den Wartungsmodus für die Hosts manuell. Dieses Problem tritt nicht auf, wenn Hosts mit vCenter Server Version 6.5a und höher verwaltet werden.

  • Problem 1263858 – SSL VPN sendet keine Upgrade-Benachrichtigung an den Remoteclient.

    SSL VPN-Gateway sendet keine Upgrade-Benachrichtigung an Benutzer. Der Administrator muss Remotebenutzern manuell mitteilen, dass das SSL VPN-Gateway (Server) aktualisiert wurde, und sie bitten, ihre Clients zu aktualisieren.

    Problemumgehung: Benutzer müssen die ältere Version des Client deinstallieren und die neuste Version manuell installieren.

  • Problem 2006028 – Host-Upgrade schlägt möglicherweise fehl, wenn das vCenter Server-System während des Upgrades neu gestartet wird.

    Wenn das zugeordnete vCenter Server-System im Verlauf eines Host-Upgrades neu gestartet wird, schlägt das Host-Upgrade möglicherweise fehl und der Host verbleibt im Wartungsmodus. Auch das Klicken auf „Auflösen“ beendet nicht den Wartungsmodus für den Host. Der Clusterstatus lautet „Nicht bereit“.

    Problemumgehung: Beenden Sie den Wartungsmodus für den Host manuell. Klicken Sie auf „Nicht bereit“ und dann auf dem Cluster auf „Alle auflösen“.

  • Problem 2429861: End2End-Latenz wird auf der vRNI-Benutzeroberfläche nach dem Upgrade auf NSX Version 6.4.6 nicht mehr angezeigt.

    End2End-Latenz wird mit vRNI-Interoperabilität für vRNI 4.2 und vRNI 5.0 verringert.

    Problemumgehung: Aktualisieren Sie vRNI auf 5.0.0-P2.

  • Problem 2449643: Der vSphere Web Client zeigt nach dem Upgrade von NSX 6.4.1 auf 6.4.6 den Fehler „Kein NSX Manager verfügbar“ an.

    In vSphere Web Client wird auf den Seiten „Firewall“ und „Logischer Switch“ die folgende Fehlermeldung angezeigt:
    „Kein NSX Manager verfügbar. Vergewissern Sie sich, dass dem aktuellen Benutzer auf NSX Manager eine Rolle zugewiesen wurde.“

    Da die Seiten „Firewall“ und „Logischer Switch“ auf der Benutzeroberfläche nicht verfügbar sind, können Benutzer möglicherweise keine Firewallregeln konfigurieren oder logische Switches erstellen. Außerdem antworten NSX APIs nur sehr langsam.

    In der Datei /usr/nsx-webserver/logs/localhost_access_log befinden sich Einträge wie die folgenden:
    127.0.0.1 - - [27/Oct/2019:08:38:22 +0100] "GET /api/4.0/firewall/globalroot-0/config HTTP/1.1" 200 1514314 91262
    127.0.0.1 - - [27/Oct/2019:08:43:21 +0100] "GET /api/4.0/firewall/globalroot-0/config HTTP/1.1" 200 1514314 90832

    127.0.0.1 - - [27/Oct/2019:11:07:39 +0100] "POST /remote/api/VdnInventoryFacade HTTP/1.1" 200 62817 264142
    127.0.0.1 - - [27/Oct/2019:11:07:40 +0100] "POST /remote/api/VdnInventoryFacade HTTP/1.1" 200 62817 265023
    127.0.0.1 - - [27/Oct/2019:11:07:40 +0100] "POST /remote/api/VdnInventoryFacade HTTP/1.1" 200 62817 265265

    Problemumgehung:

    Benennen Sie die Dateien log4j-1.2.14.jar und log4j-1.2.17.jar manuell um und starten Sie den bluelane-manager-Dienst neu.

    1. Melden Sie sich bei der NSX Manager-CLI als root-Benutzer an.

    2. Führen Sie die folgenden Befehle aus, um die .jar-Dateien umzubenennen:

    /home/secureall/secureall/sem/WEB-INF/lib]# mv log4j-1.2.17.jar log4j-1.2.17.jar.old
    /home/secureall/secureall/sem/WEB-INF/lib]# mv log4j-1.2.14.jar log4j-1.2.14.jar.old

    3. Starten Sie den bluelane-manager-Dienst neu, indem Sie den folgenden Befehl ausführen:

    /etc/init.d/bluelane-manager restart

Bekannte Probleme bei NSX Manager
  • Problem 2233029 – ESX unterstützt 10K-Routen nicht.

    ESX muss keine 10.000 Routen unterstützen. Designbedingt liegt der maximale Grenzwert für ESX bei 2.000 Routen.

    Problemumgehung: Keine.

  • Problem 2391153 – NSX Manager aktualisiert die vdn_vmknic_portgroup- und vdn_cluster-Tabelle nicht, nachdem vCenter-Vorgänge auf vmknic dvportgroup durchgeführt wurden.

    Wenn Sie die PUT-API-Anforderung https://nsx_manager_ip/api/2.0/nwfabric/configure ausführen, aktualisiert NSX Manager die vdn_vmknic_portgroup- und die vdn_cluster-Tabelle nicht, nachdem vCenter-Vorgänge auf „vmknic distributed virtual portgroup“ durchgeführt wurden. Die vCenter-Benutzeroberfläche zeigt weiterhin die alte VLAN-ID an. 

    Problemumgehung: Keine

  • Problem 2445396: Die Pool-Ports des Load Balancers werden gelöscht, wenn der Load Balancer-Pool nach dem Bearbeiten gespeichert wird.

    Beim Bearbeiten des Load Balancer-Pools und beim Speichern der Konfiguration werden die Portnummern aller Mitglieder gelöscht.

Allgemeine bekannte Probleme
  • Wenn Sie in vSphere Web Client eine Flex-Komponente öffnen, die eine HTML-Ansicht überlagert, ist die Ansicht nicht sichtbar

    Wenn Sie eine Flex-Komponente, z. B. ein Menü oder ein Dialogfeld, öffnen, die eine HTML-Ansicht überlagert, wird die Ansicht vorübergehend ausgeblendet.
    (Referenz: http://pubs.vmware.com/Release_Notes/en/developer/webclient/60/vwcsdk_600_releasenotes.html#issues)

    Problemumgehung: Keine. 

  • Problem 2367906: Die CPU-Nutzung auf dem NSX Edge erreicht 100 %, wenn die HTTP-Dienstüberwachung beim Load Balancer mit der Erweiterung „no-body“ konfiguriert ist.

    Dieses Problem tritt auf, wenn Sie die HTTP-Dienstüberwachung mit einer „no-body“-Erweiterung konfigurieren, während Sie das „nagios“-Plug-in beim Load Balancer (NSX-specific) verwenden. Der Load Balancer verliert die Verbindung mit allen Back-End-Servern und die Anforderung des Benutzers wird unterbrochen.

    Problemumgehung: Weitere Informationen finden Sie im KB-Artikel 71168.

  • Problem 2551523: Die Veröffentlichung einer neuen Regel schlägt möglicherweise fehl, wenn die Regel eine IP mit vier Nullen (0.0.0.0/0) enthält, nachdem ein Upgrade von NSX-v 6.3.x auf NSX-v 6.4.6 durchgeführt wurde.

    Die Veröffentlichung einer neuen Regel schlägt möglicherweise fehl, wenn die Regel eine IP mit vier Nullen (0.0.0.0/0) enthält, nachdem ein Upgrade von NSX-v 6.3.x auf NSX-v 6.4.6 durchgeführt wurde.

    Problemumgehung: Geben Sie für „0.0.0.0/0“ in der Quelle oder im Ziel „Alle“ an.

  • Problem 2536058: Lange API-Reaktionszeit von NSX Manager für „get flowstats“-APIs.

    Beim Abfragen der Firewallkonfiguration und IPSets ist die Reaktionszeit für diese APIs lang.

  • Problem 2513773: IDFW-Regeln werden nicht auf VDIs angewendet, nachdem deren Sicherheitsgruppen während der Sitzung entfernt wurden.

    VDI-Sitzungen werden zufällig verworfen, weil die an die IDFW-Regeln angehängten Sicherheitsgruppen entfernt wurden.

    Problemumgehung: Lösen Sie eine weitere manuelle Synchronisierung aus.

  • Problem 2509224: Eine übermäßig große Flowtabelle auf NSX Edge in Hochverfügbarkeit führt zu Verbindungsabbrüchen.

    Wenn eine übergroße Verbindungsnachverfolgungstabelle vom Standby-NSX Edge zum aktiven NSX Edge synchronisiert wird, werden neue Verbindungen verworfen.

    Problemumgehung: Keine.

  • Problem 2502739: Lange API-Reaktionszeit von NSX Manager für FW- und IPSet-APIs.

    Beim Abfragen von Firewallkonfiguration und IPSets ist die Reaktionszeit für diese APIs lang.

    Problemumgehung: Keine.

  • Problem 2498988: Die Reaktionszeit ist lang, wenn Gruppierungsobjekte abgefragt werden.

    Beim Abfragen von Gruppierungsobjekten ist die Reaktionszeit für diese APIs lang.

  • Problem 2458746: Nicht unterstützte LIF-Konfigurationen haben auf mehreren Hosts zum PSOD geführt.

    Hostvalidierungen wurden implementiert, um das Hinzufügen doppelter LIFs über verschiedene DLRs zu verhindern.

    Problemumgehung: Stellen Sie sicher, dass die virtuelle Leitung nicht in zwei verschiedenen DLRs vorhanden ist, indem Sie eine davon löschen.

  • Problem 2452833: Auf einem ESXi-Host, der eine DLR-Kontroll-VM bedient, kann ein PSOD auftreten, wenn sowohl beim Bridging als auch als LIF in zwei verschiedenen DLRs dasselbe VXLAN verwendet wird.

    Ein ESXi, der die DLR-Kontroll-VM bedient, kann PSOD verwenden, wenn für Bridging und als LIF dieselbe virtuelle Leitung verbraucht wird.

    Problemumgehung: Warten Sie, bis die aktuelle Aufgabe erfolgreich verlaufen ist, und stellen Sie sicher, dass es keine ausstehenden Aufträge gibt, bevor Sie zur Konfiguration auf einem anderen Edge übergehen.

  • Problem 2451586: LB-Anwendungsregeln funktionieren nach dem Upgrade von NSX auf 6.4.6 nicht.

    Wenn sich HTTP(S)-Back-End-Server als Teil von NSX Edge hinter einem NSX-Load Balancer befinden, kommunizieren die Clients über den Load Balancer mit den Back-End-Servern. Der Load Balancer sendet Header in Kleinbuchstaben, obwohl diese vom Server in Groß-/Kleinschreibung gesendet wurden.

  • Problem 2448449: Anwendungsregeln, die mit req_ssl_sni konfiguriert wurden, schlagen beim Upgrade auf NSX for vSphere 6.4.6 möglicherweise mit einem Analysefehler fehl.

    Wenn beim Upgrade auf NSX for vSphere 6.4.6 ein Load Balancer mit einer mit SNI verbundenen Regel konfiguriert ist oder wenn Sie eine neue mit SNI verbundene Regel in dieser Version erstellen oder konfigurieren, tritt möglicherweise ein Problem auf, weswegen das Upgrade oder das Erstellen der zugehörigen Regel fehlschlägt.

    Problemumgehung: Weitere Informationen hierzu finden Sie im VMware-Knowledgebase-Artikel 75281.

  • Problem 2444275: Auf dem Host tritt ein PSOD auf, wenn die Funktion für die Latenz der virtuellen Infrastruktur aktiviert ist.

    Auf dem ESXi-Host tritt ein PSOD auf, wenn die Funktion für die Latenz der virtuellen Infrastruktur in VRNI in einer Umgebung mit mehr als 975 BFD-Tunneln pro Host aktiviert ist. In einer Skalierungsumgebung kommt es auf dem ESXi-Host zum PSOD, wenn die Latenz aktiviert ist.

    Problemumgehung: Deaktivieren Sie in einer Skalierungsumgebung die Latenz-/Heatmap-Funktion.

  • Problem 2493095: Die Unterstützung von durch Kommas getrennten IP-Listen in der DFW wurde von der Benutzeroberfläche und aus der Datenbank entfernt.

    Nach dem Upgrade früherer Versionen von NSX-v auf NSX-v 6.4.6 wurde die kommagetrennte IP-Liste in der DFW entfernt.

  • Problem 2459936: Das Netzwerk kann nicht in zwei Teile aufgeteilt werden, indem statische Routen mit Netzwerk 0.0.0.0/1 und 128.0.0.0/1 verwendet werden.

    Mit Netzwerk 0.0.0.0/0 ist nur eine statische Route erlaubt.

    Problemumgehung: Keine.

  • Problem 2448235: Nach dem Upgrade auf NSX-v 6.4.6 können Sie Firewallregeln möglicherweise nicht nach Protokoll, Quellport und Zielport filtern.

    Sie können Firewallregeln nicht mit den Filtern für Protokoll, Quellport, Zielport filtern.

  • Problem 2445183: NSX Manager wird in vSphere Web Client nicht angezeigt, nachdem das SSL-Zertifikat von NSX Manager ersetzt wurde.

    Nach dem Ersetzen des SSL-Zertifikats von NSX Manager wird NSX Manager auf dem vSphere Web Client nicht angezeigt.

    Problemumgehung: Weitere Informationen hierzu finden Sie im VMware-Knowledgebase-Artikel 76129.

Bekannte Probleme bei der Lösungsinteroperabilität
    check-circle-line exclamation-circle-line close-line
    Scroll to top icon