| VMware NSX for vSphere 6.4.1 | Veröffentlicht am Donnerstag, 24. Mai 2018 | Build 8599035 Siehe den Revisionsverlauf dieses Dokuments. |
Inhalt dieser Versionshinweise
Diese Versionshinweise decken die folgenden Themen ab:
- Neuigkeiten in NSX 6.4.1
- Versionen, Systemanforderungen und Installation
- Eingestellte und nicht fortgeführte Funktionalität
- Upgrade-Hinweise
- FIPS-Konformität
- Revisionsverlauf
- Behobene Probleme
- Bekannte Probleme
Neuigkeiten in NSX 6.4.1
In NSX for vSphere 6.4.1 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 for vSphere 6.4.1:
Sicherheitsdienste
- Kontextbezogene Firewall:
- Zusätzliche Unterstützung für Anwendungskontext auf Ebene 7: SYMUPD (Symantec LiveUpdate-Datenverkehr, einschließlich Spywaredefinitionen, Firewallregeln, Antiviren-Signaturdateien und Software-Aktualisierungen), MAXDB (SQL-Verbindungen und -Anfragen an einen MaxDB-SQL-Server) und GITHUB (webbasiertes Git oder Repository für Versionskontrolle und Internethostingdienst).
- Erweiterte Betriebssystemunterstützung für identitätsbasierte Firewall: Die Unterstützung der identitätsbasierten Firewall für Benutzersitzungen auf Remote-Desktops und Anwendungsservern (RDSH) wurde nun auf Windows Server 2012 mit VMware Tools 10.2.5 und Windows 2012 R2 mit VMware Tools 10.2.5 erweitert.
NSX-Benutzeroberfläche
- VMware NSX – Funktionalitätsaktualisierungen für vSphere Client (HTML):
- Die folgenden VMware NSX-Funktionen sind jetzt über den vSphere Client verfügbar: Installation, Gruppen und Tags, Firewall, Service Composer, Application Rule Manager, SpoofGuard, IPFIX, Flow Monitoring Eine Liste der unterstützten Funktionalität finden Sie unter VMware NSX for vSphere-UI-Plug-In-Funktionalität im vSphere Client.
- Firewall – Verbesserungen an der Benutzeroberfläche:
- Verbesserte Transparenz: Statusübersicht, Aktionssymbolleiste, Ansicht mit Gruppenmitgliedschaftsdetails in der Firewalltabelle
- Effiziente Regelerstellung: Inline-Bearbeitung, Klonen von Regeln, Unterstützung für Mehrfachauswahl und Massenaktionen, vereinfachte Regelkonfiguration
- Effiziente Abschnittsverwaltung: Drag & Drop, positionsgenaues Einfügen von Abschnitten und Regeln, Abschnittsverankerungen beim Blättern
- Vorgänge für Rückgängigmachung: Umkehren nicht veröffentlichter Regel- und Abschnittsänderungen in Benutzeroberfläche auf Clientseite
- Zeitüberschreitungseinstellungen für Firewall: Protokollwerte sind auf einen Blick ganz ohne Popupdialogfelder einsehbar.
- Application Rule Manager – Verbesserungen an der Benutzeroberfläche:
- Sitzungsverwaltung: Zeigen Sie eine Sitzungsliste mit Angaben zu Status (Datenerfassung, Analyse abgeschlossen) und Dauer der einzelnen Sitzungen an.
- Regelplanung: Zeigen Sie die Anzahl von Gruppierungsobjekten und Firewallregeln zusammenfassend an und zeigen Sie Empfehlungen für universelle Firewallregeln an.
- Verbesserungen bei Gruppierungsobjekten:
- Dank verbesserter Transparenz können Sie einsehen, wo Gruppierungsobjekte verwendet werden.
- Zeigen Sie eine Liste effektiver Gruppenmitglieder im Hinblick auf VMs, IP, MAC und vNIC an.
- SpoofGuard – Verbesserungen an der Benutzeroberfläche:
- Unterstützung für Massenaktionen: Genehmigen oder löschen Sie gleichzeitig mehrere IPs.
NSX Edge-Verbesserungen
- Skalierung für den Lastausgleichsdienst: Erweiterte Unterstützung für Lastausgleichsdienst-Poolmitglieder (Anstieg von 32 auf 256)
Operationen und Fehlerbehebung
- Installation – Verbesserungen an der Benutzeroberfläche:
- Filtern der Clusterliste nach Status: Alle, Installiert: Fehlerfreier Zustand, Installiert: Benutzereingriff erforderlich, Nicht installiert
- Zusammenfassungsansicht für Cluster: Zeigt Integritätsstatus von Kommunikationskanal.
- Alarme bei Ablauf von Zertifikaten: Systemereignisse und SNMP-Warnungen werden vor und bei Ablauf eines Zertifikats generiert. Das Zeitintervall ist konfigurierbar. Standardmäßig sind sieben Tage vor Ablauf eingestellt.
- Automatische Sicherung vor Upgrades: 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 und Verwalten von NSX Manager-Sicherungen, die während eines Upgrades erstellt werden.
Lösungsinteroperabilität
- vSphere 6.7-Unterstützung: Wenn Sie ein Upgrade auf vSphere 6.7 durchführen möchten, müssen Sie zuerst eine Installation von bzw. ein Upgrade auf NSX for vSphere 6.4.1 oder höher vornehmen. Weitere Informationen finden Sie unter Upgrade von vSphere in einer NSX-Umgebung im Upgrade-Handbuch für NSX sowie im Knowledgebase-Artikel 53710 (Aktualisierungssequenz für vSphere 6.7 und dessen kompatible VMware-Produkte).
NSX-Lizenzeditionen
- VMware NSX Data Center-Lizenzen: Bietet Unterstützung für neue VMware NSX Data Center-Lizenzen (Standard, Professional, Advanced, Enterprise Plus, Remote Office Branch Office), die im Juni 2018 eingeführt wurden, und unterstützt weiterhin die vorherigen Lizenzschlüssel für VMware NSX for vSphere. Weitere Informationen zu NSX-Lizenzen finden Sie im VMware-Knowledgebase-Artikel 2145269.
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 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 NSX-Versionshinweise 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 |
Hinweis: vSphere 5.5 wird mit NSX 6.4 nicht unterstützt. |
| Guest Introspection für Windows | Es werden alle Versionen von VMware Tools unterstützt. Für einige Guest Introspection-basierte Funktionen sind neuere Versionen von VMware Tools erforderlich:
|
| Guest Introspection für Linux | Diese NSX-Version unterstützt die folgenden Linux-Versionen:
|
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 nach dem Upgrade 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.
Entfernung von Elementen und Änderungen an der Benutzeroberfläche
In NSX 6.4.1 wurde die Service Composer-Arbeitsfläche entfernt.
Entfernung von APIs und Änderungen des Verhaltens
Ä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/statusist veraltet. GET /api/2.0/services/policy/serviceprovider/firewall/ist veraltet. Verwenden Sie stattdessenGET /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/controllerdie 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 Antwort202 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 im Abschnitt 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 6.4: NSX 6.4 ist nicht mit vSphere 5.5 kompatibel.
- 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:
- Suchen Sie unter https://<nsxmanager>/bin/vdn/nwfabric.properties nach der neuen VIB-URL.
- Rufen Sie die VIBs der erforderlichen ESX-Hostversion über die jeweilige URL ab.
- Fügen Sie sie zu einem Image-Profil hinzu.
Upgrade-Hinweise für NSX-Komponenten
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.
Upgrade des Distributed Logical Routers
- Die Validierung wurde in NSX 6.4.1 hinzugefügt, um sicherzustellen, dass in Umgebungen, in denen VXLAN konfiguriert ist und mehr als ein vSphere Distributed Switch vorhanden ist, 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. Der nicht unterstützte vSphere Distributed Switch wird von der Benutzeroberfläche nicht mehr angezeigt.
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
-
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
FormfaktorCPU-Reservierung Arbeitsspeicherreservierung KOMPAKT 1000 MHz 512 MB GROSS 2000 MHz 1024 MB QUADLARGE 4000 MHz 2048 MB X-LARGE 6000 MHz 8192 MB -
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.
-
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" }
Upgrade für Guest Introspection
- Guest Introspection-VMs enthalten nun zusätzliche Informationen über die Hostidentität in einer XML-Datei auf der Maschine. Bei der Anmeldung bei der Guest Introspection-VM sollte die Datei „/opt/vmware/etc/vami/ovfEnv.xml“ Informationen über die Hostidentität enthalten.
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
24. Mai 2018: Erste Auflage.
29. Mai 2018: Zweite Auflage. Bekanntes Problem 2127813 wurde hinzugefügt.
8. Juni 2018: Dritte Auflage. Informationen zu NSX Data Center-Lizenzen hinzugefügt, bekanntes Problem 2130563 hinzugefügt.
20. Juli 2018: Vierte Auflage. Bekanntes Problem 2147002 wurde hinzugefügt.
5. September 2018: Fünfte Auflage. Die bekannten Probleme 2186968 und 2183584 wurden hinzugefügt.
19. September 2018: Sechste Auflage. Bekanntes Problem 2197754 und zugehöriger Hinweis wurden zu Tabelle mit den Systemanforderungen hinzugefügt.
5. Oktober 2018: Siebte Auflage. Bekanntes Problem 2164138 wurde hinzugefügt.
Behobene Probleme
Die behobenen Probleme werden in die im Folgenden aufgeführten Kategorien unterteilt.
- Allgemeine behobene Probleme
- Behobene Probleme bei logischen Netzwerken und NSX Edge
- Behobene Probleme beim NSX Manager
- Behobene Probleme bei Sicherheitsdiensten
- Behobene Installations- und Upgrade-Probleme
- Behobenes Problem 1993691, 1995142: Host wird nach dem Entfernen aus der vCenter-Bestandsliste nicht vom Replizierungscluster entfernt
Wenn ein Benutzer einen Host zu einem Replizierungscluster hinzufügt und den Host dann aus der vCenter-Bestandsliste entfernt, bevor er vom Cluster entfernt wurde, verbleibt der Legacyhost im Cluster.
- Behobenes Problem 1809387: Unterstützung für TLS v1.0 – schwaches Protokoll für sicheren Transport – wurde entfernt
Ab NSX-v 6.4.1 wird TLS v1.0 nicht mehr unterstützt.
- Behobenes Problem 2002679: In einer Cross vCenter NSX-Umgebung, in der HW-VTEP in der primären Site bereitgestellt wurde, kann es für überbrückten Datenverkehr zu einem Netzwerkausfall kommen, wenn der sekundäre NSX Manager neu startet.
In einer Cross vCenter NSX-Umgebung, in der HW-VTEP in der primären Site bereitgestellt wurde, kann es für überbrückten Datenverkehr zu einem Netzwerkausfall kommen, wenn der sekundäre NSX Manager neu startet.
- Behobenes Problem 2065225: NSX Guest Introspection-Installation schlägt in einer NSX 6.4.0-Umgebung mit der folgenden Fehlermeldung fehl: „a specified parameter is not correct Property.info.key[9]“
GI-Bereitstellungen zeigen den Installationsstatus als fehlgeschlagen und den Dienststatus für mehrere Hosts als unbekannt an.
- Behobenes Problem 2094364: USVM-Prozess konnte nach einem Prozessabsturz nicht neu gestartet werden, da der Watchdog-Prozess den USVM-Prozess nicht neu starten konnte.
Die USVM wird nach Beendigung des Prozesses in einen Warnzustand versetzt.
- Behobenes Problem 2105632: USVMs versuchen eine Zeitsynchronisierung mit Google-NTP-Servern (extern).
Der Dienst für die Zeitsynchronisierung wurde geändert, um dieses Verhalten zu verhindern.
- Behobenes Problem 2031099: NSX-Hostvorbereitung schlägt mit einem EAM-Fehler fehl: „Host is no longer in vCenter inventory“
Weitere Informationen dazu enthält der VMware-Knowledgebase-Artikel 52550.
- Behobenes Problem 2064298: Tech-Support-Protokolle können nicht heruntergeladen werden, wenn der Monat einen Buchstaben mit Akzent enthält
Wenn NSX Manager die französische Version verwendet, können die Tech-Support-Protokolle in Monaten mit Akzent im kurzen Monatsnamen nicht heruntergeladen werden.
- Behobenes Problem 2017141: Zertifikat des globalen Geltungsbereichs (globalroot-0) ist nicht für Benutzer des Edge-Geltungsbereichs zugänglich
Die folgende Fehlermeldung wird angezeigt, wenn Benutzer des Edge-Geltungsbereichs versuchen, auf eine Edge-Lastausgleichsfunktion zuzugreifen:
"Benutzer ist nicht dazu berechtigt, auf das Objekt "Global" und die Funktion "truststore.trustentity_management" zuzugreifen. Überprüfen Sie den
Geltungsbereich für den Objektzugriff und die Funktionsberechtigungen für den Benutzer."
- Behobenes Problem 1907141: Akzeptieren von GARP als gültige Antwort beim Senden einer ARP-Anforderung
Einige alte Geräte senden GARP als Antwort auf eine ARP-Anforderung. Die Korrektur geht auf das Akzeptieren von GARP als gültige ARP-Antwort ein.
- Behobenes Problem 2039443: Wenn ein DLR ohne Schnittstellen erstellt wird, wird die DLR-Instanz nicht auf dem Host erstellt, doch die Kontroll-VM versucht trotzdem, eine Verbindung mit dem Host herzustellen
Wenn ein DLR ohne LIFs erstellt wird, wird die VDR-Instanz nicht auf dem Host erstellt. In einer solchen Konfiguration versucht die DLR-Kontroll-VM, eine VMCI-Verbindung herzustellen, was fehlschlägt. Dieses Problem wirkt sich nicht auf den Datenpfad aus und kann ignoriert werden.
- Behobenes Problem 2070281: Langsamer Arbeitsspeicherverlust bei aktivierter DNS-Funktion und Fehlschlagen der Namensauflösung mit Fehlermeldungen zu nicht erreichbarem Netzwerk
Edge-Protokolle enthalten Fehlermeldungen zur Namensauflösung. Nach einiger Zeit zeigen Systemereignisse an, dass die Arbeitsspeichernutzung der Edge-VMs hoch ist (> 90 % Nutzung).
- Behobenes Problem 2084281: VPN-Tunnel wird nicht gestartet, wenn Datenverkehr hinter dem ESG initiiert wird, nachdem ein VPN-Leerlauftimeout abgelaufen ist
VPN-Tunnel bleibt aufgrund fehlerhafter Logik inaktiv, die die spd-Einträge von IPSEC gelöscht hat.
- Behobenes Problem 2092730: NSX Edge reagiert bei 100 % Festplattenauslastung nicht mehr mit der Partition /var/log
/var/log des NSX Edge Gateway füllt sich auf aktivem Edge.
- Behobenes Problem 1984392: Globale Objekte (Transportzone, UDLR, ULS und Segmente) werden nicht mit sekundärem NSX Manager synchronisiert
Die Replikator-Threads, die Daten auf dem sekundären NSX Manager replizieren, sind hängen geblieben und können keine neuen Anforderungen verarbeiten.
- Behobenes Problem 2064258: Überprüfung des NetBIOS-Namens fehlgeschlagen
In 6.4.0 wurde ein neuer Parameter in die Synchronisierungsfunktion für Domänen aufgenommen. Bei diesem Parameter handelt es sich um den NetBIOS-Namen, der vom NSX-Back-End überprüft wird. In bestimmten AD-Strukturen, z. B. bei speziellen Vertrauenskonfigurationen in Nichtstammdomänen (als Vertrauensstellungsabkürzung bekannt), in denen es sich bei der Vertrauensstellung zwischen Stammdomäne und Nichtstammdomäne um den Strukturstamm handelt, schlägt die Überprüfung des NetBIOS-Namens fehl.
- Behobenes Problem 1971683: NSX Manager protokolliert falsche Nachricht zu doppelten IPs
Erweiterte Protokollierung für falsch positive Ergebnisse.
- Behobenes Problem 2085654: Wenn im selben Satz doppelte dynamische Kriterien vorliegen (insbesondere mit Wert = null), schlägt das Upgrade der dynamischen Kriterien fehl
Starten von NSX Manager schlägt nach dem Upgrade fehl. NSX kann nach dem Upgrade nicht verwaltet werden.
- Behobenes Problem 1991702: Fehlermeldung „Unable to start data collection on SG with no VMs“ wird unter bestimmten Bedingungen angezeigt
Beim Starten einer Endpunktüberwachungssitzung auf einem identitätsbasierten SG, das einer AD-Gruppe zugeordnet ist, wird eine Fehlermeldung angezeigt: „Unable to start data collection on SG with no VMs“
- Behobenes Problem 2052634: Übersetzung geschachtelter Sicherheitsgruppen mit ausgeschlossenen Mitgliedern gibt falsches Ergebnis zurück
Firewallregel blockiert Datenverkehr fälschlicherweise oder lässt diesen fälschlicherweise zu, wenn Sicherheitsgruppen mit Schachtelung und ausgeschlossenen Mitgliedern verwendet werden.
- Behobenes Problem 2089957: VM-Übersetzung gibt NULL-Zeiger-Ausnahme für eine Sicherheitsgruppe aus, die über eine Referenz zu einer gelöschten AD-Gruppe verfügt
Wenn eine AD-Gruppe gelöscht wird und eine Sicherheitsgruppe mit Referenz auf die gelöschte AD-Gruppe vorhanden ist, gibt die Übersetzung Sicherheitsgruppe->VM eine NULL-Zeiger-Ausnahme aus. Die Regelveröffentlichung schlägt fehl.
- Behobenes Problem 2035026: Netzwerkausfall von etwa 40 bis 50 Sekunden während Edge-Upgrade
Der Netzwerkausfall bei Edge-Upgrades wird auf 10 bis 20 Sekunden reduziert.
- Behobenes Problem 2027916: Der Upgrade-Koordinator zeigt möglicherweise an, dass Controller mit fehlgeschlagenem Upgrade erfolgreich aktualisiert wurden.
Wenn bei einem Controller-Cluster mit drei Knoten der dritte Controller beim Upgrade fehlgeschlagen ist und entfernt wird, wird das gesamte Upgrade des Controller-Clusters möglicherweise als erfolgreich gekennzeichnet, obwohl das Upgrade fehlgeschlagen ist.
Bekannte Probleme
Die bekannten Probleme gliedern sich in folgende Gruppen.
- Allgemeine bekannte Probleme
- Bekannte Installations- und Upgrade-Probleme
- Bekannte Probleme bei NSX Manager
- Probleme bei logischen Netzwerken und NSX Edge
- Bekannte Probleme bei Sicherheitsdiensten
- Bekannte Probleme bei Überwachungsdiensten
- Problem 2197754: Hosts zeigen violetten Diagnosebildschirm, wenn vSphere Distributed Switch auf 6.6 aktualisiert wird
Wenn Sie NSX 6.4 installiert haben und ein Upgrade für vSphere Distributed Switches auf Version 6.6 durchführen, zeigt ESXi einen violetten Diagnosebildschirm an. Neue Installationen von vSphere 6.7 mit vSphere Distributed Switch 6.6 sind davon nicht betroffen.
Problemumgehung: Verwenden Sie vSphere Distributed Switch Version 6.5 oder früher beim Upgrade auf vSphere 6.7.
- Problem 2130563: Beim Zuweisen einer NSX Data Center-Lizenz wird eine Warnmeldung angezeigt: „Die ausgewählte Lizenz unterstützt einige der Funktionen nicht, die den lizenzierten Assets aktuell zur Verfügung stehen.“
Wenn Sie eine NSX for vSphere-Lizenz zugewiesen haben und anschließend eine NSX Data Center-Lizenz zuweisen, erhalten Sie die folgende Warnmeldung: „Die ausgewählte Lizenz unterstützt einige der Funktionen nicht, die den lizenzierten Assets aktuell zur Verfügung stehen.“ Dies liegt daran, dass die beiden Lizenzen die NSX-Funktionen unterschiedlich definieren. Wenn Sie eine Lizenzedition zuweisen, die sich auf die gleichen Funktionen wie Ihre aktuelle Lizenz bezieht, können Sie diese Meldung ignorieren.
Weitere Informationen zu NSX-Lizenzen finden Sie im VMware-Knowledgebase-Artikel 2145269.
Problemumgehung: Stellen Sie sicher, dass die neue Lizenz die Funktion unterstützt, die Sie benötigen, und ignorieren Sie die Warnmeldung.
- Problem 2127813: NSX-Lizenzschlüssel kann nicht ausgewählt und NSX Manager zugewiesen werden, während vSphere Client (HTML5) verwendet wird
Wenn Sie sich beim vSphere Client (HTML5) anmelden und einen NSX-Lizenzschlüssel hinzufügen, können Sie den Schlüssel nicht aus Lizenzen > Assets > Lösungen zuweisen. Der neue Lizenzschlüssel ist nicht sichtbar.
Problemumgehung: Verwenden Sie den vSphere Web Client, um Lizenzen hinzuzufügen und zuzuweisen.
- 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 1874863: Fehler bei der Authentifizierung mit einem geänderten Kennwort nach der Deaktivierung/Aktivierung des SSL VPN-Dienstes bei einem lokalen Authentifizierungsserver
Wenn der SSL VPN-Dienst bei Verwendung einer lokalen Authentifizierung deaktiviert und dann wieder aktiviert wurde, können sich Benutzer mit geänderten Kennwörtern nicht anmelden.
Weitere Informationen dazu enthält der VMware-Knowledgebase-Artikel 2151236.
- Problem 1702339: Bei Schwachstellenprüfungen wird möglicherweise die Quagga-Schwachstelle „bgp_dump_routes“ (CVE-2016-4049) gemeldet
Bei Schwachstellenprüfungen in NSX for vSphere wird möglicherweise die Quagga-Schwachstelle „bgp_dump_routes“ (CVE-2016-4049) gemeldet. NSX for vSphere verwendet Quagga, doch die BGP-Funktionalität (die die Schwachstelle erkennt) ist nicht aktiviert. Diese Schwachstellenwarnung kann bedenkenlos ignoriert werden.
Problemumgehung: Da das Produkt nicht anfällig ist, ist keine Problemumgehung erforderlich.
- Problem 1993691: Das Entfernen eines Hosts, ohne diesen zunächst als Replizierungsknoten zu entfernen, kann zu veralteten Einträgen in NSX Manager führen.
Wenn ein Host als Replizierungsknoten für einen HW-VTEP dient und aus dem übergeordneten Cluster entfernt werden muss, stellen Sie zunächst sicher, dass er kein Replizierungsknoten mehr ist, bevor Sie ihn aus dem Cluster entfernen. Andernfalls behält er in einigen Fällen seinen Status als Replizierungsknoten in der NSX Manager-Datenbank, was bei der Bearbeitung von weiteren Replizierungsknoten zu Fehlern führen kann.
Problemumgehung: Weitere Informationen finden Sie im Knowledgebase-Artikel 52418.
- Problem 2147002: Dienst- und Leistungsauswirkungen bei Guest Introspection-Installation auf NSX for vSphere 6.4.1
Dieses Problem tritt auf, wenn es bei vMotion oder Storage vMotion von VMs zwischen Hosts mit aktivierter Guest Introspection zu langen Wartezeiten kommt.
Häufig treten Ereignisprotokolle „Mux wird getrennt“ in vmware.log der VM zusammen mit der Fehlermeldung „PANIC: NamespaceDb.cpp:AccessNamespaceDb():83 Function call to read_key failed“ im Host-Syslog auf.Problemumgehung: Weitere Informationen dazu enthält der VMware-Knowledgebase-Artikel 56734.
- Problem 2164138: Beim Vorbereiten eines Clusters für NSX wird der ixgbe-Treiber auf Hosts mit physischen Netzwerkkarten mit ausgeführtem ixgbe-Treiber erneut geladen
Der ixgbe-Treiber wird erneut geladen, um die RSS-Option (Receive Side Scaling) zu aktivieren, um den VXLAN-Durchsatz zu verbessern. Das erneute Laden des ixgbe-Treibers sorgt dafür, dass die vmNICs, die den ixgbe-Treiber verwenden, nur wenige Sekunden lang ausfallen und gesichert werden. In seltenen Fällen kann der ixgbe-Treiber nicht erneut geladen werden und die vmNICs, die den ixgbe-Treiber verwenden, bleiben inaktiv, bis der ESXi-Host neu gestartet wird.
Problemumgehung: Weitere Informationen dazu enthält der VMware-Knowledgebase-Artikel 52980.
Bevor Sie das Upgrade durchführen, lesen Sie den Abschnitt Upgrade-Hinweise weiter oben in diesem Dokument.
- Problem 2036024: NSX Manager-Upgrade bleibt aufgrund der Datenbankfestplattenauslastung bei „Verifying uploaded file“ (Hochgeladene Datei wird überprüft) hängen
Die Upgrade-Protokolldatei „vsm-upgrade.log“ enthält außerdem die folgende Meldung: „Database disk usage is at 75%, but it should be less than 70%“ (Datenbankfestplattenauslastung ist bei 75 %, sollte jedoch unter 70 % liegen). Sie können die Datei „vsm-upgrade.log“ im NSX Manager-Support-Paket anzeigen. Navigieren Sie zu Networking & Security > Support-Paket und wählen Sie die Einstellung zur Einbindung der NSX Manager-Protokolle aus.
Problemumgehung: Wenden Sie sich an den VMware-Kundensupport.
- 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 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.
Problemumgehung: Dieses Problem betrifft die Benutzeroberfläche und kann ignoriert werden. Warten Sie den Fortschritt des Hostcluster-Upgrades ab.
- 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 1797929: Der Nachrichtenbuskanal ist nach einem Hostcluster-Upgrade nicht verfügbar
Nach einem Hostcluster-Upgrade wird von vCenter 6.0 (und früher) das Ereignis „Erneut verbinden“ nicht generiert. Dies führt dazu, dass NSX Manager keine Messaging-Infrastruktur auf dem Host einrichtet. Dieses Problem wurde in vCenter 6.5 behoben.Problemumgehung: Synchronisieren Sie erneut die Messaging-Infrastruktur, wie im folgenden API-Aufruf dargestellt:
POST https://<ip>:/api/2.0/nwfabric/configure?action=synchronize<nwFabricFeatureConfig> <featureId>com.vmware.vshield.vsm.messagingInfra</featureId> <resourceConfig> <resourceId>host-15</resourceId> </resourceConfig> </nwFabricFeatureConfig>Problem 1263858: SSL VPN sendet keine Upgrade-Benachrichtigung an den Remote-Client
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 1979457: Wenn die GI-SVM während des Upgrades im Abwärtskompatibilitätsmodus gelöscht oder entfernt wird, ist die identitätsbasierte Firewall über Guest Introspection (GI) nur dann funktionsfähig, wenn der GI-Cluster aktualisiert wird.
Die identitätsbasierte Firewall ist nicht funktionsfähig und es werden keine Protokolle im Zusammenhang mit der identitätsbasierten Firewall angezeigt. Der identitätsbasierte Firewall-Schutz ist aufgehoben, bis der Cluster aktualisiert wird.
Problemumgehung: Aktualisieren Sie den Cluster, damit die neuere Version der GI-SVM auf allen Hosts ausgeführt wird.
-oder-
Aktivieren Sie den Log Scraper, damit die identitätsbasierte Firewall funktioniert.
- Problem 2106417: GI-SVM weist nach dem NSX Manager-Upgrade von 6.3.0 auf 6.4.1 den Status „Fehlgeschlagen“ auf
Wenn Sie vCenter Server 6.5 u1 verwenden und für NSX Manager ein Upgrade von 6.3.0 auf 6.4.1 durchführen, schlägt das Upgrade für GI-SVM möglicherweise fehl.
Problemumgehung: Wenn dieses Problem auftritt, löschen Sie die GI-SVMs und stellen Sie sie erneut bereit.
- Problem 2088315: NSX Manager-Sicherungsvorgang schlägt fehl
Das in der Sicherungsdatei „S01_NSX_00_00_00_Fri23Mar2018“ enthaltene rabbitmq-Zertifikat ist abgelaufen. Überprüfen Sie das Sicherungszertifikat mithilfe der folgenden Schritte:
openssl enc -md sha512 -d -aes-256-cbc -salt -in S01_NSX_00_00_00_Fri23Mar2018 -out backup.tar -pass 'pass:)' tar -xvf backup.tar openssl x509 -enddate -noout -in home/secureall/secureall/.store/.rabbitmq_cert.pemDie Ausgabe ergibt ein abgelaufenes Datum:
notAfter=Dec 26 20:20:40 1978 GMTKontaktieren Sie den Support. Der Support sollte ein neues Zertifikat erstellen.
- Problem 1747978: OSPF-Nachbarschaften werden mit der MD5-Authentifizierung nach einem NSX Edge-HA-Failover gelöscht
Wenn in einer NSX for vSphere 6.2.4-Umgebung NSX Edge für eine Hochverfügbarkeit mit OSPF ein ordnungsgemäßer Neustart konfiguriert ist und MD5 für die Authentifizierung verwendet wird, kann OSPF nicht ordnungsgemäß neu starten. Es werden nur dann Nachbarschaften gebildet, wenn der Lebensdauer-Timer auf den OSPF-Nachbarschaftsknoten abgelaufen ist.Problemumgehung: Keine
- 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.
Problemumgehung: Starten Sie den Edge-Knoten neu.
- Problem 2015368: Firewallprotokollierung führt unter bestimmten Umständen zu unzureichendem Arbeitsspeicher
Wenn die Edge-Firewall in umfangreichen Konfigurationen aktiviert ist und die Firewallprotokollierung für einige oder alle Regeln aktiviert ist, kommt es in seltenen Fällen auf dem Edge zu Problemen aufgrund von unzureichendem Arbeitsspeicher (OOM, Out-Of-Memory). Dies ist insbesondere der Fall, wenn die Protokollierungsregeln sehr viel Datenverkehr verarbeiten müssen. Wenn eine OOM-Bedingung auftritt, wird die Edge-VM automatisch neu gestartet.
Problemumgehung: Die Firewallprotokollierung sollte am besten nur für Debugging-Zwecke verwendet und für die normale Anwendung wieder deaktiviert werden. Um dieses OOM-Problem zu vermeiden, deaktivieren Sie jegliche Firewallprotokollierung.
- 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.
Problemumgehung: Starten Sie den Edge-Knoten neu.
- Problem 2186968: Statisches IPSet nicht bei Containerset API-Aufruf gemeldet.
Wenn Sie über Dienst-Appliances verfügen, kann NSX IP-Sätze bei der Kommunikation mit Partnerdienst-Managern umgehen. Dies kann dazu führen, dass Verbindungen von Partner-Firewalls fälschlicherweise zugelassen bzw. verhindert werden.
Problemumgehung: Zur Umgehung dieses Problems wenden Sie sich an den VMware-Kundensupport. Weitere Informationen dazu enthält der VMware-Knowledgebase-Artikel 57834.
- Problem 2183584: Sicherheitsgruppen, die in einer Application Rule Manager-Sitzung erstellt wurden, werden im Dropdown-Menü der Spalte „Angewendet auf“ der empfohlenen Regel nicht angezeigt.
Sicherheitsgruppen, die in einer Application Rule Manager-Sitzung erstellt wurden, werden im Dropdown-Menü der Spalte „Angewendet auf“ der empfohlenen Regel nicht angezeigt.
Problemumgehung: Eine Problemumgehung finden Sie im VMware-Knowledgebase-Artikel 57837.
- Problem 2017806: Fehlermeldung beim Hinzufügen von Mitgliedern zu Sicherheitsgruppen, die in RDSH-Firewallabschnitten von Sicherheitsrichtlinien verwendet werden, ist nicht eindeutig
Wenn eine Sicherheitsgruppe in RDSH-Firewallabschnitten von Sicherheitsrichtlinien verwendet wird, können Sie dieser nur Verzeichnisgruppenmitglieder hinzufügen. Wenn Sie versuchen, ein anderes Mitglied als eine Verzeichnisgruppe hinzuzufügen, wird die folgende Fehlermeldung angezeigt:
„Sicherheitsgruppe wird von Service Composer-Firewall verwendet und kann nicht geändert werden“
Der Fehlermeldung ist nicht zu entnehmen, dass die Sicherheitsgruppe nicht geändert werden kann, weil die Sicherheitsgruppe in RDSH-Firewallabschnitten von Sicherheitsrichtlinien verwendet wird.Problemumgehung: Keine.
- 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.Problemumgehung: Beim Erstellen einer neuen Dienstinstanz können Sie beliebige Informationen für Cluster/Netzwerk/Speicher angeben, um die Felder auszufüllen. Auf diese Weise ist es Ihnen möglich, die Dienstinstanz zu erstellen und wunschgemäß fortfahren.
- Problem 2018077: Firewallveröffentlichung schlägt fehl, wenn für die Regel ein benutzerdefinierter L7-ALG-Dienst ohne Zielport und Protokoll verwendet wird
Wenn Sie einen L7-Dienst durch Auswählen einer der folgenden L7-ALG-APPs (APP_FTP, APP_TFTP, APP_DCERPC, APP_ORACLE) erstellen, ohne einen Zielport und ein Protokoll anzugeben, und diese dann in Firewallregeln verwenden, schlägt die Veröffentlichung der Firewallregeln fehl.
Problemumgehung: Geben Sie die entsprechenden Werte für Zielport und Protokoll (TCP/UDP) beim Erstellen eines benutzerdefinierten L7-Dienstes für die folgenden ALG-Dienste an:
- APP_FTP: Port 21-Protokoll: TCP
- APP_TFTP: Port 69-Protokoll: UDP
- APP_DCERPC: Port 135-Protokoll: TCP
- APP_ORACLE: Port 1521-Protokoll: TCP
- Problem 1466790: Mit dem NSX-Tool Traceflow können keine VMs in überbrückten Netzwerken ausgewählt werden
Wenn Sie das NSX-Tool Traceflow verwenden, können Sie nur VMs auswählen, die mit einem logischen Switch verbunden sind. Das bedeutet, dass VMs in einem L2-überbrückten Netzwerk nicht mit dem VM-Namen als Quell- oder Zieladresse für die Traceflow-Untersuchung ausgewählt werden können.Problemumgehung: Verwenden Sie für VMs, die an L2-überbrückte Netzwerke angeschlossen sind, die IP-Adresse oder MAC-Adresse der Schnittstelle, die Sie als Ziel in einer Traceflow-Untersuchung angeben möchten. Sie können an L2-überbrückte Netzwerke angeschlossene VMs nicht als Quelle verwenden. Weitere Informationen finden Sie im Knowledgebase-Artikel 2129191.
