Versionshinweise zu VMware NSX for vSphere 6.3.2

|
VMware NSX for vSphere 6.3.2   |   Freigegeben am 8. Juni 2017   |   Build 5672532

Inhalt dieser Versionshinweise

Diese Versionshinweise decken die folgenden Themen ab:

Neuigkeiten in 6.3.2

NSX for vSphere 6.3.2 ist eine Version zur Fehlerkorrektur, mit der bestimmte von Kunden gemeldete Probleme behoben wurden. Weitere Informationen dazu finden Sie unter Behoben in 6.3.2.

Diese Version bietet eine vollständige Unterstützung für den Modus für den Betrieb mit getrenntem Controller (Controller Disconnected Operation, CDO). Weitere Informationen dazu finden Sie im Abschnitt Modus für den Betrieb mit getrenntem Controller (Controller Disconnected Operation, CDO): im Administratorhandbuch für NSX.

Ab der Version NSX 6.3.2 wird Open VM Tools von der verteilten Firewall unterstützt.

Im Folgenden finden Sie die neuen und geänderten Funktionen in NSX 6.3.1 und NSX 6.3.0.

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 Empfohlene Version
NSX for vSphere

VMware empfiehlt die neueste NSX 6.3-Version für neue Bereitstellungen sowie zum Durchführen eines Upgrades von 6.1.x.

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

  • vSphere 5.5U3 und höher
  • vSphere 6.0U3 und höher. vSphere 6.0U3 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.
  • vSphere 6.5U1 und höher. vSphere 6.5U1 behebt das Problem eines EAM-Versagens bei OutOfMemory-Fehlern. Weitere Informationen dazu enthält der VMware-Knowledgebase-Artikel 2135378.
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:
  • Verwenden Sie VMware Tools 10.0.9 und 10.0.12 für die Aktivierung der optionalen, in VMware Tools enthaltenen Thin Agent-Komponente des Netzwerk-Introspektions-Treibers.
  • Führen Sie ein Upgrade auf VMware Tools 10.0.8 und höher für die Behebung des Problems verlangsamter VMs nach dem Upgrade von VMware Tools in NSX/vCloud Networking and Security durch (siehe VMware-Knowledgebase-Artikel 2144236).
  • Verwenden Sie VMware Tools 10.1.0 und höher zur Unterstützung von Windows 10.
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)
vRealize Orchestrator NSX-vRO-Plug-In 1.1.0 oder höher

Hinweis: VMware unterstützt aktuell nicht NSX for vSphere 6.3.x mit vRealize Networking Insight 3.2.

Systemanforderungen und Installation

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

Installationsanweisungen finden 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.)

  • NSX Data Security wurde entfernt: In der Version NSX 6.3.0 wurde die Funktion NSX Data Security aus dem Produkt entfernt.

  • NSX Activity Monitoring (SAM) wird nicht mehr unterstützt: Ab NSX 6.3.0 wird Activity Monitoring nicht mehr in NSX unterstützt. Verwenden Sie stattdessen die Endpunktüberwachung. Weitere Informationen dazu finden Sie unter Endpunktüberwachung im Administratorhandbuch für NSX.

  • Web Access Terminal wurde entfernt: Web Access Terminal (WAT) wurde aus NSX 6.3.0 entfernt. Sie haben nicht die Möglichkeit, Web Access SSL VPN-Plus zu konfigurieren und den Zugriff auf die öffentliche URL über NSX Edge zu aktivieren. VMware empfiehlt die Verwendung des Vollzugriffs-Clients bei SSL VPN-Bereitstellungen zur Verbesserung der Sicherheit. Wenn Sie die WAT-Funktionalität in früheren Versionen verwenden, müssen Sie diese deaktivieren, bevor Sie ein Upgrade auf 6.3.0 durchführen.

  • IS-IS wurde aus NSX Edge entfernt: Ab der Version NSX 6.3.0 kann das IS-IS-Protokoll nicht mehr auf der Registerkarte Routing konfiguriert werden.

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

Entfernung von APIs und Änderungen des Verhaltens

Löschen der Firewallkonfiguration oder des Standardabschnitts:

  • Die Anforderung zum Löschen eines Firewallabschnitts wird jetzt abgelehnt, wenn der Standardabschnitt angegeben wurde: DELETE /api/4.0/firewall/globalroot-0/config/layer2sections|layer3sections/sectionId
  • Zum Abrufen der Standardkonfiguration wurde eine neue Methode integriert. Mit der Ausgabe dieser Methode können Sie die gesamte Konfiguration oder jeden Standardabschnitt ersetzen:
    • Abrufen der Standardkonfiguration mit GET api/4.0/firewall/globalroot-0/defaultconfig
    • Aktualisieren der gesamten Konfiguration mit PUT /api/4.0/firewall/globalroot-0/config
    • Aktualisieren eines einzelnen Abschnitts mit PUT /4.0/firewall/globalroot-0/config/layer2sections|layer3sections/{sectionId}

Der Parameter defaultOriginate wurde aus den folgenden Methoden nur für NSX Edge-Appliances von logischen (verteilten) Routern entfernt:

  • GET/PUT /api/4.0/edges/{edge-id}/routing/config/ospf
  • GET/PUT /api/4.0/edges/{edge-id}/routing/config/bgp
  • GET/PUT /api/4.0/edges/{edge-id}/routing/config

Die Festlegung von defaultOriginate auf „True“ für eine Edge-Appliance eines logischen (verteilten) Routers für NSX 6.3.0 oder höher schlägt fehl.

Alle IS-IS-Methoden wurden aus dem NSX Edge-Routing entfernt.

  • GET/PUT/DELETE /4.0/edges/{edge-id}/routing/config/isis
  • GET/PUT /4.0/edges/{edge-id}/routing/config

Upgrade-Hinweise

Hinweis: Wenn Sie SFTP für NSX-Sicherungen verwenden, ändern Sie nach dem Upgrade auf Version 6.3.x den Sicherheitsalgorithmus auf hmac-sha2-256, da hmac-sha1 nicht unterstützt wird. Eine Liste der unterstützten Sicherheitsalgorithmen in 6.3.x finden Sie im VMware-Knowledgebase-Artikel 2149282 .

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

Upgrade-Hinweise zu NSX und vSphere

  • 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.

  • 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.

    In NSX 6.3.0 wurden die Festplattengrößen der NSX Edge-Appliance geändert:

    • Kompakt, Groß, Quad Large: 1 Festplatte mit 584 MB + 1 Festplatte mit 512 MB

    • Sehr groß: 1 Festplatte mit 584 MB + 1 Festplatte mit 2 GB + 1 Festplatte mit 256 MB

  • Upgrade-Pfad von NSX 6.x: 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.3.x erfolgreich durchgeführt wurde, erhalten Sie Erläuterungen im Knowledgebase-Artikel 2134525.

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

  • Upgrade auf vSphere 6.5a: Wenn Sie ein Upgrade von vSphere 5.5 oder 6.0 auf vSphere 6.5a durchführen möchten, müssen Sie zuerst ein Upgrade auf NSX 6.3.x vornehmen. Weitere Informationen dazu finden Sie unter Upgrade von vSphere in einer NSX-Umgebung im Upgrade-Handbuch für NSX.

    Hinweis: NSX 6.2.x ist nicht mit vSphere 6.5 kompatibel.

  • 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.
  • Setzen Sie den vSphere Web Client zurück: Nach dem Upgrade von NSX Manager müssen Sie den vSphere Web Client-Server wie in der Dokumentation zum NSX-Upgrade erläutert zurücksetzen. Bevor Sie diesen Schritt ausführen, wird die Registerkarte Netzwerk und Sicherheit im vSphere Web Client möglicherweise nicht angezeigt. Eventuell müssen Sie auch Ihren Browser-Cache oder Ihren Browser-Verlauf löschen.

  • Zustandsfreie Umgebungen: Für NSX-Upgrades in einer statusfreien Hostumgebung werden neue VIB-URLs verwendet: 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:

    1. Laden Sie die aktuellen NSX-VIBs vom NSX Manager über eine feste URL herunter.

    2. Fügen Sie die VIBs zum Host-Image-Profil hinzu.

    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 die neue VIB-URL über https://<NSX-Manager-IP>/bin/vdn/nwfabric.properties.
    • Rufen Sie die VIBs der erforderlichen ESX-Hostversion über die jeweilige URL ab.
    • Fügen Sie sie zu einem Image-Profil hinzu.
  • Upgrade ohne Neustart und Deinstallation auf den Hosts: Bei vSphere 6.0 und höher ist nach einem Upgrade auf NSX 6.3.x 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.

    Bei den folgenden Aufgaben ist ein Neustart des Hosts nicht erforderlich:

    • Upgrades von NSX 6.3.0 auf NSX 6.3.x auf ESXi 6.0 oder höher.
    • Installation des NSX 6.3.x-VIB, die nach dem Upgrade für ESXi von 6.0 auf 6.5.0a oder höher erforderlich ist.

      Anmerkung: Das ESXi-Upgrade erfordert weiterhin einen Neustart des Hosts.

    • Deinstallation des NSX 6.3.x-VIB auf ESXi 6.0 oder höher.

    Bei den folgenden Aufgaben ist ein Neustart des Hosts erforderlich:

    • Upgrades von NSX 6.2.x oder früher auf NSX 6.3.x (alle ESXi-Versionen).
    • Upgrades von NSX 6.3.0 auf NSX 6.3.x auf ESXi 5.5.
    • Installation des NSX 6.3.x-VIB, die nach dem Upgrade von ESXi von 5.5 auf Version 6.0 oder höher erforderlich ist.
    • Deinstallation des NSX 6.3.x-VIB auf ESXi 5.5.

Upgrade-Hinweise zu NSX-Komponenten

  • Upgrade auf NSX 6.3.1

    • Wenn Sie ein Upgrade von NSX 6.3.0 auf NSX 6.3.1 durchführen, müssen Sie Folgendes beachten: Es müssen nur NSX Manager und Hostcluster aktualisiert werden. NSX 6.3.1 zeigt nur diese Komponenten für das Upgrade an.

    • Wenn Sie ein Upgrade von NSX 6.2.x auf NSX 6.3.1 durchführen, müssen Sie Folgendes beachten: Sie müssen ein komplettes Upgrade für alle NSX-Komponenten durchführen. Beachten Sie, dass dabei für NSX Edge und Guest Introspection die Version 6.3.0 und nicht 6.3.1 angezeigt wird.
  • 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:

    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 nachfolgender Tabelle).

    3. 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

  • 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.

  • 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 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).

  • Controller-Festplattenlayout: Upgrades von 6.2.2 und früher erhalten nicht das neue, in 6.2.3 eingeführte Festplattenlayout, das separate Festplattenpartitionen für Daten und Protokolle zur Verbesserung der Controller-Stabilität ermöglicht.
  • Bevor Sie ein Upgrade auf NSX 6.2.5 oder höher vornehmen, stellen Sie sicher, dass alle Lastenausgleichsdienst-Verschlüsselungslisten durch Doppelpunkte getrennt sind. Wenn in Ihrer Verschlüsselungsliste ein anderes Trennzeichen (z. B. das 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>-Liste in <clientSsl> und <serverSsl> mit einer Liste mit Doppelpunkttrennung. 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 Load Balancing auf vROPs-Versionen vor 6.2.0 fest: vROPs-Poolmitglieder in vROPs-Versionen vor 6.2.0 verwenden TLS Version 1.0. Sie müssen deshalb ausdrücklich durch Einstellung von "ssl-version=10" in der NSX-Load-Balancer-Konfiguration einen Wert für die Überwachungserweiterung 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"
    }

  • Host bleibt eventuell im Installationsstadium hängen: Während umfangreicher NSX-Upgrades besteht die Gefahr, dass ein Host bei der Durchführung der Installation für längere Zeit hängen bleibt. Dies kann aufgrund von Problemen bei der Deinstallation alter NSX-VIBs auftreten. In diesem Fall wird der diesem Host zugeordnete EAM-Thread in der VI Client-Aufgabenliste als „Hängend“ vermerkt.
    Problemumgehung: Gehen Sie wie folgt vor:

    • Melden Sie sich bei vCenter mithilfe des VI Client an.
    • Klicken Sie mit der rechten Maustaste auf die als „Hängend“ angegebene EAM-Aufgabe und brechen Sie diese ab.
    • Vom vSphere Web Client initiieren Sie einen „Auflösen“-Vorgang im Cluster. Für den hängenden Host wird nun eventuell „InProgress“ angezeigt.
    • Melden Sie sich beim Host an und initiieren Sie einen Neustart, um den Abschluss des Upgrades auf diesem Host zu erzwingen.

Upgrade-Hinweise zu 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.

Bekannte Probleme

Bekannte Probleme gliedern sich wie folgt:

Allgemeine bekannte Probleme

Problem 1740625, 1749975: Probleme der Benutzeroberfläche unter Mac OS in Firefox und Safari
Wenn Sie Firefox oder Safari unter Mac OS verwenden, funktioniert die Schaltfläche „Zurück“ in NSX Edge auf der Seite „Networking & Security“ im vSphere 6.5 Web Client nicht. Manchmal friert in Firefox die Benutzeroberfläche ein.

Problemumgehung: Verwenden Sie Google Chrome unter Mac OS oder klicken Sie auf die Home-Schaltfläche und fahren Sie gemäß den Anweisungen fort.

Problem 1700980: Bei Sicherheitspatch CVE-2016-2775 kann ein zu langer Abfragename zu einem Segmentierungsfehler in „lwresd“ führen.

Unter NSX 6.2.4 ist BIND 9.10.4 installiert, aber die Option „lwres“ wird in named.conf nicht verwendet. Daher ist das Produkt nicht anfällig.

Problemumgehung: Da das Produkt nicht anfällig ist, ist keine Problemumgehung erforderlich.

Problem 1558285: Das Löschen von Clustern von vCenter mithilfe von Guest Introspection führt zu einer Nullzeiger-Ausnahme
Bevor ein Cluster von vCenter entfernt werden kann, müssen Dienste wie Guest Introspection entfernt werden.

Problemumgehung: Löschen Sie die EAM-Agency für die Dienstbereitstellung ohne zugeordneten Cluster.

Problem 1629030: Für die Befehle der zentralen CLI zur Paketerfassung (debug packet capture und show packet capture) ist vSphere 5.5U3 oder höher erforderlich
Diese Befehle werden von früheren Versionen von vSphere 5.5 nicht unterstützt.

Problemumgehung: VMware empfiehlt allen NSX-Kunden die Verwendung von vSphere 5.5U3 oder höher.

Problem 1568180: Die Funktionsliste für NSX bei der Verwendung von vCSA 5.5 (vCenter Server Appliance) ist nicht korrekt
Sie können die Funktionen einer Lizenz im vSphere Web Client durch Auswahl der Lizenz und Klicken auf Aktionen > Funktionen anzeigen darstellen. Wenn Sie ein Upgrade auf NSX 6.2.3 durchführen, wird für Ihre Lizenz ein Upgrade auf eine Enterprise-Lizenz durchgeführt, mit der alle Funktionen aktiviert werden. Wenn allerdings NSX Manager mit vCSA 5.5 (vCenter Server Appliance) registriert wird, führt die Auswahl von Funktionen anzeigen zur Darstellung der Funktionen für die Lizenz, die vor dem Upgrade verwendet wurde, und nicht für die neue Enterprise-Lizenz.

Problemumgehung: Alle Enterprise-Lizenzen umfassen die gleichen Funktionen, auch wenn sie im vSphere Web Client nicht korrekt dargestellt werden. Weitere Informationen finden Sie auf der NSX-Lizenzseite.

Bekannte Installations- und Upgrade-Probleme

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

Neues Problem 1848058: Upgrade von ESXi-Hosts VIBs auf NSX 6.3.2 schlägt möglicherweise fehl
In einigen Fällen wird beim Upgrade von ESXi-Host-VIBs auf NSX 6.3.2 das ältere VIB-Verzeichnis von NSX Manager gelöscht, wodurch das Upgrade nicht durchgeführt werden kann. Durch Klicken auf die Schaltfläche „Auflösen“ kann das Problem nicht behoben werden.

Problemumgehung: Zur Behebung dieses Problems verwenden Sie die Upgrade-API:

PUT https://<nsx-mgr-ip>/api/2.0/nwfabric/configure

<nwFabricFeatureConfig>
  <featureId>com.vmware.vshield.vsm.vxlan</featureId>
  <resourceConfig>
    <resourceId>domain-cXX</resourceId>
  </resourceConfig>
</nwFabricFeatureConfig>
wobei <nsx-mgr-ip> die IP-Adresse Ihres NSX Manager ist und domain-cXX die Domänen-ID des Clusters.

Neues Problem 1747217: Vorbereitung der ESXi Hosts führt zu muxconfig.xml.bad und Guest Introspection funktioniert nicht ordnungsgemäß
Wenn „vmx path“ in einer der VMs in muxconfig.xml fehlt und MUX beim Versuch, die Konfigurationsdatei zu analysieren, die Eigenschaft „xml path“nicht findet, wird die Konfigurationsdatei in „muxconfig.xml.bad“ umbenannt, die Fehlermeldung „Fehler – MUX-Analysekonfiguration“ an die USVM gesendet und der Konfigurationskanal geschlossen.

Problemumgehung: Entfernen Sie die verwaisten virtuellen Maschinen aus der vCenter-Bestandsliste.

Neues 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.

Neues Problem 1435504: HTTP/HTTPS-Systemstatusprüfung ergibt nach dem Upgrade von 6.0.x oder 6.1.x auf 6.3.x INAKTIV mit der Fehlermeldung „Rückgabecode 127 ist außerhalb des gültigen Bereichs – Plug-In fehlt möglicherweise“
Wenn in den Versionen NSX 6.0.x und 6.1.x die URLs ohne doppelte Anführungszeichen ("") konfiguriert wurden, konnte die Systemstatusprüfung nicht durchgeführt werden. Es wurde dann folgender Fehler angezeigt: „Rückgabecode 127 ist außerhalb des gültigen Bereichs – Plug-In fehlt möglicherweise“. Als Problemumgehung wurde das Hinzufügen doppelter Anführungszeichen ("") in der eingegebenen URL empfohlen (dies war nicht für die Felder send/receive/expect erforderlich). Dieses Problem wurde in Version 6.2.0 behoben, was allerdings dazu führt, dass bei einem Upgrade von 6.0.x oder 6.1.x auf 6.3.x die Mitglieder des Pools durch die zusätzlichen doppelten Anführungszeichen in der Systemstatusprüfung als INAKTIV angezeigt werden.

Problemumgehung: Entfernen Sie nach dem Upgrade die doppelten Anführungszeichen ("") im URL-Feld aus allen betroffenen Konfigurationen der Systemstatusprüfung.

Neues Problem 1834285: HTTP/HTTPS-Transaktion schlägt auf NSX-Load Balancer nach dem Upgrade auf NSX 6.1.5 oder höher fehl.
Ab NSX 6.1.5 wird bei Aktivierung von X-forwarded-for der HTTP-Verbindungsmodus von passivem Schließen (option httpclose) auf den Standardmodus HTTP-Server-Close (option http-server-close) geändert, wodurch nach dem Empfang einer Antwort vom Server die clientseitige Verbindung offen bleibt, während die serverseitige Verbindung geschlossen wird. Dies führt zu Problemen bei einigen Anwendungen, weil in NSX-Versionen vor 6.1.5 der Load Balancer die Verbindung nicht proaktiv schloss, sondern stattdessen den Header „Connection:close“ in beide Richtungen einfügte, um dem Client oder Server mitzuteilen, dass die Verbindung geschlossen werden soll.

Problemumgehung: Fügen Sie eine Anwendungsregel mit dem Skript option httpclose hinzu und verknüpfen Sie diese mit dem fehlerhaften virtuellen Server.

Problem 1734245: Data Security führt zum Fehler bei Upgrades auf 6.3.0
Upgrades auf 6.3.0 sind nicht möglich, wenn Data Security als Teil einer Dienstrichtlinie konfiguriert ist. Stellen Sie sicher, dass vor dem Upgrade Data Security von allen Dienstrichtlinien entfernt wird.

Problem 1801685: Filter werden auf ESXi nach dem Upgrade von Version 6.2.x auf 6.3.0 aufgrund einer fehlgeschlagenen Verbindung mit dem Host nicht angezeigt
Nach dem Upgrade von NSX 6.2.x auf 6.3.0 und der Cluster-VIBs auf 6.3.0-Bits weist der „Kommunikationskanalstatus“ die Verbindung von NSX Manager zum Firewallagenten und von NSX Manager zum Steuerungskomponentenagenten als inaktiv aus, auch wenn die Installation als erfolgreich und die Firewall als aktiviert angezeigt wird. Dies führt zum Scheitern der Veröffentlichung von Firewallregeln und Sicherheitsrichtlinien, und die VXLAN-Konfiguration kann nicht zu den Hosts gesendet werden.

Problemumgehung: Führen Sie den API-Aufruf zur Synchronisierung des Nachrichtenbusses für den Cluster mithilfe folgender API durch: POST:https://<NSX-IP>/api/2.0/nwfabric/configure?action=synchronize.
API-Text:

<nwFabricFeatureConfig>
 <featureId>com.vmware.vshield.vsm.messagingInfra</featureId>
 <resourceConfig>
   <resourceId>{Cluster-MOID}</resourceId>
 </resourceConfig>
</nwFabricFeatureConfig>

Problem 1791371: Wenn beim Upgrade von ESXi-Hosts auf vSphere 6.5a die Guest Introspection- und VXLAN-VIBs zeitgleich aktualisiert werden, wird ein Alarm ausgelöst
Die Guest Introspection- und VXLAN-VIBs unterscheiden sich bei vSphere 6.5a. Wenn Sie diese Komponenten zeitgleich aktualisieren, wird vom VXLAN-VIB-Upgrade ein Alarm ausgelöst, der einen Neustart des Hosts verlangt.

Problemumgehung: Installieren Sie zuerst die VXLAN-VIBs und anschließend die Guest Introspection-VIBs, wenn Sie ein Upgrade auf vSphere 6.5a durchführen.

Problem 1805983: Wenn Sie ein Upgrade auf NSX 6.2.5, 6.2.6 oder 6.3.0 durchführen, funktionieren virtuelle Server ohne einen Serverpool nicht
Virtuelle Server ohne Serverpool unterstützen nur die HTTP/HTTPS-Umleitung. Alle anderen Funktionen sind nicht verfügbar.

Problemumgehung: Erstellen Sie einen Pseudopool ohne Mitglieder und weisen Sie diesen dem virtuellen Server zu.

Problem 1797307: Bei NSX Edge kann nach einem Upgrade oder einer erneuten Bereitstellung ein Split Brain auftreten
Für ein Standby-NSX Edge wird vom CLI-Befehl „show service highavailability“ der Hochverfügbarkeitsstatus als „Standby“ ausgegeben, der Status für „config engine“ aber als „Aktiv“.

Problemumgehung: Starten Sie das NSX Edge im Standbymodus neu.

Problem 1789989: Im Verlauf eines Hostcluster-Upgrades kann in der Datenebene ein Paketverlust auftreten
Bei einem VIB-Upgrade wird die Kennwortdatei von VSFWD (vShield Firewall Daemon), die im VIB enthalten ist, entfernt, sodass VSFWD das alte Kennwort nicht für die Herstellung einer Verbindung mit NSX Manager verwenden kann. Zuerst muss deshalb das neue Kennwort aktualisiert werden. Dieser Vorgang nimmt einige Zeit nach dem Neustart des Hosts in Anspruch. Allerdings werden in einem komplett automatisierten DRS-Cluster VMs sofort verschoben, wenn der vorbereitete Host gestartet wurde. Da der VSFWD-Vorgang zu diesem Zeitpunkt noch nicht bereit ist, besteht für eine kurze Zeit die Gefahr des Paketverlustes in der Datenebene.

Problemumgehung: Statt das Failback sofort nach dem Neustart des Hosts durchzuführen, führen Sie das Failback auf den neu vorbereiteten Host dieser VMs später durch.

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&gt:/api/2.0/nwfabric/configure?action=synchronize

<nwFabricFeatureConfig>
  <featureId>com.vmware.vshield.vsm.messagingInfra</featureId>
  <resourceConfig>
    <resourceId>host-15</resourceId>
  </resourceConfig>
</nwFabricFeatureConfig>

Problem 1802688: Upgrade von NSX 6.2.x auf 6.3.0 übernimmt nicht den aktualisierten DFW-Aktivierungsstatus
Wenn Sie dem aktualisierten Cluster nach einem Upgrade von NSX von 6.2.x auf 6.3.0 und von Cluster-VIBs auf 6.3.0-Bits einen neuen Host hinzufügen, ist der bisherige Firewallstatus des betreffenden Hosts und Clusters weiterhin gültig und wird nicht aktualisiert, auch wenn die neuen VIBs auf dem neuen Host installiert wurden.

Problemumgehung: Gehen Sie wie folgt vor:

  1. Führen Sie den API-Aufruf zur Synchronisierung des Nachrichtenbusses für den Host mit folgender API durch: POST https://<NSX-IP>/api/2.0/nwfabric/configure?action=synchronize. Der Firewallstatus für diesen Host und Cluster wird dadurch auf „Deaktiviert“ gesetzt.
    <nwFabricFeatureConfig>
      <featureId>com.vmware.vshield.vsm.messagingInfra</featureId>
      <resourceConfig>
        <resourceId>{HOST-ID}</resourceId>
      </resourceConfig>
    </nwFabricFeatureConfig>
  2. Aktivieren Sie jetzt über die Benutzeroberfläche die Firewall für diesen Cluster auf der Seite „Installation“ > „Hostvorbereitung“. Damit sollte für alle Hosts in diesem Cluster der Modus der aktivierten DFW gelten.

Problem 1768144: Ältere NSX Edge-Appliance-Ressourcenreservierungen, die die neuen Grenzwerte überschreiten, können zu Fehlern bei Upgrades oder erneuten Bereitstellungen führen
In NSX 6.2.4 und früher konnten beliebig große Ressourcenreservierungen für eine NSX Edge-Appliance festgelegt werden. In NSX war kein Höchstwert vorgegeben.
 Nach dem Upgrade des NSX Managers auf Version 6.2.5 oder höher treten bei Upgrades oder erneuten Bereitstellungen des Edge Fehler auf (wodurch ein Upgrade ausgelöst wird), wenn ein vorhandenes Edge reservierte Ressourcen (insbesondere Arbeitsspeicher) aufweist, die den neuen Höchstwert für den ausgewählten Formfaktor überschreiten. Hat ein Benutzer beispielsweise eine Arbeitsspeicherreservierung in Höhe von 1000 MB auf einem LARGE Edge vor Version 6.2.5 festgelegt und ändert die Appliance-Größe nach einem Upgrade auf Version 6.2.5 in COMPACT, so überschreitet die Arbeitsspeicherreservierung den neuen Höchstwert – in diesem Fall 512 für ein COMPACT Edge – und der Vorgang scheitert.
Unter Upgrade von Edge Services Gateway (ESG) erhalten Sie Informationen zur empfohlenen Ressourcenzuteilung in NSX 6.2.5.

Problemumgehung: Verwenden Sie die Appliance-REST-API: PUT https://<NSXManager>/api/4.0/edges/<edge-Id>/appliances/ zum erneuten Konfigurieren der Arbeitsspeicherreservierung, sodass sie innerhalb der für den Formfaktor festgelegten Werte liegt, ohne weitere Appliance-Änderungen. Nach Abschluss dieses Vorgangs können Sie die Appliance-Größe ändern.

Problem 1600281: Für den USVM-Installationsstatus von Guest Introspection wird in der Registerkarte „Dienstbereitstellungen“ der Wert „Fehlgeschlagen“ angegeben

Wenn der unterstützende Datenspeicher für eine globale Guest Introspection-SVM offline geschaltet wurde oder wenn auf diesen nicht zugegriffen werden kann, muss die USVM eventuell neu gestartet oder erneut bereitgestellt werden.

Problemumgehung: Starten Sie die USVM zur Wiederherstellung neu oder stellen Sie diese erneut bereit.

Problem 1660373: vCenter unterbindet das Hinzufügen eines Hosts zu vSphere Distributed Switch aufgrund einer abgelaufenen NSX-Lizenz

Bei vSphere 5.5 Update 3 und vSphere 6.0.x ist vSphere Distributed Switch in der NSX-Lizenz enthalten. Allerdings blockiert vCenter das Hinzufügen von ESXi-Hosts zu einem vSphere Distributed Switch, wenn die NSX-Lizenz abgelaufen ist.

Problemumgehung: Ihre NSX-Lizenz muss aktiv sein, damit Sie einem vSphere Distributed Switch einen Host hinzufügen können.​

Problem 1569010/1645525: Beim Upgrade von 6.1.x auf NSX for vSphere 6.2.3 auf einem System, das mit vCenter 5.5 verbunden ist, wird im Feld „Produkt“ des Fensters „Lizenzschlüssel zuweisen“ die NSX-Lizenz als generischer Wert „NSX for vSphere“ und nicht als eine genauer spezifizierte Version wie z. B. „NSX for vSphere - Enterprise“ dargestellt

Problemumgehung: Keine.

Problem 1636916: In einer vCloud Air-Umgebung werden Edge-Firewall-Regeln mit dem Wert „Alle“ des Quellprotokolls in „TCP:Alle, UDP:Alle“ geändert, wenn für die NSX Edge-Version ein Upgrade von vCNS 5.5.x auf NSX 6.x durchgeführt wurde
Als Folge davon ist der ICMP-Datenverkehr blockiert und es treten eventuell Paketverwerfungen auf.

Problemumgehung: Vor dem Upgrade Ihrer NSX Edge-Version erstellen Sie spezifischere Edge-Firewallregeln und ersetzen Sie „Alle“ mit bestimmten Quellportwerten.

Problem 1660355: Bei VMs, die von 6.1.5 auf 6.2.3 und höher migriert wurden, wird TFTP-ALG nicht unterstützt
Auch wenn der Host aktiviert ist, wird für VMs, die von 6.1.5 auf 6.2.3 und höher migriert wurden, kein TFTP-ALG unterstützt.

Problemumgehung: Fügen Sie die VM hinzu und entfernen Sie diese von der Ausschlussliste oder starten Sie die VM neu, damit der neue Filter für 6.2.3 (und höher) erstellt wird, der ein TFTP-ALG unterstützt.

Problem 1474238: Nach dem vCenter-Upgrade kann es zu einem Verbindungsabbruch zwischen vCenter und NSX kommen.
Wenn Sie das in vCenter eingebettete SSO verwenden und Sie ein Upgrade von vCenter 5.5 auf vCenter 6.0 durchführen, wird die Verbindung von vCenter zu NSX möglicherweise getrennt. Dies geschieht, wenn vCenter 5.5 bei NSX unter Verwendung des Root-Benutzernamens registriert wurde. In NSX 6.2 ist die vCenter-Registrierung mit Root veraltet.
Hinweis: Wenn Sie externes SSO verwenden, sind keine Änderungen erforderlich. Sie können denselben Benutzernamen, z. B. „admin@mybusiness.mydomain“, beibehalten. Dann wird die vCenter-Verbindung nicht getrennt.

Problemumgehung: Registrieren Sie vCenter mit NSX, indem Sie den administrator@vsphere.local-Benutzernamen anstelle des Root-Benutzernamens verwenden.

Problem 1332563: Herunterfahren des Gastbetriebssystems für Agent-VMs (SVA) vor dem Ausschalten
Wenn ein Host in den Wartungsmodus versetzt wird, werden alle Dienstanwendungen ausgeschaltet und nicht ordnungsgemäß heruntergefahren. Dies kann zu Fehlern innerhalb von Anwendungen von Drittanbietern führen.

Problemumgehung: Keine.

Problem 1473537: Dienst-Appliance, die mit der Ansicht „Dienstbereitstellungen“ bereitgestellt wurde, kann nicht eingeschaltet werden

Problemumgehung: Bevor Sie den Vorgang fortsetzen, überprüfen Sie Folgendes:

  • Die Bereitstellung der virtuellen Maschine wurde abgeschlossen.

  • Es werden für die virtuelle Maschine, die im Aufgabenbereich von vCenter angezeigt wird, keine in Ausführung befindlichen Aufgaben wie z. B. Klonen, Neukonfigurieren usw. angezeigt.

  • Im vCenter-Ereignisfenster der virtuellen Maschine werden die folgenden Ereignisse nach der Initiierung der Bereitstellung angezeigt:
     
    Agent-VM <VM-Name> wurde bereitgestellt.
    Markieren Sie den Agenten als verfügbar, um mit dem Agent-Workflow fortzufahren.
     

    Löschen Sie in einem solchen Fall die virtuelle Dienstmaschine. In der Dienstbereitstellungs-Benutzeroberfläche wird die Bereitstellung als „Fehlgeschlagen" angezeigt. Durch Klicken auf das rote Symbol wird ein Alarm wegen einer nicht verfügbaren Agent-VM für den Host angezeigt. Wenn Sie den Alarm beheben, wird die virtuelle Maschine erneut bereitgestellt und eingeschaltet.

Wenn in Ihrer Umgebung nicht alle Cluster vorbereitet sind, wird die Upgrade-Meldung für die verteilte Firewall auf der Registerkarte „Hostvorbereitung“ der Installationsseite nicht angezeigt
Wenn Sie Cluster für die Netzwerkvirtualisierung vorbereiten, ist die verteilte Firewall auf solchen Clustern aktiviert. Wenn in Ihrer Umgebung nicht alle Cluster vorbereitet sind, wird die Upgrade-Meldung für die verteilte Firewall auf der Registerkarte „Hostvorbereitung“ nicht angezeigt.

Problemumgehung: Verwenden Sie den folgenden REST-Aufruf, um die verteilte Firewall zu aktualisieren:
PUT https://<nsxmgr-ip>/api/4.0/firewall/globalroot-0/state

Problem 1215460: Wenn eine Dienstgruppe nach dem Upgrade geändert wird und Dienste hinzugefügt oder entfernt werden, werden diese Änderungen nicht in der Firewall-Tabelle widergespiegelt.
Von Benutzern erstellte Dienstgruppen werden in der Edge-Firewall-Tabelle beim Upgrade erweitert, d. h., in der Spalte „Service“ in der Firewall-Tabelle werden alle Dienste innerhalb der Dienstgruppe angezeigt. Wenn die Dienstgruppe nach dem Upgrade zum Hinzufügen oder Entfernen von Diensten modifiziert wird, werden diese Änderungen nicht in der Firewall-Tabelle widergespiegelt.

Problemumgehung: Erstellen Sie eine neue Dienstgruppe mit einem anderen Namen und verwenden Sie dann diese Dienstgruppe in der Firewallregel.

Problem 1413125: SSO kann nach dem Upgrade nicht neu konfiguriert werden
Wenn der in NSX Manager konfigurierte SSO-Server der einzige native Server in vCenter Server ist, können Sie die SSO-Einstellungen in NSX Manager nach dem Upgrade von vCenter Server auf Version 6.0 und dem Upgrade von NSX Manager auf Version 6.x nicht neu konfigurieren.

Problemumgehung: Keine.

Problem 1266433: 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 1474066: Der NSX-REST-API-Aufruf zur Aktivierung bzw. Deaktivierung der IP-Erkennung scheint keine Auswirkungen zu haben
Wenn die Clustervorbereitung auf dem Host noch nicht abgeschlossen ist, hat der NSX-REST-API-Aufruf zum Aktivieren bzw. Deaktivieren der IP-Erkennung (https://<nsxmgr-ip>/api/2.0/xvs/networks/universalwire-5/features) keine Auswirkungen.

Problemumgehung: Stellen Sie vor dem Erteilen dieses API-Aufrufs sicher, dass die Hostclustervorbereitung abgeschlossen ist.

Problem 1459032: Fehler beim Konfigurieren eines VXLAN-Gateways
Wenn beim Konfigurieren von VXLAN mit einem statischen IP-Pool (unter Networking & Security > Installation> Hostvorbereitung > VXLAN konfigurieren) keine Gateway-IP für den IP-Pool auf dem VTEP festgelegt werden kann (weil das Gateway nicht ordnungsgemäß konfiguriert oder nicht erreichbar ist), wechselt der Status der VXLAN-Konfiguration für den Host-Cluster in den Fehlerstatus (ROT).

Die Fehlermeldung lautet VXLAN-Gateway kann auf Host nicht festgelegt werden und der Fehlerstatus ist VXLAN_GATEWAY_SETUP_FAILURE. Im REST-API-Aufruf GET https://<nsxmgr-ip>/api/2.0/nwfabric/status?resource=<cluster-moid> lautet der VXLAN-Status wie folgt:

<nwFabricFeatureStatus>
  <featureId>com.vmware.vshield.nsxmgr.vxlan</featureId>
  <featureVersion>5.5</featureVersion>
  <updateAvailable>false</updateAvailable>
  <status>RED</status>
  <message>VXLAN Gateway cannot be set on host</message>
  <installed>true</installed>
  <enabled>true</enabled>
  <errorStatus>VXLAN_GATEWAY_SETUP_FAILURE</errorStatus>
</nwFabricFeatureStatus>

Problemumgehung: Es gibt zwei Optionen, den Fehler zu beheben.

  • Option 1: Entfernen Sie die VXLAN-Konfiguration für den Host-Cluster, korrigieren Sie das zugrunde liegende Gateway-Setup im IP-Pool, indem Sie sicherstellen, dass das Gateway ordnungsgemäß konfiguriert ist, und konfigurieren Sie VXLAN für den Host-Cluster anschließend neu.

  • Option 2: Führen Sie die folgenden Schritte aus.

    1. Korrigieren Sie das zugrunde liegende Gateway-Setup im IP-Pool, indem Sie sicherstellen, dass das Gateway ordnungsgemäß konfiguriert und erreichbar ist.

    2. Versetzen Sie den Host (oder Hosts) in den Wartungsmodus, um sicherzustellen, dass auf dem Host kein VM-Datenverkehr aktiv ist.

    3. Löschen Sie die VXLAN VTEPs aus dem Host.

    4. Deaktivieren Sie den Wartungsmodus für den Host. Durch das Deaktivieren des Wartungsmodus für den Host wird der VXLAN VTEP-Erstellungsvorgang auf NSX Manager ausgelöst. NSX Manager versucht, die erforderlichen VTEPs auf dem Host erneut zu erstellen.

Problem 1462319: Das VIB „esx-dvfilter-switch-security“ ist nicht mehr in der Ausgabe des Befehls „esxcli software vib list | grep esx“ vorhanden.
Ab NSX 6.2 sind die Module „esx-dvfilter-switch-security“ innerhalb des VIB esx-vxlan enthalten. Die einzigen NSX VIBs, die für 6.2 installiert sind, sind esx-vsip und esx-vxlan. Bei einem Upgrade von NSX auf 6.2 wird das alte VIB „esx-dvfilter-switch-security“ aus den ESXi-Hosts entfernt.
Ab NSX 6.2.3 wird zusätzlich zu den NSX VIBs „esx-vsip“ und „esx-vxlan“ das dritte VIB „esx-vdpi bereitgestellt. Bei einer erfolgreichen Installation werden alle 3 VIBs angezeigt.

Problemumgehung: Keine.

Problem 1481083: Nach dem Upgrade können logische Router, für die explizites Failover-Teaming konfiguriert ist, Pakete möglicherweise nicht ordnungsgemäß weiterleiten
Wenn auf den Hosts ESXi 5.5 ausgeführt wird, unterstützt die explizite Failover-Teaming-Richtlinie für NSX 6.2 nicht mehrere aktive Uplinks auf Distributed Logical Routern.

Problemumgehung: Ändern Sie die explizite Failover-Teaming-Richtlinie, sodass es nur einen aktiven Uplink gibt und sich die anderen Uplinks im Standby-Modus befinden.

Problem 1485862: Das Deinstallieren von NSX aus einem Hostcluster führt manchmal zu einem Fehlerzustand
Bei Verwendung der Aktion "Deinstallieren" auf der Registerkarte Installation: Hostvorbereitung kann ein Fehler auftreten, bei dem die Nachricht eam.issue.OrphanedAgency in den EAM-Protokollen für die Hosts angezeigt wird. Nach Verwendung der Aktion „Beheben“ und dem Neustart der Hosts bleibt der Fehlerzustand bestehen, selbst wenn die NSX-VIBs erfolgreich deinstalliert wurden.

Problemumgehung: Löschen Sie die verwaiste Agency auf dem vSphere ESX Agent Manager (Verwaltung: vCenter Server-Erweiterungen: vSphere ESX Agent Manager).

Problem 1411275: vSphere Web Client zeigt die Registerkarte „Netzwerk und Sicherheit“ nach der Sicherung und Wiederherstellung in NSX for vSphere 6.2 nicht an
Wenn Sie nach dem Upgrade auf NSX for vSphere 6.2 eine Sicherung und Wiederherstellung durchführen, wird die Registerkarte Netzwerk und Sicherheit im vSphere Web Client nicht angezeigt.

Problemumgehung: Wenn eine NSX Manager-Sicherung wiederhergestellt wird, werden Sie vom Appliance Manager abgemeldet. Warten Sie ein paar Minuten, bevor Sie sich beim vSphere Web Client anmelden.

Die Dienst-VM, die über die Registerkarte "Dienstbereitstellungen" auf der Installationsseite bereitgestellt wurde, wird nicht eingeschaltet

Problemumgehung: Befolgen Sie die unten beschriebenen Schritte.

  1. Entfernen Sie die Dienst-VM manuell vom ESX Agent-Ressourcenpool im Cluster.
  2. Klicken Sie auf Networking and Security und anschließend auf Installation.
  3. Klicken Sie auf die Registerkarte Dienstbereitstellungen.
  4. Wählen Sie den entsprechenden Dienst aus und klicken Sie auf das Symbol Auflösen.
    Die Dienst-VM wird neu bereitgestellt.

Problem 1764460: Nach Abschluss der Hostvorbereitung erscheinen alle Clustermitglieder als „Bereit“, aber Clusterebene wird fälschlicherweise als „Ungültig“ angezeigt
Nach dem Abschluss der Host-Vorbereitung erscheinen alle Cluster-Mitglieder korrekt als „Bereit“, aber das Cluster-Level wird als „Ungültig“ angegeben. Die dafür angezeigte Ursache ist ein benötigter Host-Neustart, obwohl dieser bereits durchgeführt wurde.

Problemumgehung: Klicken Sie auf das rote Warnsymbol und wählen Sie „Lösen“.

Bekannte Probleme bei NSX Manager

Neues Problem 1801325: In NSX Manager mit hoher CPU- und/oder Festplattenauslastung generierte „kritische“ Systemereignisse und Protokollmeldungen
Bei hoher Festplattenauslastung, umfangreichen Änderungen der Auftragsdaten oder einer großen Auftragswarteschlange auf NSX Manager können ein oder mehrere der folgenden Probleme auftreten:

  • „Kritische“ Systemereignisse im vSphere Web Client
  • Hohe Festplattenauslastung auf NSX Manager für die Partition /common
  • Hohe CPU-Auslastung über einen längeren Zeitraum oder in regelmäßigen Intervallen
  • Negative Auswirkungen auf die Leistung von NSX Manager

Problemumgehung: Wenden Sie sich an den VMware-Kundensupport. Weitere Informationen dazu enthält der VMware-Knowledgebase-Artikel 2147907.

Neues Problem 1781080: DNS-Suchkonfiguration schlägt fehl, wenn mehr als eine Domäne mit Kommas als Trennzeichen hinzugefügt wird
Wenn Sie NSX Manager mehr als ein Domänensuchsuffix hinzufügen, schlagen alle DNS-Lookups, die nicht den vollständig qualifizierten Namen verwenden, fehl. Dies resultiert aus einem internen Formatproblem in /etc/resolv.conf.

Problemumgehung: Verwenden Sie ein einzelnes DNS-Suchsuffix.

Neues Problem 1806368: Die Wiederverwendung von Controllern eines zuvor fehlgeschlagenen primären NSX Manager, der nach einem Failover wieder zum primären NSX Manager wird, führt dazu, dass die DLR-Konfiguration nicht an alle Hosts weitergegeben wird
Fällt in einem Cross-vCenter NSX-Setup der primäre NSX Manager aus, wird ein sekundärer NSX Manager zu einem primären heraufgestuft und ein neuer Controller-Cluster für die Verwendung mit dem neu heraufgestuften sekundären (jetzt primären) NSX Manager bereitgestellt. Wenn der primäre NSX Manager wieder in Betrieb ist, wird der sekundäre NSX Manager herabgestuft und der primäre NSX Manager wiederhergestellt. In diesem Fall wird die DLR-Konfiguration nicht an alle Hosts weitergegeben, wenn Sie die vorhandenen Controller wiederverwenden, die auf diesem primären NSX Manager vor dem Failover bereitgestellt wurden. Dieses Problem tritt nicht auf, wenn Sie stattdessen einen neuen Controller-Cluster erstellen.

Problemumgehung: Stellen Sie einen neuen Controller-Cluster für den wiederhergestellten primären NSX Manager bereit.

Neues Problem 1831131: Verbindung vom NSX Manager zu SSO schlägt bei Authentifizierung über LocalOS-Benutzer fehl
Verbindung vom NSX Manager zu SSO schlägt bei Authentifizierung über LocalOS-Benutzer fehl und produziert folgenden Fehler: „Verbindung zum NSX Manager konnte nicht hergestellt werden. Wenden Sie sich an den Administrator.“

Problemumgehung: Fügen Sie die Enterprise Admin-Rolle für nsxmanager@localos zusätzlich zu nsxmanager@domain hinzu.

Problem 1800820: Die Aktualisierung der UDLR-Schnittstelle auf einem sekundären NSX Manager ist nicht möglich, wenn die alte UDLR-Schnittstelle bereits aus dem System gelöscht wurde
In einem Szenario, in dem der globale Synchronisierungsdienst (Replikator) auf dem primären NSX Manager nicht mehr funktioniert, müssen Sie die UDLR- (Universal Distributed Logical Router, globaler verteilter logischer Router) und ULS-Schnittstellen (Universal Logical Switch, globaler logischer Switch) auf dem primären NSX Manager löschen, anschließend neue Schnittstellen erstellen und diese dann auf dem sekundären NSX Manager replizieren. In diesem Fall wird die UDLR-Schnittstelle auf dem sekundären NSX Manager nicht aktualisiert, da bei der Replizierung ein neuer ULS auf dem sekundären NSX Manager erstellt wird und der UDLR nicht mit dem neuen ULS verbunden ist.

Problemumgehung: Stellen Sie sicher, dass der Replikator ausgeführt wird, und löschen Sie die UDLR-Schnittstelle (LIF) auf dem primären NSX Manager, der über einen neu erstellten ULS als Grundlage verfügt. Erstellen Sie dann die UDLR-Schnittstelle (LIF) mit demselben zugrunde liegenden ULS erneut.

Problem 1770436: Es werden Warnungen generiert, auch wenn keine doppelte IP-Adresse vorhanden ist
Manchmal meldet der Befehl Arping, dass die NSX Manager-IP-Adresse im Netzwerk dupliziert wurde, obwohl dies nicht der Fall ist. Dadurch wird eine Falschmeldung zu diesem Ereignis generiert.

Problemumgehung: Wenden Sie sich an den VMware-Kundensupport.

Problem 1772911: Die Ausführung von NSX Manager erfolgt sehr langsam, wobei die Inanspruchnahme des Festplattenspeichers sowie die Größe der Aufgaben- und Auftragstabelle bei fast 100%-tiger CPU-Auslastung steigt
Die Situation stellt sich dann folgendermaßen dar:

  • Die NSX Manager-CPU-Auslastung liegt bei 100 % oder nähert sich regelmäßig der 100 %-Marke, und das Hinzufügen zusätzlicher Ressourcen zur NSX Manager-Appliance bewirkt keine Änderung.
  • Mit dem Befehl show process monitor in der NSX Manager-Befehlszeilenschnittstelle (CLI) wird der Java-Vorgang angezeigt, der die meisten CPU-Zyklen in Anspruch nimmt.
  • Der Befehl show filesystems in der NSX Manager-CLI zeigt an, dass das Verzeichnis /common einen sehr hohen Nutzungsgrad aufweist, etwa über 90 %.
  • Bei einigen Änderungen der Konfiguration wird die Zeit überschritten (manche dauern über 50 Minuten), und sie werden nicht wirksam.

Weitere Informationen dazu enthält der VMware-Knowledgebase-Artikel 2147907.

Problemumgehung: Wenden Sie sich zur Behebung dieses Problems an den VMware-Kundensupport.

Problem 1785142: Synchronisierungsprobleme werden auf dem primären NSX Manager verzögert angezeigt, wenn die Kommunikation zwischen dem primären und dem sekundären NSX Manager blockiert ist
Wenn die Kommunikation zwischen dem primären und dem sekundären NSX Manager blockiert ist, werden die Synchronisierungsprobleme auf dem primären NSX Manager nicht sofort angezeigt.

Problemumgehung: Warten Sie ca. 20 Minuten, bis die Kommunikation wieder aufgenommen wird.

Problem 1786066: In einer Cross-vCenter-Installation von NSX kann die Trennung eines sekundären NSX Manager dazu führen, dass NSX Manager nicht erneut als sekundärer NSX Manager verbunden werden kann
Wenn Sie in einer Cross-vCenter-Installation von NSX die Verbindung mit einem sekundären NSX Manager trennen, können Sie später diesen NSX Manager eventuell nicht mehr als sekundären NSX Manager erneut hinzufügen. Wenn Sie in einer solchen Situation versuchen, NSX Manager erneut als sekundären NSX Manager zu verbinden, wird NSX Manager auf der Registerkarte „Verwaltung“ des vSphere Web Client zwar als „Sekundär“ angegeben, die Verbindung zum primären NSX Manager wird aber nicht hergestellt.

Problemumgehung: Gehen Sie wie folgt vor:

  1. Trennen Sie den sekundären NSX Manager vom primären NSX Manager.
  2. Fügen Sie den sekundären NSX Manager dem primären NSX Manager erneut hinzu.

Problem 1713669: NSX Manager schlägt wegen einer vollen Festplatte fehl, wenn die Datenbanktabelle ai_useripmap zu groß geworden ist
Die zu große Datenbank führt zu einer vollen Festplatte der NSX Manager-Appliance und zum entsprechenden NSX Manager-Fehler. Der postgres-Vorgang kann nach einem Neustart nicht gestartet werden. Die Partition „/common“ ist voll. Dieses Problem tritt meist auf Sites mit einer großen Arbeitslast auf dem Ereignisprotokollserver (ELS, Event Log Server) und auf Sites mit hohem Guest Introspection-Datenverkehrsvolumen auf. Häufig sind davon Sites betroffen, die die identitätsbasierte Firewall (IDFW) verwenden. Weitere Informationen dazu enthält der VMware-Knowledgebase-Artikel 2148341.

Problemumgehung: Kontaktieren Sie den VMware-Kundensupport, der Ihnen bei der Behebung dieses Problems weiterhelfen kann.

Problem 1787542: Ausnahmen im Protokoll der sekundären NSX Manager nach einer DB-Wiederherstellung auf dem primären NSX Manager
Nach der Wiederherstellung der DB auf dem primären NSX Manager werden wiedereingesetzte globale DFW-Abschnitte für die sekundären NSX Manager nicht angezeigt.

Problemumgehung: Keine. Starten Sie den betreffenden sekundären NSX Manager erneut für die Wiederherstellung.

Problem 1715354: Verzögerte Verfügbarkeit der REST-API
Wenn nach dem Wechsel in den FIPS-Modus oder nach dem Beenden des FIPS-Modus der NSX Manager neu gestartet wird, dauert es eine gewisse Zeit, bis die NSX Manager-API betriebsbereit ist. Es kann dabei der Eindruck entstehen, dass die API hängt. Dies ist aber nicht der Fall. Die fehlende Betriebsbereitschaft tritt nur auf, weil die Controller Zeit benötigen, um die Verbindung mit NSX Manager wiederherzustellen. Es wird empfohlen, zu warten, bis der NSX-API-Server betriebsbereit ist. Vergewissern Sie sich, dass alle Controller verbunden sind, bevor Sie Vorgänge ausführen.

Problem 1441874: Beim Upgrade eines einzelnen NSX Manager in einer vCenter-Umgebung im verknüpften Modus wird eine Fehlermeldung ausgegeben
In einer Umgebung mit mehreren VMware vCenter-Servern, die mehrere NSX Manager umfassen, wird, wenn Sie einen oder mehrere NSX Manager unter „vSphere Web Client >Netzwerk und Sicherheit > Installation > Host-Vorbereitung“ auswählen, eine Fehlermeldung ausgegeben, die sinngemäß Folgendes besagt:
„Verbindung zum NSX Manager konnte nicht hergestellt werden. Wenden Sie sich an den Administrator.“

Problemumgehung: Weitere Informationen dazu enthält der VMware-Knowledgebase-Artikel 2127061.

Problem 1696750: Beim Zuweisen einer IPv6-Adresse zu NSX Manager über PUT API ist ein Neustart erforderlich
Beim Ändern der konfigurierten Netzwerkeinstellungen für NSX Manager via https://{NSX Manager IP address}/api/1.0/appliance-management/system/network ist ein Systemneustart erforderlich. Bis zum Neustart werden die alten Einstellungen angezeigt.

Problemumgehung: Keine.

Problem 1529178: Das Hochladen eines Server-Zertifikats, das keinen allgemeinen Namen enthält, führt zur Meldung „Interner Serverfehler“.

Wenn Sie ein Server-Zertifikat ohne einen allgemeinen Namen hochladen, wird die Meldung „Interner Serverfehler“ eingeblendet.

Problemumgehung: Verwenden Sie ein Zertifikat, das sowohl einen SubAltName als auch einen allgemeinen Namen bzw. mindestens einen allgemeinen Namen enthält

Problem 1655388: Die Benutzeroberfläche von NSX Manager 6.2.3 wird in der englischen statt in der lokalen Sprache dargestellt, wenn der IE11-/Edge-Browser im Betriebssystem Windows 10 in Japanisch, Chinesisch oder Deutsch verwendet wird.

Wenn Sie NSX Manager 6.2.3 mit dem IE11-/Edge-Browser im Betriebssystem Windows 10 in Japanisch, Chinesisch und Deutsch starten, wird die Oberfläche in englischer Sprache dargestellt.

Problemumgehung: Führen Sie die folgenden Schritte aus:

  1. Starten Sie den Microsoft Registrierungs-Editor (regedit.exe) und wechseln Sie zu Computer > HKEY_CURRENT_USER > SOFTWARE > Microsoft > Internet Explorer > International.
  2. Ändern Sie den Wert von AcceptLanguage in die lokale Sprache. Wenn Sie beispielsweise die Benutzeroberfläche auf Deutsch darstellen möchten, ändern Sie den Wert und setzen Sie DE an die erste Position.
  3. Starten Sie den Browser neu und melden Sie sich erneut beim NSX Manager an. Die entsprechende Sprache wird dann dargestellt.

Problem 1435996: Im CSV-Format aus NSX Manager exportierte Protokolldateien sind mit einem Zeitstempel (Zeitraum, nicht Datum/Uhrzeit) versehen.
Protokolldateien, die als CSV aus NSX Manager mit vSphere Web Client exportiert werden, werden mit einem Zeitstempel mit der Epochenzeit in Millisekunden versehen, anstatt mit der entsprechenden Zeit basierend auf der Zeitzone.

Problemumgehung: Keine.

Problem 1644297: Das Hinzufügen/Löschen eines DFW-Abschnitts im primären NSX erstellt zwei gespeicherte DFW-Konfigurationen auf dem sekundären NSX
In einem Cross-vCenter-Setup werden, wenn dem primären NSX Manager ein zusätzlicher globaler oder lokaler DFW-Abschnitt hinzugefügt wurde, zwei DFW-Konfigurationen auf dem sekundären NSX Manager gespeichert. Dieses Problem beeinträchtigt zwar nicht die Funktionalität, führt aber dazu, dass die Obergrenze für gespeicherte Konfigurationen schneller erreicht wird, sodass eventuell zentrale Konfigurationen überschrieben werden.

Problemumgehung: Keine.

Problem 1534877: Der NSX Manager-Dienst wird nicht gestartet, wenn der Hostname mehr als 64 Zeichen enthält
Bei der Erstellung eines Zertifikats über die OpenSSL-Bibliothek darf der Hostname nicht länger als 64 Zeichen sein.

Problem 1537258: Die NSX Manager-Auflistung erfolgt für die Anzeige in Web Client sehr langsam
In vSphere 6.0-Umgebungen mit mehreren NSX Managern kann es vorkommen, dass der vSphere Web Client bis zu zwei Minuten benötigt, um die Liste der NSX Manager anzuzeigen, wenn für die Validierung des angemeldeten Benutzers eine große Anzahl von AD-Gruppen verwendet wird. Beim Versuch, die NSX Manager-Liste anzuzeigen, kann es zu einem Zeitüberschreitungsfehler in Bezug auf den Datendienst kommen. Für dieses Problem gibt es keine Umgehung. Warten Sie, bis die Liste geladen ist bzw. bis Sie erneut angemeldet sind, um die NSX Manager-Liste einsehen zu können.

Problem 1534606: Die Seite der Hostvorbereitung kann nicht geladen werden
Bei der Ausführung von vCenter im verknüpften Modus müssen alle vCenter mit einem NSX Manager derselben NSX-Version verbunden sein. Sollten die NSX-Versionen nicht übereinstimmen, kann der vSphere Web Client nur mit dem NSX Manager kommunizieren, der die höhere NSX-Version ausführt. Es erscheint eine Fehlermeldung etwa in der Form „Konnte keine Verbindung zum NSX Manager herstellen. Wenden Sie sich an den Administrator“ auf der Registerkarte „Hostvorbereitung“.

Problemumgehung: Es wird empfohlen, für alle NSX Manager ein Upgrade auf dieselbe NSX-Softwareversion durchzuführen.

Problem 1386874: Registerkarte „Networking & Security“ wird im vSphere Web Client nicht angezeigt
Nach dem Upgrade von vSphere auf Version 6.0 wird die Registerkarte „Networking & Security“ nicht angezeigt, wenn Sie sich mit dem Root-Benutzernamen beim vSphere Web Client anmelden.

Problemumgehung: Melden Sie sich als „administrator@vsphere.local“ oder als beliebiger anderer vCenter-Benutzer an, der vor dem Upgrade in vCenter Server vorhanden war und dessen Rolle in NSX Manager definiert war.

Problem 1027066: vMotion von NSX Manager zeigt möglicherweise die folgende Fehlermeldung an: „Die virtuelle Ethernet-Karte 'Netzwerkadapter 1' wird nicht unterstützt“
Sie können diesen Fehler ignorieren. Das Netzwerk funktioniert nach vMotion ordnungsgemäß.

Problem 1477041: Auf der Übersichtsseite der virtuellen NSX Manager-Appliance wird kein DNS-Name angezeigt
Beim Anmelden bei der virtuellen NSX Manager-Appliance weist die Zusammenfassungsseite ein Feld für den DNS-Namen auf. Dieses Feld bleibt leer, selbst wenn ein DNS-Name für die NSX Manager-Appliance festgelegt wurde.

Problemumgehung: Sie können den NSX Manager-Hostnamen und die Suchdomänen auf der Seite "Verwalten: Netzwerk" anzeigen.

Problem 1492880: Die NSX Manager-Benutzeroberfläche wird nach dem Ändern des Kennworts über die NSX-Befehlszeilenschnittstelle nicht automatisch abgemeldet
Wenn Sie bei NSX Manager angemeldet sind und Ihr Kennwort über die CLI kürzlich geändert haben, können Sie mit Ihrem alten Kennwort an der NSX Manager-CLI angemeldet bleiben. Normalerweise sollten Sie vom NSX Manager-Client bei einer Zeitüberschreitung der Sitzung nach Inaktivität automatisch abgemeldet werden.

Problemumgehung: Melden Sie sich bei der NSX Manager-Benutzeroberfläche ab und mit dem neuen Kennwort wieder an.

Problem 1468613: Hostname des Netzwerks kann nicht bearbeitet werden
Nachdem Sie sich bei der virtuellen NSX Manager-Appliance angemeldet haben und zu Appliance Management navigiert sind, auf die Einstellungen „Appliance verwalten“ und dann auf „Netzwerk“ unter „Einstellungen“ geklickt haben, um den Hostnamen des Netzwerks zu verwalten, erhalten Sie möglicherweise einen Fehler in Bezug auf eine ungültige Domänennamenliste. Dies geschieht, wenn die im Feld „Suchdomänen“ angegebenen Domänennamen durch Leerraumzeichen anstatt durch Kommas getrennt sind. NSX Manager akzeptiert nur Domänennamen, die durch Kommas getrennt sind.
Problemumgehung: Führen Sie die folgenden Schritte aus:

  1. Melden Sie sich bei der virtuellen NSX Manager-Appliance an.

  2. Klicken Sie unter Appliance-Verwaltung auf Appliance-Einstellungen verwalten.

  3. Klicken Sie im Fensterbereich „Einstellungen“ auf Netzwerk.

  4. Klicken Sie auf Bearbeiten neben DNS-Server.

  5. Ersetzen Sie im Feld „Suchdomänen“ alle Leerraumzeichen durch Kommas.

  6. Klicken Sie auf OK, um die Änderungen zu speichern.

Problem 1436953: Falsches Systemereignis wird generiert, selbst nach der erfolgreichen Wiederherstellung von NSX Manager aus einer Sicherung
Nach der erfolgreichen Wiederherstellung des NSX Manager über eine Sicherung werden die folgenden Systemereignisse im vSphere Web Client angezeigt, wenn Sie zu Networking & Security: NSX Manager: Überwachen: Systemereignisse navigieren.

  • Das Wiederherstellen von NSX Manager aus der Sicherung ist fehlgeschlagen (mit Schweregrad „Kritisch“).

  • Das Wiederherstellen von NSX Manager wurde erfolgreich abgeschlossen (mit Schweregrad „Zur Information“.

Problemumgehung: Wenn die abschließende Systemereignisnachricht als erfolgreich angezeigt wird, können Sie die vom System generierten Ereignisnachrichten ignorieren.

Problem 1489768: Änderung im Verhalten des NSX REST-API-Aufrufs zum Hinzufügen eines Namespace in einem Datencenter
In NSX 6.2 gibt der REST-API-Aufruf POST https://<nsxmgr-ip>/api/2.0/namespace/datacenter/ eine URL mit einem absoluten Pfad zurück. Beispiel: http://198.51.100.3/api/2.0/namespace/api/2.0/namespace/datacenter/datacenter-1628/2. In früheren Versionen von NSX hat dieser API-Aufruf eine URL mit einem relativen Pfad zurückgegeben. Beispiel: /api/2.0/namespace/datacenter/datacenter-1628/2.

Problemumgehung: Keine.

Bekannte Probleme bei logischen Netzwerken und bekannte Probleme bei NSX Edge

Neues Problem 1878081: Einige der Routen wurden aus der Weiterleitungstabelle im Gateway für die Edge-Dienste gelöscht
In einigen wenigen Instanzen wurden einige der Routen aus der Weiterleitungstabelle gelöscht. Dies führt zu einem Ausfall des Datenverkehrs.

Problemumgehung: Starten Sie den Edge-Knoten neu.

Neues Problem 1492497: NSX Edge-DHCP-Datenverkehr kann nicht gefiltert werden
Sie können auf den DHCP-Netzwerkdatenverkehr auf einem NSX Edge keine Firewallfilter anwenden, da der DHCP-Server auf einem NSX Edge RAW-Sockets verwendet, die den TCP/IP-Stack umgehen.

Problemumgehung: Keine.

Neues Problem 1781438: Auf den ESG- oder DLR-NSX Edge-Appliances zeigt der Routing-Dienst keine Fehlermeldungen an, wenn das BGP-Pfadattribut MULTI_EXIT_DISC mehr als einmal empfangen wird
Der Edge-Router oder der Distributed Logical Router zeigt keine Fehlermeldung an, wenn er mehr als einmal das BGP-Pfadattribut MULTI_EXIT_DISC empfängt. Gemäß RFC 4271 [Abschnitt 5] darf das gleiche Attribut (d. h. Attribute gleichen Typs) nur einmal im Feld „Pfadattribute“ einer bestimmten UPDATE-Meldung enthalten sein.

Problemumgehung: Keine.

Neues Problem 1786515: Benutzer mit Sicherheitsadministratorrechten können die Load Balancer-Konfiguration nicht über die Benutzeroberfläche von vSphere Web Client bearbeiten
Ein Benutzer mit den Rechten eines Sicherheitsadministrators für ein bestimmtes NSX Edge kann die globale Load-Balancer-Konfiguration für dieses Edge nicht mit der Benutzeroberfläche von vSphere Web Client bearbeiten. Die folgende Fehlermeldung wird angezeigt: „Der Benutzer ist nicht berechtigt, auf das Objekt ‚Global‘ und die Funktion si.service zuzugreifen. Überprüfen Sie den Geltungsbereich für den Objektzugriff und die Funktionsberechtigungen für den Benutzer.“

Problemumgehung: Keine.

Neues Problem 1849760: 100 % CPU-Auslastung während und nach einem Ausfall des physisches Netzwerks Der Routing-Vorgang beansprucht eventuell CPU-Leistung, wenn bestimmte Präfixe über das IBGP-Netzwerk abgerufen werden, etwa wenn der nächste Hop zum Präfixsubnetz gehört.

Problemumgehung: Wenn dieses Problem auftritt, wird empfohlen, Präfixe für das iBGP-Netzwerk zwischen ESG und DLR herauszufiltern und nur die Standardroute für iBGP anzukündigen.

Neues Problem 1849042/1849043: Das Administratorkonto wird gesperrt, wenn der Ablauf von Kennwörtern auf der NSX Edge-Appliance konfiguriert ist
Wenn für den Admin-Benutzer auf der NSX Edge-Appliance der Ablauf von Kennwörtern konfiguriert ist, wird der Benutzer nach dem Ablauf des Kennworts in einem Zeitraum von sieben Tagen zur Änderung des Kennworts aufgefordert, wenn er sich bei der Appliance anmeldet. Kommt es beim Ändern des Kennworts zu Fehlern, wird das Konto gesperrt. Wenn darüber hinaus das Kennwort zum Zeitpunkt der Anmeldung an der CLI-Eingabeaufforderung geändert wird, erfüllt das neue Kennwort eventuell nicht die Richtlinie für sichere Kennwörter, die von der Benutzeroberfläche und REST erzwungen wird.

Problemumgehung: Um dieses Problem zu vermeiden, müssen Sie das Administratorkennwort immer mit der Benutzeroberfläche oder der REST-API ändern, bevor das vorhandene Kennwort abläuft. Wenn das Konto gesperrt ist, können Sie mit der Benutzeroberfläche oder der REST-API auch ein neues Kennwort konfigurieren. Das Konto wird dann wieder entsperrt.

Neues Problem 1711013: Synchronisierung der FIB zwischen aktivem und Standby-NSX Edge nach dem Neustart der Standby-VM dauert 15 Minuten
Wenn ein Standby-NSX Edge ausgeschaltet ist, wird die TCP-Sitzung zwischen dem aktiven und dem Standby-Modus nicht geschlossen. Das aktive Edge erkennt, dass der Standby-Modus nach dem Keepalive (KA-)Ausfall inaktiv ist (15 Minuten lang). Nach 15 Minuten wird eine neue Socket-Verbindung mit dem Standby-Edge hergestellt, und die FIB wird zwischen dem aktivem Edge und dem Standby-Edge synchronisiert.

Problemumgehung: Keine.

Neues Problem 1733282: NSX Edge unterstützt keine statischen Geräterouten mehr
NSX Edge unterstützt keine Konfiguration statischer Routen mit NULL-Nexthop-Adresse.

Problemumgehung: Keine.

Neues Problem 1860583: Verwendung von Remote-Syslog-Servern als FQDN kann das Routing beeinträchtigen, wenn DNS nicht erreichbar ist
Wenn auf einem NSX Edge Remote-Syslog-Server mithilfe des FQDN konfiguriert sind und DNS nicht erreichbar ist, können davon die Routing-Funktionen beeinträchtigt werden. Das Problem tritt eventuell nur sporadisch auf.

Problemumgehung: Es wird empfohlen, IP-Adressen anstelle des FQDN zu verwenden.

Neues Problem 1861814: SSL VPN schlägt bei Verwendung von Mac OS Sierra oder El Capitan auf NSX fehl
In einer NSX for vSphere 6.3.x-Umgebung mit konfiguriertem und aktiviertem SSL VPN schlägt dieses SSL VPN auf einem Mac mit OS Sierra oder mit El Capitan mit folgender Meldung fehl:
„Verbindung zu Gateway wurde aufgrund eines Fehlers bei der Validierung des Serverzertifikats getrennt.“
Windows-basierte Computer sind davon nicht betroffen.

Problemumgehung: Weitere Informationen und die Problemumgehung finden Sie im VMware-Knowledgebase-Artikel 2150054.

Neues Problem 1850773: NSX Edge NAT meldet eine ungültige Konfiguration, wenn in der Load-Balancer-Konfiguration mehrere Ports verwendet werden
Dieses Problem tritt jedes Mal auf, wenn Sie einen virtuellen Load-Balancer-Server mit mehr als einem Port konfigurieren. Die NAT kann bei einer solchen Konfiguration des betroffenen NSX Edge nicht mehr verwendet werden.

Problemumgehung: Weitere Informationen und die Problemumgehung finden Sie im VMware-Knowledgebase-Artikel 2149942.

Neues Problem 1852988: ESG kündigt BGP-Routen mit der Nachbaradresse als nächsten Hop an
ESG kündigt BGP-Routen zum Nachbarn mit dem nächsten Hop als Nachbaradresse anstelle der lokalen Adresse an, wenn für den Nachbarn die Option „Default Originate“ aktiviert ist. Dies tritt auf, wenn die Uplink-BGP-Sitzung unterbrochen wird.

Problemumgehung: Unterbrechen Sie die BGP-Sitzung mit dem Nachbarn, für den die Routen mit den nächsten Hops als Nachbaradresse und nicht als lokale Adresse angekündigt wurden. Dadurch wird sichergestellt, dass der Routing Table Manager eine Neuberechnung durchführt und die richtigen Routen erneut angekündigt werden.

Neues Problem 1849760: Routing-Vorgang beansprucht eventuell CPU-Leistung, wenn bestimmte Präfixe über das IBGP-Netzwerk abgerufen werden, etwa wenn der nächste Hop zum Präfixsubnetz gehört
Das Problem tritt bei einer Konfiguration mit einem Peering der DLR-NSX Edge-Appliance (Kontroll-VM) mit ESGs in IBGP und einem Peering der ESGs mit physischen Routern über EBGP auf. Darüber hinaus wird für die DLR-Kontroll-VM die Hochverfügbarkeit ausgeführt. Für die BGP-Sitzung werden eng getaktete Timer verwendet. Wenn das zugrunde liegende Netzwerk instabil wird und sich dieser Zustand auf die BGP-Nachbarn überträgt, ruft die DLR-Kontroll-VM auch erneut die Präfixe für den instabilen Nachbarn ab und muss diese auflösen. Wenn das abgerufene Präfixsubnetz sich auf die IP-Adresse des nächsten Hop bezieht (z. B. 10.0.0.0/8 über 10.1.1.2), kann der Routing-Vorgang in einer rekursiven Schleife münden.

Problemumgehung: Wenn Sie solche Präfixe für die NSX-Topologie ankündigen müssen, können ESGs die Option „Default Originate“ aktivieren, die Standardroute zu physischen Routern mithilfe von BGP-Nachbarfiltern blockieren und die Standardroute nur zum DLR zulassen. Im Wesentlichen besteht die Lösung darin, den Abruf von Präfixen zu verhindern.

Neues Problem 1798847: In einem Cross-vCenter NSX-Setup kann es vorkommen, dass die Aktualisierung des VXLAN-UDP-Ports dauerhaft hängen bleibt
Wenn der primäre NSX Manager über keinen konfigurierten sekundären NSX Manager verfügt, bleibt die Aktualisierung des VXLAN-UDP-Ports dauerhaft hängen.

Problemumgehung: Setzen Sie mithilfe der NSX Manager-API die Aktualisierung des Ports auf dem primären NSX Manager fort.

Problem 1791264: Durch Doppelklicken auf eine Transportzone kann der CDO-Modus nicht aktiviert/deaktiviert werden.
Wenn Sie versuchen, den CDO-Modus auf der Seite „Übersicht“, die durch Doppelklicken auf eine Transportzone im vSphere Web Client aufgerufen wird, zu aktivieren oder zu deaktivieren, hat dies keine Auswirkungen.

Problemumgehung: Gehen Sie wie folgt vor:

  1. Wechseln Sie mit Installation > Vorbereitung des logischen Netzwerks > Transportzonen zurück zur Seite mit den Transportzonen und wählen Sie die gewünschte Transportzone aus.
  2. Wählen Sie aus dem Dropdown-Menü Aktionen die Option CDO aktivieren/deaktivieren aus.
  3. Die ausgewählte Aktion wird wirksam.

Problem 1773500: Ungültige Route (0.0.0.0/32) führt zum Absturz von NSX
Wenn Sie die Route 0.0.0.0/32 auf dem NSX-DLR weitergeben, wird diese Route nicht unterstützt und zurückgewiesen. Dies führt jedoch weiterhin zu einem Absturz mit violettem Diagnosebildschirm (Purple Screen of Death, PSOD), wenn die zugehörige logische Schnittstelle gelöscht und erneut mit einer IP-Adresse desselben Subnetzes hinzugefügt wird.

Problemumgehung: 0.0.0.0/32 ist keine gültige Route. Konfigurieren Sie diese nicht oder verwenden Sie eine Routemap, um sie zurückzuweisen.

Problem 1764258: Der Datenverkehr geht nach einem Hochverfügbarkeits-Failover oder nach einer erzwungenen Synchronisierung auf einem NSX Edge, das mit einer Teilschnittstelle konfiguriert ist, bis zu acht Minuten verloren
Wenn ein Hochverfügbarkeits-Failover ausgelöst oder eine erzwungene Synchronisierung über eine Teilschnittstelle gestartet wird, geht der Datenverkehr bis zu acht Minuten lang verloren.

Problemumgehung: Verwenden Sie für die Hochverfügbarkeit keine Teilschnittstellen.

Problem 1771760: SNMP-Antwortpakete mit einem OID vom Typ „Counter64“ werden durch das NSX Edge verworfen, wenn NAT nicht aktiviert ist.
Das SNMP-ALG in NSX Edge kann keine Counter64-Typen von einem SNMP-Antwortpaket verarbeiten. Das Paket wird deshalb verworfen. Als Ergebnis erhält der Client keine Antwort für die Anforderung.

Problemumgehung: Wenn dieses Problem auftritt, wenden Sie sich an den VMware-Kundensupport.

Problem 1767135: Fehler beim Versuch, auf Zertifikate und Anwendungsprofile unter Load Balancer zuzugreifen
Benutzer mit Security-Administrator-Rechten und Edge-Geltungsbereich können bei Verwendung des Load Balancer nicht auf Zertifikate und Anwendungsprofile zugreifen. Im vSphere Web Client werden entsprechende Fehlermeldungen angezeigt.

Problemumgehung: Keine.

Problem 1792548: NSX Controller bleibt möglicherweise mit folgender Meldung hängen: „Warten auf Verknüpfung mit Cluster“
NSX Controller bleibt möglicherweise mit folgender Meldung hängen: „Warten auf Verknüpfung mit Cluster“ (CLI-Befehl:show control-cluster status). Dieses Problem tritt auf, wenn bei der Aktivierung des Controllers für die Schnittstellen eth0 und breth0 dieselbe IP-Adresse konfiguriert wurde. Sie können dies mithilfe des folgenden CLI-Befehls auf dem Controller überprüfen: show network interface

Problemumgehung: Wenden Sie sich an den VMware-Kundensupport.

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 1804116: Der logische Router meldet einen fehlerhaften Status auf einem Host, für den keine Kommunikation mit NSX Manager möglich ist
Wenn ein logischer Router auf einem Host eingeschaltet oder erneut bereitgestellt wird, der nicht mit NSX Manager kommunizieren kann (aufgrund eines NSX-VIB-Upgrade-/Installationsfehlers oder eines Hostkommunikationsproblems), meldet der logische Router einen fehlerhaften Status, und die fortlaufende automatische Wiederherstellung über eine erzwungene Synchronisierung kann nicht durchgeführt werden.

Problemumgehung: Nach der Behebung des Kommunikationsproblems zwischen dem Host und NSX Manager starten Sie das NSX Edge manuell neu und warten Sie, bis alle Schnittstellen aktiv sind. Diese Problemumgehung wird nur für logische Router und nicht für das NSX Edge Services Gateway (ESG) benötigt, da die automatische Wiederherstellung über eine erzwungene Synchronisierung das NSX Edge neu startet.

Problem 1783065: Bei Load Balancer ist die gemeinsame Konfiguration von UDP-Port und TCP über IPv4- und IPv6-Adressen nicht möglich
UDP unterstützt nur IPv4-IPv4, IPv6-IPv6 (Frontend-Backend). NSX Manager enthält einen Fehler. Auch wenn die IPv6-Link-Local-Adresse gelesen und als eine IP-Adresse des Gruppierungsobjekts übertragen wird, können Sie das IP-Protokoll nicht für die LB-Konfiguration verwenden.

Im Folgenden finden Sie eine beispielhafte LB-Konfiguration, die das Problem veranschaulicht:
In der Load-Balancer-Konfiguration wird der Pool „vCloud_Connector“ mit einem Gruppierungsobjekt (vm-2681) als Poolmitglied konfiguriert. Dieses Objekt enthält sowohl IPv4- als auch IPv6-Adressen. Dies wird von der LB-L4-Engine nicht unterstützt.

{
              "algorithm" : {
        ...
    },
              "members" : [
        {
            ...  ,
            ...
        }
              ],
              "applicationRules" : [],
              "name" : "vCloud_Connector",
              "transparent" : {
                 "enable" : false
              }
        }

  {
              "value" : [
                 "fe80::250:56ff:feb0:d6c9",
                 "10.204.252.220"
              ],
              "id" : "vm-2681"
            }

Problemumgehung:

  • Option 1: Geben Sie unter „Poolmitglied“ die IP-Adresse des Poolmitglieds statt der Gruppierungsobjekte ein.
  • Option 2: Verwenden Sie keine IPv6-Adressen in den VMs.

Problem 1773127: Bei Setups mit einer erheblichen Anzahl an Hosts und logischen Switches wird der Bildschirm, der die Hosts eines bestimmten logischen Switch anzeigt, nicht korrekt geladen.
Wenn Sie „Logischer Switch“ > „Zugehörige Objekte“ > „Hosts“ aus Ihrem Setup mit einer erheblichen Anzahl an Hosts auswählen, kann der vSphere Web Client nach einer Wartezeit von einigen Minuten nicht geladen werden. Es wird folgende Fehlermeldung angezeigt: Für den Datendienst wurde eine Zeitüberschreitung festgestellt, da eine Backend-Aufgabe mehr als 120 Sekunden in Anspruch genommen hat. Dieses Problem tritt auf, weil der Remote-API-Aufruf für NSX Manager zu lange für die Rückgabe benötigt.

Problemumgehung: Sie können dieses Problem auf zweifache Weise umgehen:

  • Erste Möglichkeit: Erhöhen Sie den Grenzwert für die API-Zeitüberschreitung wie im VMware-Knowledgebase-Artikel 2040626 beschrieben. Nach der Erhöhung dieses Wertes müssen Sie eventuell den vSphere Web Client neu starten. Die Wahrscheinlichkeit ist hoch, dass nach der Erhöhung des Grenzwertes für die Zeitüberschreitung kein Fehler mehr auftritt. Sie müssen aber etwa zwei bis vier Minuten warten, bis die Seite erneut geladen wird.
  • Zweite Möglichkeit: Wenn Sie nur die zugehörigen Hosts korrekt anzeigen möchten, wechseln Sie zu „Home“ > „Netzwerk“ > „Portgruppe“ > „Zugehörige Objekte“ > „Hosts“, um die Liste der Hosts aufzurufen, die dem logischen Switch zugeordnet sind.

Problem 1777792: Wenn für den Peer-Endpoint „BELIEBIG“ festgelegt wurde, kann keine IPSec-Verbindung hergestellt werden
Wenn in der IPSec-Konfiguration für NSX Edge der Remote-Peer-Endpoint auf „BELIEBIG“ festgelegt wurde, verhält sich das Edge wie ein IPSec-„Server“ und wartet auf Remote-Peers zur Initiierung von Verbindungen. Wenn allerdings der Initiator eine Anforderung zur Authentifizierung mithilfe von PSK+XAUTH sendet, wird von Edge folgende Fehlermeldung angezeigt: „Ursprüngliche Nachricht des Hauptmodus wurde unter XXX.XXX.XX.XX:500 empfangen, aber es wurde keine Verbindung mit der Richtlinie PSK+XAUTH autorisiert“. IPSec kann dann nicht eingerichtet werden.

Problemumgehung: Verwenden Sie in der IPSec-VPN-Konfiguration anstelle von „BELIEBIG“ eine ganz bestimmte IP-Adresse oder einen FQDN für den Peer-Endpoint.

Problem 1770114: Fehlermeldung auf Clusterebene wird nach erfolgreicher Hostvorbereitung nicht gelöscht
Wenn Sie einem Cluster einen IP-Pool zuweisen, der nicht über ausreichend IP-Adressen verfügt, und dann versuchen, diesem Cluster einen Host hinzuzufügen, erhalten Sie die Fehlermeldung „Unzureichende IP-Adressen“. Auch wenn Sie dann diesem Pool zusätzliche IP-Adressen hinzufügen und dieser Cluster daraufhin weitere Hosts erhalten kann, verbleibt die Fehlermeldung auf der Clusterebene.

Problemumgehung: Wenden Sie sich an den VMware-Kundensupport.

Problem 1789088: NSX Edge bleibt hängen, wenn in der Befehlzeile die Eingabeaufforderung grub eingegeben wird
NSX Edge kann eventuell nicht gestartet werden und bleibt eventuell bei der grub-Eingabeaufforderung der Befehlszeile hängen.

Problemumgehung:

  • Untersuchen Sie als Erstes Folgendes:
    1. Prüfen Sie mit dem Befehl set die vorhandene Umgebung.
    2. Ermitteln Sie mit den Befehlen ls und cat die Datei /boot/grub/grub.cfg und entfernen Sie diese.
      grub> ls /boot
      grub> ls /boot/grub
      grub> cat /boot/grub/grub.cfg
      
    3. Erfassen Sie die Hostprotokolle zu diesem Zeitpunkt (möglichst nah am Auftreten des Problems). Einige NFS-Protokolle zeigen eventuell ein NFS-Speicherproblem an.
  • Als Nächstes starten Sie NSX Edge manuell. Gehen Sie in der Reihenfolge vor, wie im Folgenden beschrieben (führen Sie den jeweils folgenden Schritt nur dann aus, wenn das Edge mit dem Schritt zuvor nicht startet):

    1. Starten Sie die Edge-VM mithilfe der Option „Power-Neustart“ im vSphere Web Client neu.

    2. ODER geben Sie die grub-Konfigurationsdatei erneut an. Damit soll das Menü geladen werden, wodurch das Edge sofort gestartet werden kann.
      Führen Sie bei der grub-Eingabeaufforderung den folgenden Befehl aus:

      grub> configfile /boot/grub/grub.cfg

    3. ODER führen Sie bei der grub-Eingabeaufforderung die folgenden Befehle aus:
      grub> insmod ext2
      grub> set root=(hd0,1)
      grub> linux /boot/vmlinuz loglevel=3 root=/dev/sda1
      grub> boot
      

Problem 1741158: Erstellen eines neuen, nicht konfigurierten NSX Edge und Anwenden der Konfiguration kann zu vorzeitiger Aktivierung des Edge-Dienstes führen
Wenn Sie die NSX API verwenden, um einen neuen, nicht konfigurierten NSX Edge zu erstellen, dann einen API-Aufruf durchführen, um einen der Edge-Dienste auf diesem Edge zu deaktivieren (also beispielsweise für „dhcp-enabled“ „false“ festlegen) und schließlich die Konfigurationsänderungen auf den deaktivierten Edge-Dienst anwenden, wird dieser umgehend aktiviert.

Problemumgehung: Nachdem Sie eine Konfigurationsänderung an einem Edge-Dienst vornehmen, der deaktiviert bleiben soll, führen Sie sofort einen PUT-Aufruf durch, um das Aktivierungs-Flag für diesen Dienst auf „false“ festzulegen.

Problem 1758500: Statische Route mit mehreren nächsten Hops wird nicht in NSX Edge-Routing- und -Weiterleitungstabellen installiert, wenn es sich bei mindestens einem der nächsten konfigurierten Hops um die vNIC-IP-Adresse des Edge handelt
Bei ECMP und mehreren Nächster-Hop-Adressen kann unter NSX die vNIC-IP-Adresse des Edge als nächster Hop konfiguriert werden, wenn zumindest eine der Nächster-Hop-IP-Adressen gültig ist. Dies wird ohne Fehlermeldungen und Warnungen zugelassen, aber die Netzwerkroute wird aus der Tabelle zum Edge-Routing/-Weiterleiten entfernt.

Problemumgehung: Konfigurieren Sie die vNIC-IP-Adresse des Edge nicht als nächsten Hop in der statischen Route, wenn Sie ECMP verwenden.

Problem 1716464: NSX-Load Balancer führt keine Weiterleitung zu VMs durch, die kürzlich mit einem Sicherheits-Tag versehen wurden.
Wenn wir zwei VMs mit einem bestimmten Tag bereitstellen und anschließend einen LB für die Weiterleitung zu dem entsprechenden Tag konfigurieren, führt der LB die Weiterleitung zu diesen beiden VMs erfolgreich durch. Falls wir jedoch eine dritte VM mit dem entsprechenden Tag bereitstellen, führt der LB die Weiterleitung nur zu den ersten beiden VMs durch.

Problemumgehung: Klicken Sie im LB-Pool auf „Speichern“. Dadurch werden die VMs neu geprüft und das Routing zu den neu gekennzeichneten VMs wird gestartet.

Problem 1753621: Wenn ein Edge mit einem privaten lokalen AS Weiterleitungen an EBGP-Peers sendet, werden sämtliche private AS-Pfade aus den gesendeten BGP-Routing-Aktualisierungen gelöscht.
NSX weist derzeit eine Beschränkung auf, die verhindert, dass der vollständige AS-Pfad für eBGP-Nachbarn freigegeben wird, wenn der AS-Pfad nur private AS-Pfade enthält. Auch wenn dies in den meisten Fällen das gewünschte Verhalten ist, gibt es Fälle, in denen der Administrator möglicherweise private AS-Pfade für einen eBGP-Nachbarn freigeben möchte.

Problemumgehung: Es ist keine Umgehung verfügbar, bei der der Edge alle AS-Pfade in der BGP-Aktualisierung ankündigt.

Problem 1461421: In der Ausgabe des Befehls „show ip bgp neighbor“ für NSX Edge wird die bisherige Anzahl an zuvor eingerichteten Verbindungen beibehalten

Mit dem Befehl „show ip bgp neighbor“ wird angezeigt, wie oft für einen bestimmten Peer die Maschine mit dem Status „BGP“ in den Status „Eingerichtet“ übergegangen ist. Die Änderung des Kennworts einer MD5-Authentifizierung führt dazu, dass die Peer-Verbindung aufgehoben und dann erneut erstellt wird, wodurch die Zählung gelöscht wird. Dieses Problem tritt nicht mit einem Edge-DLR auf.

Problemumgehung: Zum Löschen der Zählung führen Sie den Befehl „clear ip bgp neighbor“ aus.

Problem 1676085: Eine Aktivierung der Edge-HA ist nicht möglich, wenn keine Ressourcenreservierung durchgeführt werden kann

Ab der Version NSX for vSphere 6.2.3 scheitert die Aktivierung der Hochverfügbarkeit (High Availability, HA) auf einem vorhandenen Edge, wenn nicht ausreichend Ressourcen für eine zweite Edge-VM-Appliance reserviert werden können. Die Konfiguration wird auf die letzte bekannte brauchbare Konfiguration zurückgesetzt. In vorherigen Versionen wird die Edge-VM, wenn die HA nach dem Scheitern der Edge-Bereitstellung und der Ressourcenreservierung aktiviert wird, trotzdem erstellt.

Problemumgehung: Dies ist eine erwartete Änderung des Verhaltens.

Problem 1656713: Auf dem NSX Edge sind nach einem HA-Failover keine IPSec-Sicherheitsrichtlinien vorhanden. Der Datenverkehr kann nicht über den Tunnel geleitet werden.

Ein Switchover mithilfe von Standby > Aktiv ist für den über IPSec-Tunnel verlaufenden Datenverkehr nicht möglich.

Problemumgehung: Deaktivieren/aktivieren Sie IPSec nach dem NSX Edge-Switchover.

Problem 1354824: Wenn eine Edge-VM beschädigt ist oder aus anderen Gründen wie z. B. wegen eines Stromausfalls nicht erreicht werden kann, werden Systemereignisse generiert, wenn die Systemstatusprüfung von NSX Manager scheitert

Die Registerkarte „Systemereignisse“ zeigt Ereignisse zum Status „Edge Unreachability“ (Edge nicht erreichbar) an. In der NSX Edges-Liste wird aber möglicherweise weiterhin der Status „Bereitgestellt“ dargestellt.

Problemumgehung: Rufen Sie mit der folgenden API detaillierte Statusinformationen zu einem NSX Edge ab:

  GET https://NSX-Manager-IP-Address/api/4.0/edges/edgeId/status?detailedStatus=true 

Problem 1556924: Der L3-Konnektivitätsverlust mit VXLAN führt zu einem „Würde blockieren“-Fehler

Wenn die DLR-LIFs auf dem Host konfiguriert sind, der zugrunde liegende VXLAN-Layer aber nicht komplett vorbereitet wurde, kann die Konnektivität einiger DLR-LIFs beeinträchtigt sein. Einige VMs des DLR sind nicht erreichbar. Möglicherweise sind Protokolleinträge in der Art „Failed to Create VXLAN trunk status: Would block“ (VXLAN-Trunk-Status kann nicht erstellt werden: Würde blockieren) in der Datei /var/log/vmkernel.log vorhanden.

Problemumgehung: Sie können die LIFs löschen und dann erneut erstellen. Eine andere Möglichkeit ist ein Neustart der betroffenen ESXi-Hosts.

Problem 1647657: Show-Befehle auf einem ESXi-Host mit DLR (Distributed Logical Router) zeigen maximal 2000 Routen pro DLR-Instanz an

Show-Befehle auf einem ESXi-Host mit aktiviertem DLR stellen maximal 2000 Routen pro DLR-Instanz dar, auch wenn mehr Routen ausgeführt werden. Dabei handelt es sich aber nur um ein Anzeigeproblem, d. h. der Datenpfad ist für alle Routen wie vorgesehen funktionsfähig.

Problemumgehung: Keine.

Problem 1634215: Die Ausgabe von OSPF CLI-Befehlen gibt nicht wieder, ob das Routing deaktiviert ist.

Wenn OSPF deaktiviert ist, wird in der Ausgabe der CLI-Routing-Befehle nicht "OSPF is disabled" angezeigt. Die Ausgabe ist leer.

Problemumgehung: Der Befehl show ip ospf stellt den korrekten Status dar.

Problem 1647739: Durch die erneute Bereitstellung einer Edge-VM nach einem vMotion-Vorgang wird das Edge oder die DLR-VM wieder im ursprünglichen Cluster platziert

Problemumgehung: Um die Edge-VM in einem anderen Ressourcenpool oder in einem anderen Cluster zu platzieren, konfigurieren Sie mithilfe der NSX Manager-Benutzeroberfläche den gewünschten Speicherort.

Problem 1463856: Wenn die NSX Edge-Firewall aktiviert ist, werden vorhandene TCP-Verbindungen blockiert
TCP-Verbindungen werden über die statusorientierte Edge-Firewall blockiert, wenn der anfängliche Drei-Wege-Handshake nicht erkannt wird.

Problemumgehung: Gehen Sie wie folgt vor, um solche vorhandenen Flows zu steuern. Aktivieren Sie das Flag „tcpPickOngoingConnections“ in der globalen Firewall-Konfiguration mithilfe der NSX-REST-API. Dies schaltet die Firewall vom strikten Modus in den toleranten Modus um. Aktivieren Sie dann die Firewall. Nachdem die vorhandenen Verbindungen hergestellt wurden (möglicherweise erst einige Minuten nach der Aktivierung der Firewall), können Sie das Flag „tcpPickOngoingConnections“ wieder deaktivieren, um die Firewall zurück in den strikten Modus zu versetzen. (Diese Einstellung ist dauerhaft.)

PUT /api/4.0/edges/{edgeId}/firewall/config/global

<globalConfig>
<tcpPickOngoingConnections>true</tcpPickOngoingConnections>
</globalConfig>

Problem 1374523: Erforderlicher Neustart von ESXi oder erforderliche Ausführung von [services.sh restart] nach der Installation von VXLAN VIB, um die VXLAN-Befehle mit esxcli verfügbar zu machen

Nach der Installation von VXLAN VIB müssen Sie ESXi neu starten oder den Befehl [services.sh restart] ausführen, damit die VXLAN-Befehle mit esxcli verfügbar sind.

Problemumgehung: Verwenden Sie anstelle von esxcli den Befehl localcli.

Problem 1604514: Die Bearbeitung und Konfiguration des Standard-Gateway auf einem nicht verwalteten DLR scheitert nach dem Klicken auf „Veröffentlichen“

Wenn ein Standard-Gateway einem nicht verwalteten DLR hinzugefügt wird, scheitert die Veröffentlichung mit der Fehlermeldung „Routing Distance wird nur von NSX Edge Version 6.2.0 und später mit bereitgestellten NSX Edge-VMs unterstützt“. Die Ursache dafür ist der Standardwert „1“ für Admin Distance in der Benutzeroberfläche.

Problemumgehung: Entfernen Sie den Wert „1“ für Admin Distance, der standardmäßig eingestellt ist.

Problem 1642087: Nach der Änderung des Parameters securelocaltrafficbyip in der IPSec-VPN-Erweiterung scheitert die Weiterleitung zum Zielnetzwerk

Bei der Verwendung eines NSX Edge Services Gateway tritt folgendes Problem auf:

  • Nach der Änderung des Wertes securelocaltrafficbyip in der NSX-Benutzeroberfläche (Bildschirm „IPSec-VPN bearbeiten“) auf 0 funktioniert die Weiterleitung zu einem Remotesubnetz des IPSec-VPN-Tunnels nicht mehr
  • Nach der Änderung dieses Parameters werden die korrekten Informationen für ein Remotesubnetz nicht mehr in der IP-Routing-Tabelle angezeigt

Problemumgehung: Deaktivieren Sie den IPSec-VPN-Dienst und aktivieren Sie ihn dann erneut. Anschließend prüfen Sie, ob die erwarteten Routing-Informationen in der Befehlszeilenschnittstelle (CLI) und in der Benutzeroberfläche angezeigt werden.

Problem 1525003: Die Wiederherstellung einer NSX Manager-Sicherung mit einer fehlerhaften Passphrase scheitert ohne Rückmeldung, da auf zentrale Stammordner nicht zugegriffen werden kann

Problemumgehung: Keine.

Problem 1637639: Wenn der Windows 8 SSL VPN PHAT-Client verwendet wird, wird die virtuelle IP vom IP-Pool nicht zugewiesen
Unter Windows 8 wird die virtuelle IP-Adresse nicht wie vorgesehen vom IP-Pool zugewiesen, wenn eine neue IP-Adresse vom Edge Services Gateway zugewiesen wurde oder wenn sich der IP-Pool ändert und einen anderen IP-Bereich verwendet.

Problemumgehung: Dieses Problem tritt nur unter Windows 8 auf. Um dieses Problems zu vermeiden, verwenden Sie ein anderes Windows-Betriebssystem.

Problem 1628220: DFW- oder NetX-Beobachtungen werden auf der Empfängerseite nicht angezeigt
Traceflow zeigt eventuell keine DFW- und NetX-Beobachtungen auf der Empfängerseite an, wenn der mit der Ziel-vNIC verbundene Switchport geändert wird. Dieses Problem wird für vSphere 5.5-Versionen nicht behoben. Bei vSphere 6.0 und höher tritt dieses Problem nicht auf.

Problemumgehung: vNIC muss aktiviert bleiben. Starten Sie die VM neu.

Problem 1534603: Der Dienststatus für IPSec und L2 VPN wird als ausgeschaltet angezeigt, auch wenn der Dienst nicht aktiviert ist
In der Registerkarte „Einstellungen“ der Benutzeroberfläche wird der L2-Dienststatus als nicht aktiviert angezeigt. Die API hingegen zeigt den L2-Status als aktiviert an. Der L2 VPN- und IPSec-Dienst wird in der Registerkarte „Einstellungen“ immer als ausgeschaltet angezeigt, bis die Seite der Benutzeroberfläche aktualisiert wird.

Problemumgehung: Aktualisieren Sie die Seite.

Problem 1534799: Langsame Konvergenz beim Herunterfahren des OSPF Area Border Router mit der höchsten IP-Adresse
Die Konvergenz dauert sehr lang, wenn der NSX-basierte OSPF Area Border Router (ABR) mit der höchsten IP-Adresse heruntergefahren oder neu gestartet wird. Wenn ein ABR, der nicht über die numerisch höchste IP-Adresse verfügt, heruntergefahren oder neu gestartet wird, konvergiert der Datenverkehr schnell auf einen anderen Pfad. Wird jedoch der ABR mit der höchsten IP-Adresse heruntergefahren oder neu gestartet, so nimmt die erneute Konvergenz einen Zeitraum von mehreren Minuten in Anspruch. Der OSPF-Vorgang kann manuell bereinigt werden, um die Konvergenzzeit zu verringern.

Problem 1446327: Einige TCP-basierten Anwendungen überschreiten möglicherweise den zulässigen Zeitraum, wenn sie eine Verbindung über NSX Edge herstellen
Der Zeitüberschreitungswert für die Inaktivität bei hergestellten TCP-Verbindungen beträgt standardmäßig 3.600 Sekunden. NSX Edge löscht jede Verbindung, die länger im Leerlauf ist, als es der Zeitüberschreitungswert für eine Inaktivität erlaubt, und trennt diese Verbindungen.

Problemumgehung:
  1. Wenn sich die Anwendung eine relativ lange Zeit im Leerlauf befindet, aktivieren Sie die TCP-„KeepAlives“ auf dem Host mit einem „KeepAlive“-Intervall mit weniger als 3.600 Sekunden.
  2. Erhöhen Sie den Edge TCP-Zeitüberschreitungswert für die Inaktivität mithilfe der folgenden NSX-REST-API auf über zwei Stunden. So können Sie den Zeitüberschreitungswert zum Beispiel auf 9.000 Sekunden erhöhen. NSX-API-URL:
    /api/4.0/edges/{edgeId}/systemcontrol/config PUT Method <systemControl> <property>sysctl.net.netfilter.nf_conntrack_tcp_timeout_established=9000</property> </systemControl>

Problem 1089745: OSPF kann nur für einen DLR Edge-Uplink konfiguriert werden
Es ist aktuell nicht möglich, OSPF für mehr als einen der DLR Edge-Uplinks zu konfigurieren. Diese Beschränkung ist die Folge davon, dass sich die DLR-Instanzen eine einzige Weiterleitungsadresse teilen.

Problemumgehung: Es handelt sich hier um eine aktuelle Systembeschränkung, für die keine Problemumgehung verfügbar ist.

Problem 1498965: Edge-Syslog-Meldungen erreichen den Remote-Syslog-Server nicht
Unmittelbar nach der Bereitstellung kann der Edge-Syslog-Server die Hostnamen für alle konfigurierten Remote-Syslog-Server nicht auflösen.

Problemumgehung: Konfigurieren Sie Remote-Syslog-Server unter Verwendung der entsprechenden IP-Adressen oder verwenden Sie die Benutzeroberfläche, um die Edge-Synchronisierung zu erzwingen.

Problem 1494025: Die Einstellungen für die Konfiguration des DNS-Clients für logische Router werden nach dem Update der REST-Edge-API nicht vollständig angewendet

Problemumgehung: Wenn Sie die REST-API zum Konfigurieren der DNS-Weiterleitung (Auflöser) verwenden, führen Sie die folgenden Schritte durch:

  1. Geben Sie die Einstellungen für den DNS Client XML-Server so an, dass diese der Einstellung der DNS-Weiterleitung entsprechen.

  2. Aktivieren Sie die DNS-Weiterleitung und stellen Sie sicher, dass die Einstellungen für die Weiterleitung den Einstellungen für den DNS-Client-Server entsprechen, die in der XML-Konfiguration angegeben sind.

Problem 1243112: Validierung und Fehlernachricht für ungültigen nächsten Hop in statischer Route nicht vorhanden, ECMP-aktiviert
Beim Versuch, eine statische Route hinzuzufügen, wenn ECMP aktiviert ist, wird keine Fehlermeldung angezeigt und die statische Route nicht installiert, wenn die Routing-Tabelle keine Standardroute enthält und es einen nicht erreichbaren nächsten Hop in der Konfiguration der statischen Route gibt.

Problemumgehung: Keine.

Problem 1288487: Wenn eine NSX Edge-VM mit einer Teilschnittstelle, die durch einen logischen Switch gesichert ist, über die Benutzeroberfläche von vCenter Web Client gelöscht wird, funktioniert der Datenpfad eventuell nicht für eine neue virtuelle Maschine, die mit demselben Port verbunden ist
Wenn die Edge-VM über die Benutzeroberfläche von vCenter Web Client (und nicht über NSX Manager) gelöscht wird, wird der auf dvPort über einem opaken Kanal konfigurierte VXLAN-Trunk nicht zurückgesetzt. Die Trunk-Konfiguration wird nämlich von NSX Manager verwaltet.

Problemumgehung: Löschen Sie die VXLAN-Trunk-Konfiguration wie folgt manuell:

  1. Wechseln Sie zum vCenter-MOB (Managed Object Browser), indem Sie Folgendes in einem Browserfenster eingeben:
    https://<vc-ip>/mob?vmodl=1
  2. Klicken Sie auf Inhalt.
  3. Rufen Sie den dvsUuid-Wert wie folgt ab:
    1. Klicken Sie auf den Root-Ordner-Link (zum Beispiel „group-d1(Datacenters)“).
    2. Klicken Sie auf den Datencenternamen-Link (zum Beispiel „datacenter-1“).
    3. Klicken Sie auf den networkFolder-Link (zum Beispiel group-n6).
    4. Klicken Sie auf den DVS-Namen-Link (zum Beispiel „dvs-1“).
    5. Kopieren Sie den Wert von uuid.
  4. Klicken Sie auf DVSManager und dann auf updateOpaqueDataEx.
  5. Fügen Sie in selectionSet folgendes XML-Segment hinzu.
    <selectionSet xsi:type="DVPortSelection">
      <dvsUuid>value</dvsUuid>
      <portKey>value</portKey> <!--port number of the DVPG where trunk vnic got connected-->
    </selectionSet>
  6. Fügen Sie in opaqueDataSpec folgendes XML-Segment hinzu:
    <opaqueDataSpec>
      <operation>remove</operation>
      <opaqueData>
        <key>com.vmware.net.vxlan.trunkcfg</key>
        <opaqueData></opaqueData>
      </opaqueData>
    </opaqueDataSpec>
  7. Setzen Sie isRuntime auf "false".
  8. Klicken Sie auf Methode aufrufen.
  9. Wiederholen Sie die Schritte 5 bis 8 für jeden Trunk-Port, der auf der gelöschten Edge-VM konfiguriert wurde.

Problem 1637939: MD5-Zertifikate werden für die Bereitstellung von Hardware-Gateways nicht unterstützt
Beim Bereitstellen von Hardware-Gateway-Switches als VTEPs für ein logisches Bridging von L2 VLAN zu VXLAN unterstützen die physischen Switches mindestens SHA1 SSL-Zertifikate für eine OVSDB-Verbindung zwischen dem NSX Controller und dem OVSDB-Switch.

Problemumgehung: Keine.

Problem 1637943: Der Hybrid- oder Multicast-Replikationsmodus wird für VNIs, die über eine Hardware-Gateway-Bindung verfügen, nicht unterstützt.
Hardware-Gateway-Switches unterstützen, wenn sie als VTEPs für das L2 VXLAN-zu-VLAN Bridging verwendet werden, nur den Unicast-Replikationsmodus.

Problemumgehung: Verwenden Sie nur den Unicast-Replikationsmodus.

Bekannte Probleme bei Sicherheitsdiensten

Neues Problem 1854661: In einem Cross-VC-Setup zeigen die gefilterten Firewallregeln nicht den Indexwert beim Wechsel zwischen NSX Managern an
Nach der Anwendung von Kriterien einer Filterregel auf einen NSX Manager und dem Wechsel zu einem anderen NSX Manager zeigt der Index der Regel für alle gefilterten Regeln „0“ statt der tatsächlichen Position der Regel an.

Problemumgehung: Löschen Sie den Filter, um die Position der Regel anzuzeigen.

Neues Problem 1881696: Wenn eine Richtlinie mit einigen damit verknüpften Firewallaktionen erstellt und die Richtlinie später zum Löschen aller Aktionen bearbeitet wird, zeigt die Richtlinie fälschlicherweise den Status „Vorgang läuft“ an, wenn NSX Manager neu gestartet wird
Wenn Sie eine Richtlinie mit Aktionen einer Kategorie erstellen und dann später die Richtlinie durch Löschen der Aktionen bearbeiten, zeigt die Richtlinie fälschlicherweise den Status „Vorgang läuft“ an, wenn NSX Manager neu gestartet wird.

Problemumgehung: Dieses Problem hat keine funktionalen Auswirkungen. Wenn jedoch die Benutzeroberfläche nur noch langsam reagiert, löschen Sie die Richtlinie und erstellen Sie diese neu.

Neues Problem 1859531: Für bestimmte Systemereignisse des Application Rule Manager werden keine SNMP-Traps gesendet
Für die folgenden Systemereignisse des Application Rule Manager werden keine SNMP-Traps gesendet:

  • Flow-Analyse gestartet
  • Flow-Analyse fehlgeschlagen
  • Flow-Analyse abgeschlossen

Diese Systemereignisse werden auf der Registerkarte für die Überwachung der NSX-Manager-Systemereignisse angezeigt.

Problemumgehung: Es ist keine Umgehung erforderlich. Die Analyse wird wie gewohnt fortgesetzt, es werden aber keine SNMP-Traps zur Kennzeichnung dieser Ereignisse generiert.

Neues Problem 1846402: Mehrere IP-Adressen auf einer vNIC verzögern die Veröffentlichung der Firewall
Das Problem tritt auf, wenn eine vNIC über mehrere IP-Adressen verfügt und ARP-Snooping aktiviert ist. Jedes Paket, dass die vNIC verlässt, führt dann möglicherweise zu einer ARP-Meldung vom Host zum Manager mit der neu ermittelten IP-Adresse. Dies liegt daran, dass der Host nur eine durch ARP-Snooping ermittelte IP-Adresse zum Manager senden kann. Wenn die vNIC die IP-Adresse wechselt, behandelt der Host die IP-Adresse als neu und sendet die ARP-Snooping-Meldung zum Manager. Dies führt in der Regel zu einer Änderung der Containermeldungen auf dem NSX Manager und zu Verzögerungen in der Umsetzung der Firewallkonfiguration auf dem Host.

Problemumgehung: Deaktivieren Sie das ARP-Snooping, wenn vNICs über mehrere IP-Adressen verfügen. Verwenden Sie stattdessen das DHCP-Snooping oder VMware Tools.

Problem 1474650: NetX-Benutzer sehen bei ESXi 5.5.x- und 6.x-Hosts einen violetten Diagnosebildschirm mit der Meldung ALERT: NMI: 709: NMI IPI received
Wenn eine große Anzahl von Paketen von einer Dienst-VM übertragen oder empfangen wird, dominiert DVFilter weiterhin die CPU, was Taktsignalverlust und einen violetten Diagnosebildschirm zur Folge hat. Weitere Informationen dazu enthält der VMware-Knowledgebase-Artikel 2149704.

Problemumgehung: Upgrade des ESXi-Hosts auf eine der folgenden Mindestversionen von ESXi, die für die Verwendung von NetX erforderlich sind:

  • 5.5 Patch 10
  • ESXi 6.0U3
  • ESXi 6.5

Problem 1676043: VM wird aus der Ausschlussliste entfernt, wenn sie zweimal gleichzeitig hinzugefügt wird
Wird einer Ausschlussliste eine bestimmte VM von zwei Benutzern gleichzeitig hinzugefügt, ohne dass die Benutzeroberfläche aktualisiert wird, werden die bereits hinzugefügten VMs aus der Ausschlussliste entfernt.

Problemumgehung: Aktualisieren Sie die Benutzeroberfläche, bevor Sie die virtuelle Maschine der Ausschlussliste hinzufügen.

Problem 1770259: Im Feld appliedTo der DFW-Regel können nicht mehrere appliedTo-Objekte angegeben werden
Wenn Sie die DFW-Regel auf einen Satz von vNICs oder VMs oder auf Cluster oder Datencenter anwenden, diese veröffentlichen und dann später durch Hinzufügen zusätzlicher Objekte zum Feld appliedTo verändern möchten, werden die Änderungen nicht wirksam, auch wenn die Veröffentlichung durchgeführt werden kann.

Problemumgehung: Keine.

Problem 1798779: Nach dem Upgrade von NSX von 6.2.x auf 6.3.0 ermöglicht die Benutzeroberfläche des vSphere Web Client irrtümlicherweise das Hinzufügen eines globalen Sicherheits-Tags
In NSX 6.3.0 wurden globale Sicherheits-Tags eingeführt. Wenn Sie versuchen einer globalen Sicherheitsgruppe, die mit der Version 6.2.x vor dem Upgrade auf NSX 6.3.0 erstellt wurde, ein solches globales Sicherheits-Tag hinzuzufügen, scheitert dieser Vorgang mit der Fehlermeldung „Das angeforderte Mitglied ist kein gültiges Mitglied“. Diese Meldung ist korrekt und weist darauf hin, dass es nicht möglich ist, einer globalen NSX 6.2.x-Sicherheitsgruppe ein globales Sicherheits-Tag hinzuzufügen. Die Benutzeroberfläche ist hier irreführend.

Problemumgehung: Erstellen Sie nach dem Upgrade eine globale NSX 6.3.0-Sicherheitsgruppe und fügen Sie dieser die globalen Sicherheits-Tags hinzu.

Problem 1799543: Nach dem Upgrade von NSX 6.2.x auf NSX 6.3.0 zeigt der vSphere Web Client irrtümlicherweise globale NSX 6.2.x-Sicherheitsgruppen sowie globale Nicht-Aktiv/Standby-Sicherheitsgruppen an und ermöglicht deren Auswahl, wenn Sie die erste globale Aktiv/Standby-Sicherheitsgruppe erstellen
Wenn Sie die allererste globale Aktiv/Standby-Sicherheitsgruppe erstellen, wird in der Benutzeroberfläche des vSphere Web Client eine globale Sicherheitsgruppe angezeigt, die mit NSX 6.2.x erstellt wurde, und die auch hinzugefügt werden kann. Dieser Vorgang scheitert mit der Fehlermeldung „Das angeforderte Mitglied ist kein gültiges Mitglied“.

Problemumgehung: Erstellen Sie mindestens eine globale Aktiv/Standby-Sicherheitsgruppe. Das Problem wird nicht mehr auftreten, wenn Sie die nächste globale Aktiv/Standby-Sicherheitsgruppe anlegen.

Problem 1786780: Das Neuanordnen und Verschieben von Richtlinien mit der Benutzeroberfläche von Service Composer dauert sehr lange, und die CPU-Auslastung ist hoch
Wenn Sie mit der Benutzeroberfläche von Service Composer Richtlinien neu anordnen oder neu positionieren, kann dies eine sehr lange Zeit in Anspruch nehmen, und die CPU-Auslastung ist hoch.

Problemumgehung: Führen Sie zur Lösung des Problems die folgenden Schritte durch:

  • Geben Sie der Richtlinie bei der Erstellung die passende Priorität (Gewichtung), damit diese schon im ersten Versuch an der richtigen Stelle platziert wird, sodass Sie die Richtlinien dann nicht mehr erneut anordnen müssen.
  • Wenn Sie eine Richtlinie an eine andere Position verschieben müssen, bearbeiten Sie die betreffende Richtlinie und ändern Sie die Priorität (Gewichtung) in einen geeigneten Wert. So wird eine einzelne Richtlinie geändert und die Rangfolge schnell angepasst.

Problem 1787680: Globaler Firewallabschnitt kann nicht gelöscht werden, wenn sich NSX Manager im Transitmodus befindet
Wenn Sie versuchen, einen globalen Firewallabschnitt über die Benutzeroberfläche von NSX Manager im Transitmodus zu löschen und dann eine Veröffentlichung durchzuführen, schlägt dies fehl. Sie sind dann nicht mehr in der Lage, NSX Manager in den eigenständigen Modus zu versetzen.

Problemumgehung: Löschen Sie den globalen Firewallabschnitt mit der REST-API zum Löschen eines einzelnen Abschnitts.

Problem 1741844: Die Adressermittlung einer vNIC mit mehreren IP-Adressen mithilfe von ARP-Snooping führt zu einer CPU-Auslastung von 100 %.
Dieses Problem tritt auf, wenn die vNIC einer virtuellen Maschine mit mehreren IP-Adressen konfiguriert wurde und ARP-Snooping für die IP-Erkennung aktiviert wurde. Das Modul für die IP-Erkennung sendet weiter ständig vNIC-IP-Aktualisierungen an den NSX Manager, um die vNIC-IP-Zuordnung für alle VMs zu ändern, die mit mehreren IP-Adressen konfiguriert wurden.

Problemumgehung: Für dieses Problem gibt es keine Umgehung. Zurzeit unterstützt die Funktion für das ARP-Snooping nur eine IP-Adresse pro vNIC. Weitere Informationen finden Sie im Abschnitt IP-Erkennung für virtuelle Maschinen im Administratorhandbuch für NSX.

Problem 1689159: Die Funktion „Regel hinzufügen“ im Flow Monitoring funktioniert nicht korrekt für ICMP-Flows
Beim Hinzufügen einer Regel über das Flow Monitoring bleibt das Feld „Dienste“ leer, wenn es nicht explizit auf „ICMP“ festgelegt wird. Infolgedessen wird gegebenenfalls eine Regel mit dem Diensttyp „ANY“ hinzugefügt.

Problemumgehung: Aktualisieren Sie das Feld „Dienste“, um den ICMP-Datenverkehr widerzuspiegeln.

Problem 1632235: Währen der Guest Introspection-Installation wird in der Netzwerk-Dropdown-Liste nur der Eintrag „Angegeben auf dem Host“ angezeigt
Bei der Installation von Guest Introspection mit der NSX-Lizenz nur für den Virenschutz und vSphere Essential oder mit der Standardlizenz enthält die Netzwerk-Dropdown-Liste nur die vorhandene Liste der DV-Portgruppen. Diese Lizenz unterstützt nicht die DVS-Erstellung.

Problemumgehung: Vor der Installation von Guest Introspection auf einem vSphere-Host mit einer dieser Lizenzen geben Sie zuerst das Netzwerk im Fenster „Agent-VM-Einstellungen“ an.

Problem 1652155: Das Erstellen oder Migrieren von Firewallregeln mithilfe von REST-APIs kann unter bestimmten Bedingungen nicht durchgeführt werden und ergibt dann einen HTTP 404-Fehler

Das Hinzufügen oder Migrieren von Firewallregeln mithilfe von REST-APIs wird unter folgenden Bedingungen nicht unterstützt:

  • Massenerstellung von Firewallregeln, wenn „autoSaveDraft=true“ festgelegt ist.
  • Gleichzeitiges Hinzufügen von Firewallregeln in mehreren Abschnitten.

Problemumgehung: Legen Sie für den Parameter autoSaveDraft im API-Aufruf „false“ fest, wenn Firewallregeln als Massenvorgang erstellt oder migriert werden.

Problem 1509687: Für die URL-Länge werden beim Zuweisen eines einzelnen Sicherheits-Tag zu vielen VMs in einem API-Aufruf gleichzeitig bis zu 16000 Zeichen unterstützt
Ein einzelnes Sicherheits-Tag kann in einem API-Aufruf nicht einer großen Anzahl an VMs gleichzeitig zugewiesen werden, wenn die URL-Länge 16000 Zeichen übersteigt.

Problemumgehung: Zur Optimierung der Leistung weisen Sie ein Tag in einem einzelnen Aufruf nur maximal 500 VMs zu.

Problem 1662020: Eine Veröffentlichung scheitert mit der Fehlermeldung „Die letzte Veröffentlichung ist auf Host Hostnummer fehlgeschlagen“ in den Abschnitten „Allgemein“ und „Partnersicherheitsdienste“ der DFW-Benutzeroberfläche

Nach der Änderung einer Regel wird in der Benutzeroberfläche die Meldung „Die letzte Veröffentlichung ist auf Host Hostnummerfehlgeschlagen“ angezeigt. Die in der Benutzeroberfläche aufgeführten Hosts verfügen eventuell nicht über die korrekte Version der Firewallregeln, sodass es zu Sicherheitslücken und/oder zu einer Netzwerkunterbrechung kommt.

Das Problem tritt in der Regel in folgenden Fällen auf:

  • Nach dem Upgrade einer älteren auf die neueste NSX-Version.
  • Nach der Verschiebung eines Hosts aus einem Cluster und seine Verschiebung zurück in den Cluster.
  • Nach der Verschiebung eines Hosts von einem Cluster in einen anderen.

Problemumgehung: Zur Wiederherstellung müssen Sie eine Synchronisierung der betroffenen Cluster erzwingen (nur Firewall).

Problem 1481522: Die Migration von Firewallregelentwürfen von 6.1.x auf 6.2.3 wird nicht unterstützt, da die Entwürfe der beiden Versionen nicht kompatibel sind

Problemumgehung: Keine.

Problem 1628679: Bei Verwendung einer identitätsbasierten Firewall ist die VM von entfernten Benutzern weiterhin Teil der Sicherheitsgruppe

Wenn ein Benutzer aus einer Gruppe auf dem AD-Server entfernt wird, gehört die VM, für die der Benutzer angemeldet ist, weiterhin zur Sicherheitsgruppe. Dadurch werden die Firewallrichtlinien für die VM-vNIC auf dem Hypervisor beibehalten, sodass der Benutzer über einen kompletten Zugriff auf die Dienste verfügt.

Problemumgehung: Keine. Dieses Verhalten entspricht dem Programm-Design.

Problem 1462027: In übergreifenden vCenter NSX-Bereitstellungen werden mehrere Versionen von gespeicherten Firewallkonfigurationen auf sekundäre NSX Manager kopiert
Bei der globalen Synchronisierung werden mehrere Kopien von globalen Konfigurationen auf sekundären NSX Managern gespeichert. Die Liste der gespeicherten Konfigurationen enthält mehrere Entwürfe, die während der Synchronisierung für NSX Manager mit demselben Namen und derselben Zeit oder mit einer Zeitdifferenz von 1 Sekunde erstellt wurden.

Problemumgehung: Führen Sie den API-Aufruf aus, um doppelte Entwürfe zu löschen.

DELETE : https://<nsxmgr-ip>/api/4.0/firewall/config/drafts/

Suchen Sie die zu löschenden Entwürfe, indem Sie alle Entwürfe anzeigen:

GET: https://<nsxmgr-ip>/api/4.0/firewall/config/drafts

In der folgenden Beispielausgabe weisen die Entwürfe 143 und 144 denselben Namen auf und sie wurden zur selben Zeit erstellt. Sie stellen daher Duplikate dar. Ebenso weisen die Entwürfe 127 und 128 denselben Namen auf, jedoch mit einer Sekunde Zeitdifferenz. Sie stellen daher auch Duplikate dar.

<firewallDrafts>
    <firewallDraft id="144" name="AutoSaved_Wednesday, August 5, 2015 11:08:40 PM GMT" timestamp="1438816120917"> 
        <description>Auto saved configuration</description>
        <preserve>false</preserve>
        <user>replicator-1fd96022-db14-434d-811d-31912b1cb907</user>
        <mode>autosaved</mode>
    </firewallDraft>
    <firewallDraft id="143" name="AutoSaved_Wednesday, August 5, 2015 11:08:40 PM GMT" timestamp="1438816120713">
        <description>Auto saved configuration</description>
        <preserve>false</preserve>
        <user>replicator-1fd96022-db14-434d-811d-31912b1cb907</user>
        <mode>autosaved</mode>
    </firewallDraft>
   <firewallDraft id="128" name="AutoSaved_Wednesday, August 5, 2015 9:08:02 PM GMT" timestamp="1438808882608">
        <description>Auto saved configuration</description>
        <preserve>false</preserve>
        <user>replicator-1fd96022-db14-434d-811d-31912b1cb907</user>
        <mode>autosaved</mode>
    </firewallDraft>
    <firewallDraft id="127" name="AutoSaved_Wednesday, August 5, 2015 9:08:01 PM GMT" timestamp="1438808881750">
        <description>Auto saved configuration</description>
        <preserve>false</preserve>
        <user>replicator-1fd96022-db14-434d-811d-31912b1cb907</user>
        <mode>autosaved</mode>
    </firewallDraft>
</firewallDrafts>

Problem 1449611: Wenn eine Firewallrichtlinie im Service Composer aufgrund einer gelöschten Sicherheitsgruppe nicht synchronisiert ist, kann die Firewallregel nicht auf der Benutzeroberfläche korrigiert werden.

Problemumgehung: Auf der Benutzeroberfläche können Sie die ungültige Firewallregel löschen und sie anschließend erneut hinzufügen. Sie können auch in der API die Firewallregel korrigieren, indem Sie die ungültige Sicherheitsgruppe löschen. Synchronisieren Sie anschließend die Firewallkonfiguration: Wählen Sie Service Composer: Sicherheitsrichtlinien aus und klicken Sie für jede Sicherheitsrichtlinie mit verbundenen Firewallregeln auf Aktionen und wählen Sie Firewallkonfiguration synchronisieren aus. Um dieses Problem zu vermeiden, verändern Sie die Firewallregeln so, dass sie sich nicht auf Sicherheitsgruppen beziehen, bevor Sie die Sicherheitsgruppen löschen.

Problem 1557880: Es sind eventuell keine Schicht 2-Regeln (L2, Layer 2) vorhanden, wenn die MAC-Adresse einer virtuellen Maschine in den Regeln verändert wurde
Da die L2-Regeloptimierung standardmäßig AKTIVIERT ist, werden L2-Regeln, wenn Quell- und Zielfelder angegeben sind (keine Auswahl von „Beliebig“), nur für vNICs (oder Filter) angewendet, wenn die vNIC-MAC-Adresse mit der Quell- oder Ziel-MAC-Adressliste übereinstimmt. Für Hosts mit virtuellen Maschinen, die nicht den Quell- oder Ziel-MAC-Adressen entsprechen, werden diese L2-Regeln nicht angewendet.

Problemumgehung: Damit L2-Regeln auf alle vNICs (oder Filter) angewendet werden können, muss für die Quell- oder Zielfelder die Option „Beliebig“ ausgewählt werden.

Problem 1496273: Auf der Benutzeroberfläche können Sie NSX-Firewallregeln für beide Richtungen erstellen, die nicht auf Edges angewendet werden können
Fälschlicherweise lässt der Web Client das Erstellen einer NSX-Firewallregel zu, die auf einen oder mehrere NSX Edges angewendet wird, wenn die Regel über Datenverkehr verfügt, der in eine der beiden Richtungen gesendet wird, bzw. wenn es sich bei dem Pakettyp um IPV4 oder IPV6 handelt. Auf der Benutzeroberfläche sollte das Erstellen solcher Regeln nicht zulässig sein, da NSX diese nicht auf NSX Edges anwenden kann.

Problemumgehung: Keine.

Problem 1557924: Der globale logische Switch ist für die Verwendung im Feld „AppliedTo“ einer lokalen DFW-Regel zulässig
Wenn ein globaler logischer Switch als Mitglied einer Sicherheitsgruppe benutzt wird, kann die DFW-Regel diese Sicherheitsgruppe im Feld „AppliedTo“ verwenden. Dadurch wird indirekt die Regel auf den globalen logischen Switch angewendet. Dies sollte nicht erlaubt sein, da es zu einem nicht vorhersehbaren Verhalten dieser Regeln führen kann.

Problemumgehung: Keine.

Problem 1559971: Eine Firewall-Ausschlussliste von Cross-vCenter NSX wird nicht veröffentlicht, wenn die Firewall auf einem Cluster deaktiviert wurde
In Cross-vCenter NSX wird für alle Cluster keine Firewall-Ausschlussliste veröffentlicht, wenn die Firewall auf einem Cluster deaktiviert wurde.

Problemumgehung: Führen Sie eine Synchronisierung der betroffenen NSX-Edges durch.

Problem 1407920: Nach der Verwendung von DELETE API schlägt das erneute Veröffentlichen einer Firewallregel fehl
Wenn Sie die gesamte Firewallkonfiguration mithilfe der Methode DELETE API löschen und dann versuchen, alle Regeln erneut anhand eines zuvor gespeicherten Entwurfs der Firewallregeln zu veröffentlichen, schlägt die Regelveröffentlichung fehl.

Problem 1494718: Es können keine neuen universellen Regeln erstellt werden und vorhandene universelle Regeln können nicht über die Benutzeroberfläche von Flow Monitoring bearbeitet werden

Problemumgehung: Globale Regeln können nicht über die Flow Monitoring-UI hinzugefügt oder bearbeitet werden. EditRule wird automatisch deaktiviert.

Problem 1442379: Firewallkonfiguration für Service Composer nicht synchronisiert
Wenn in NSX Service Composer eine Firewallrichtlinie ungültig ist (z. B. wenn Sie eine Sicherheitsgruppe gelöscht haben, die aktuell in einer Firewallregel verwendet wurde), wird durch das Löschen oder Ändern einer anderen Firewallrichtlinie bewirkt, dass Service Composer nicht mehr synchronisiert ist. Es wird die Fehlermeldung Firewallkonfiguration nicht synchronisiert angezeigt.

Problemumgehung: Löschen Sie ungültige Firewallregeln und synchronisieren Sie anschließend die Firewallkonfiguration. Wählen Sie Service Composer: Sicherheitsrichtlinien aus und klicken Sie für jede Sicherheitsrichtlinie mit verbundenen Firewallregeln auf Aktionen und wählen Sie Firewallkonfiguration synchronisieren aus. Um dieses Problem zu vermeiden, korrigieren oder löschen Sie immer ungültige Firewallkonfigurationen, bevor Sie weitere Änderungen an der Firewallkonfiguration vornehmen.

Problem 1066277: Name der Sicherheitsrichtlinie darf nicht länger als 229 Zeichen sein
In das Feld für den Namen der Sicherheitsrichtlinie auf der Registerkarte „Sicherheitsrichtlinie“ von Service Composer können bis zu 229 Zeichen eingegeben werden. Grund hierfür ist, dass den Richtliniennamen intern ein Präfix vorangestellt wird.

Problemumgehung: Keine.

Problem 1443344: Einige Versionen der Networks-VM-Serien von Drittanbietern funktionieren nicht mit den Standardeinstellungen von NSX Manager
Einige Komponenten von NSX 6.1.4 oder später deaktivieren SSLv3 standardmäßig. Stellen Sie vor dem Upgrade sicher, dass keine der in Ihre NSX-Bereitstellung eingebundenen Drittanbieterlösungen von der SSLv3-Kommunikation abhängt. Zum Beispiel erfordern einige Versionen der Lösung der Palo Alto Networks VM-Serie Unterstützung für SSLv3. Bitten Sie deshalb Ihre Anbieter um die entsprechenden Versionsanforderungen.

Problem 1660718: Für den Status der Service Composer-Richtlinie wird in der Benutzeroberfläche „Vorgang läuft“ und in der API-Ausgabe „Ausstehend“ angezeigt

Problemumgehung: Keine.

Problem 1620491: Der Synchronisierungsstatus auf Richtlinienebene in Service Composer zeigt nicht den Veröffentlichungsstatus der Regeln einer Richtlinie an

Wenn eine Richtlinie erstellt oder geändert wird, zeigt Service Composer den Status „Erfolg“ an, der sich aber nur auf den Persistenzstatus bezieht. Dieser Status sagt nichts darüber aus, ob die Regeln auf dem Host erfolgreich bereitgestellt wurden.

Problemumgehung: Verwenden Sie die Firewall-Benutzeroberfläche zur Anzeige des Veröffentlichungsstatus.

Problem 1317814: Die Synchronisierung von Service Composer geht verloren, wenn Richtlinienänderungen durchgeführt werden, während einer der Service Manager ausgefallen ist
Werden Richtlinienänderungen durchgeführt, wenn einer von mehreren Dienst-Managern inaktiv ist, können diese Änderungen nicht durchgeführt werden und Service Composer ist nicht mehr synchronisiert.

Problemumgehung: Stellen Sie sicher, dass der Dienst-Manager reagiert und erzwingen Sie eine Synchronisierung über den Service Composer.

Problem 1070905: Entfernen und erneutes Hinzufügen eines Hosts zu einem Cluster, der durch Guest Introspection und Lösungen von Drittanbietern geschützt wird, ist nicht möglich
Wenn Sie einen Host aus einem durch Guest Introspection und Lösungen von Drittanbietern geschützten Cluster entfernen, indem Sie die Verbindung des Hosts zu vCenter Server trennen und ihn anschließend aus diesem entfernen, treten möglicherweise Probleme auf, wenn Sie versuchen, denselben Host erneut demselben Cluster hinzuzufügen.

Problemumgehung: Um einen Host aus einem geschützten Cluster zu entfernen, versetzen Sie den Host zunächst in den Wartungsmodus. Verschieben Sie den Host im nächsten Schritt in einen nicht geschützten Cluster oder außerhalb aller Cluster. Trennen Sie dann die Verbindung und entfernen Sie den Host.

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 1772504: Service Composer unterstützt keine Sicherheitsgruppen mit MAC Set
Service Composer erlaubt die Verwendung von Sicherheitsgruppen in Richtlinienkonfigurationen. Für den Fall, dass eine Sicherheitsgruppe einen MAC Set enthält, akzeptiert Service Composer die entsprechende Sicherheitsgruppe ohne Warnung, es können jedoch keine Regeln für den entsprechenden MAC Set erzwungen werden. Dies ist darauf zurückzuführen, dass Service Composer auf Layer3 arbeitet und keine Layer2-Konstrukte unterstützt. Beachten Sie, dass falls eine Sicherheitsgruppe sowohl einen IP Set als auch einen MAC Set enthält, der IP Set nach wie vor wirksam ist, wohingegen der MAC Set ignoriert wird. Es kann nicht schaden, eine Sicherheitsgruppe, die einen MAC Set enthält, zu referenzieren – der Benutzer muss sich bewusst sein, dass der MAC Set ignoriert wird.

Problemumgehung: Falls der Benutzer beabsichtigt, Firewallregeln mithilfe eines MAC Sets zu erstellen, sollte er die DFW-Layer2-/Ethernetkonfiguration anstelle von Service Composer verwenden.

Problem 1718726: Synchronisation des Service Composers kann nicht erzwungen werden, wenn ein Benutzer den Abschnitt „Service Composer-Richtlinie“ mithilfe von DFW REST API manuell gelöscht hat

In einer cross-vCenter NSX-Umgebung wird jeder Versuch eines Benutzers, die Synchronisation der NSX Service Composer-Konfiguration zu erzwingen, fehlschlagen, wenn es nur einen Richtlinienabschnitt gab und dieser Richtlinienabschnitt (der über den Service Composer verwaltete Richtlinienabschnitt) zu einem früheren Zeitpunkt mit einem REST API-Aufruf gelöscht wurde.

Problemumgehung: Löschen Sie den über den Service Composer verwalteten Richtlinienabschnitt nicht mit einem REST API-Aufruf. (Bitte beachten Sie, dass bereits die UI das Löschen dieses Abschnittes verhindert.)

Bekannte Probleme bei Überwachungsdiensten

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.

Problem 1626233: Wenn die NetX-Dienst-VM (SVM) Pakete verwirft, generiert Traceflow keine entsprechende Beobachtung

Die Traceflow-Sitzung wird nach dem Senden des Pakets an die NetX-Dienst-VM (SVM) beendet. Wenn die SVM Pakete verwirft, generiert Traceflow keine entsprechende Beobachtung.

Problemumgehung: Für dieses Problem gibt es keine Umgehung. Wird das Traceflow-Paket nicht wieder eingefügt, ist davon auszugehen, dass die SVM das Paket verworfen hat.

Bekannte Probleme bei der Lösungsinteroperabilität

Problem 1568861: Die NSX Edge-Bereitstellung scheitert im Zuge jeder Edge-Bereitstellung von einer vCloud Director-Zelle aus, zu welcher der vCenter-Listener nicht gehört.

Die NSX Edge-Bereitstellung scheitert im Zuge jeder Edge-Bereitstellung von einer vCloud Director-Zelle aus, zu welcher der vCenter-Listener nicht gehört. Darüber hinaus scheitern alle NSX Edge-Aktionen vom vCloud Director, inklusive einer erneuten Bereitstellung.

Problemumgehung: Stellen Sie ein NSX Edge von der vCloud Director-Zelle aus bereit, zu welcher der vCenter-Listener gehört.

Bekannte Probleme von NSX Controller

Problem 1765354: <deployType> ist eine erforderliche Eigenschaft, wird aber nicht verwendet
<deployType> ist eine erforderliche Eigenschaft, wird aber nicht verwendet und hat keine Bedeutung.

Problem 1516207: Controller werden eventuell isoliert, wenn die IPsec-Kommunikation für NSX Controller-Cluster erneut aktiviert wird
Wenn für einen NSX-Controller-Cluster die unverschlüsselte Controller-zu-Controller-Kommunikation zulässig ist (IPSec ist deaktiviert) und die IPSec-basierte Kommunikation später erneut aktiviert wird, kann es vorkommen, dass ein oder mehrere Controller aufgrund eines nicht übereinstimmenden, zuvor vereinbarten Schlüssels (Pre-Shared Key, PSK) von einem Großteil des Clusters isoliert werden. In diesem Fall ist es der NSX API eventuell nicht mehr möglich, die IPSec-Einstellungen der Controller zu ändern.

Problemumgehung:

Führen Sie zur Behebung dieses Problems folgende Schritte durch:

  1. Deaktivieren Sie IPSec mithilfe der NSX API.

    PUT /2.0/vdn/controller/node

    <controllerNodeConfig>
      <ipSecEnabled>false</ipSecEnabled>
    </controllerNodeConfig>

  2. Aktivieren Sie IPSec mithilfe der NSX API erneut.

    PUT /2.0/vdn/controller/node

    <controllerNodeConfig>
      <ipSecEnabled>true</ipSecEnabled>
    </controllerNodeConfig>

Um dieses Problem zu vermeiden, beachten Sie die nachfolgenden Empfehlungen:

  • Verwenden Sie für die Deaktivierung von IPSec immer die NSX API. Die Verwendung der NSX Controller-CLI zur Deaktivierung von IPSec wird nicht unterstützt.
  • Stellen Sie immer sicher, dass alle Controller aktiv sind, bevor Sie mit der API die IPSec-Einstellung ändern.

Problem 1306408: NSX Controller-Protokolle müssen nacheinander heruntergeladen werden
NSX Controller-Protokolle können nicht alle gleichzeitig heruntergeladen werden. Selbst wenn der Download über mehrere Controller stattfindet, muss der Download über den aktuellen Controller abgeschlossen sein, bevor Sie den Download über den nächsten Controller starten. Beachten Sie, dass Sie den Download eines Protokolls nicht abbrechen können, nachdem er gestartet wurde.

Problemumgehung: Warten Sie, bis der Download über den aktuellen Controller abgeschlossen ist, bevor Sie den Download eines weiteren Protokolls starten.

Behobene Probleme

Erfahren Sie mehr zu behobenen Problemen in 6.3.2 oder in 6.3.1 und früher.

Neu behobene Probleme in NSX 6.3.2

Die behobenen Probleme in 6.3.2 gliedern sich wie folgt:

In NSX 6.3.2 behobene allgemeine Probleme

Behobenes Problem 1839275: VMs verlieren die Verbindung mit physischen Servern hinter den Hardware-VTEP-Switches
Wenn in Host-VMs sowohl die Datenebene als auch die Steuerungskomponente vorhanden ist und die Steuerungskomponente durch physische Trennung aller Netzwerkkabel inaktiv ist, verlieren die virtuellen Maschinen die Verbindung mit den physischen Servern, die sich hinter den Hardware-VTEP-Switches befinden. Problem in 6.3.2 behoben.

In NSX 6.3.2 behobene Probleme bei Installation und Upgrades

Behobenes Problem 1811218: VMKernel-Port von Nicht-NSX-vorbereiteten vSphere Distributed Switches (VDS) verliert nach einem Neustart des Hosts die Verbindung
Auf Hosts mit mehreren VDS verliert der VMKernel-Port von Nicht-NSX-vorbereiteten Distributed Switches nach dem Neustart des Hosts die Verbindung, wenn diese Switches über die gleiche dvPort-ID wie der VTEP-VMKernel-Port des NSX-vorbereiteten VDS verfügen. Weitere Informationen dazu enthält der VMware-Knowledgebase-Artikel 2149116. Problem in 6.3.2 behoben.

Behobenes Problem 1850690: Guest Introspection-USVM meldet volle Festplatte
In einer VMware NSX for vSphere 6.3.x-Umgebung mit bereitgestellter Guest Introspection erhalten Sie eine Warnung, dass für mindestens eine Guest Introspection-USVM der /var/log-Festplattenspeicher voll bzw. beinahe voll ist. Dieselbe Warnung wird in vRealize Operations Manager oder in jedem anderen Überwachungstool angezeigt, das den Festplattenspeicher der virtuellen Maschine nachverfolgt. Problem in 6.3.2 behoben.

Behobenes Problem 1854519: VMs verlieren die Nord-Süd-Verbindung nach der Migration von einem VLAN zu einem überbrückten VXLAN
Wenn das VM-Netzwerk von einem VLAN auf ein überbrücktes VXLAN auf dem DLR umgestellt wird, geht der eingehende Datenverkehr zur virtuellen Maschine verloren. Problem in 6.3.2 behoben.

In NSX 6.3.2 behobene NSX Manager-Probleme

Behobenes Problem 1814683: NSX Manager reagiert nicht mehr, wenn mehrere HTTP-Threads in einer Autorisierungsprüfung hängen bleiben
NSX Manager reagiert nicht mehr und muss neu gestartet werden. Problem in 6.3.2 behoben.

In NSX 6.3.2 behobene Netzwerk- und Edge-Dienste-Probleme

Behobenes Problem 1681063: Der VPN Tunnel-Status einiger Edge Gateways wird in vCloud Director nicht korrekt angegeben.
vCloud Director (vCD) und NSX zeigen unterschiedliche Statuszustände für IPSec VPN Tunnel an. vCD zeigt den IPSec Tunnel als ausgeschaltet an, obwohl er eingeschaltet ist und der Datenverkehr durchläuft. Problem in 6.3.2 behoben.

Behobenes Problem 1827643: Fluten des Unicast-Datenverkehrs beim Ereignis „Controller inaktiv“
Wenn das Ereignis „Controller inaktiv“ auftritt, werden kurz nach dem Herunterfahren der Controller alle L3-Datenpakete zu allen VTEPs auf diesem logischen Switch gesendet. Dies liegt daran, dass die standardmäßige L2-MAC-Verwendungsdauer kleiner ist als die L3-ARP-Zeitüberschreitung und die Controller nicht für die Aktualisierung der Einträge der verwendeten MAC-Tabelle verfügbar sind. Das Fluten kann zur Zurücksetzung von Übertragungen in NICs führen, die eine solche hohe Arbeitslast nicht verarbeiten können. Dies führt eventuell zu Paketausfällen bei Taktsignalprotokollen mit Auswirkungen auf HA-Anwendungen. Beispielsweise kann es für einen DLR mit NSX Edge-Appliance und aktivierter Hochverfügbarkeit zu einem Split-Brain-Szenario kommen, durch das OSPF zwischen DLR und ECMP-ESG fluktuiert (Flapping). Problem in 6.3.2 behoben.

Behobenes Problem 1793575: Der gesamte ausgehende NSX-Datenverkehr erfolgt über eine Netzwerkkarte (NIC), wenn das IP-Hash-Teaming aktiviert ist
Wenn NSX-Portgruppen mit einer IP-Hash-Teaming-Richtlinie (statischer EtherChannel oder LACP) konfiguriert sind, wird der gesamte ausgehende Datenverkehr aus diesen Portgruppen über eine einzige Netzwerkkarte (NIC) geleitet. Dies verursacht zwar keinen Verlust beim Datenverkehr, die Netzwerkarbeitslast wird aber nicht über alle verfügbaren Links verteilt. Im Falle eines Fehlers der verwendeten Netzwerkkarte wird der Datenverkehr aller NSX-Portgruppen zu einer anderen aktiven Netzwerkkarte im Team umgeleitet. Der eingehende Datenverkehr wird davon nicht beeinträchtigt und kann auf allen verfügbaren Links empfangen werden. Problem in 6.3.2 behoben.

Behobenes Problem 1812445: Die L2VPN-Bridge-Tabelle wird wegen eines DLR-pMAC mit doppelter ARP-Antwort funktionsunfähig
Der VXLAN-Trunk-Port des L2VPN-Servers auf dem Host verwirft nicht die ARP-Antwort von der virtuellen Client-Maschine mit einem pMAC als Ziel-MAC, wodurch die MAC-Tabelle der Bridge nicht mehr funktionsfähig ist, sodass der Datenverkehr verworfen wird. Problem in 6.3.2 behoben.

Behobenes Problem 1806934: CVE-2015-3240 von Openswan führt zu einem Denial-of-Service(DoS)-Fehler
IKE-Daemon in Libreswan vor 3.15 und Openswan vor 2.6.45 ermöglichen, sofern mit NSS erstellt, Remoteangreifern die Auslösung eines Denial-of-Service-Fehlers (Assertionsfehler und Daemon-Neustart) über einen Nullwert DH g^x in einer KE-Nutzlast in einem IKE-Paket. Problem in 6.3.2 behoben.

Behobenes Problem 1811884: Logischer Switch wird auf dem Host des globalen Synchronisierungsdienstes (Replikator) nicht entfernt
Sie können einen logischen Switch auf dem Host des Synchronisierungsdienstes (Replikator) nicht entfernen. Problem in 6.3.2 behoben.

Behobenes Problem 1803220: VXLAN-Konnektivität mit Hosts, für die der CDO-Modus aktiviert ist, geht verloren, wenn die Verbindung von Controller zu Host nicht verfügbar ist
Die CDO-Funktion (Controller Disconnected Operation, Betrieb mit getrenntem Controller) stellt die VXLAN-Konnektivität sicher, wenn der gesamte Controller-Cluster nicht aktiv oder nicht erreichbar ist. Wenn allerdings der Controller-Cluster aktiv ist und ein Host die Konnektivität mit ihm verliert, bleibt der Datenverkehr der Datenebene zu diesem Host von anderen Hosts, die mit dem Controller verbunden sind, eventuell weiterhin unterbrochen. In diesem Fall wurde der Host aus der VTEP-pro-VNI-Liste entfernt und die vom Remotehost gesendeten ARPs werden verworfen. Für Datenverkehr ausgehend von dem Host, der die Konnektivität mit dem Controller verloren hat, stellt die CDO-Funktion sicher, dass er das richtige Ziel erreicht. Problem in 6.3.2 behoben.

Behobenes Problem 1817673: ESXi-Host stürzt ab, und es kommt zu Routing-Problemen, wenn die DLR-LIF-IP-Adresse geändert wird und die vorherige IP-Adresse einer virtuellen Maschine zugewiesen ist
Auf Hosts mit aktiver Bridge wird der violette Diagnosebildschirm angezeigt. Es kommt zu DLR-Routing-Problemen auf allen Hosts, wenn mit der virtuellen Maschine kommuniziert wird, deren IP-Adresse der vorherigen DLR-LIF-IP-Adresse entspricht. Problem in 6.3.2 behoben.

Behobenes Problem 1825416: vApps mit Fencing schlagen in vCloud Director 8.20 nach dem Upgrade auf NSX for vSphere 6.3.x fehl
Nach dem Upgrade auf NSX 6.3.x und von NSX Edge-Gateways auf 6.3.x in vCloud Director 8.20 schlagen vApps mit Fencing fehl, und die virtuellen Maschinen in einem Netzwerk mit Fencing können nicht mit ihrem Gateway kommunizieren. Problem in 6.3.2 behoben.

Behobenes Problem 1842337: Es ist keine DLR-ARP-Auflösung für ECMP-ESG möglich
Die ARP-Auflösung im DLR für das ECMP-Routing schlägt fehl und beeinträchtigt den Nord-Süd-Datenverkehr. Problem in 6.3.2 behoben.

Behobenes Problem 1834837: Alle vCNS-Edges (Version 5.5.4) und NSX Edges (6.1.x und 6.2.x), die im VIX-Kommunikationsmodus ausgeführt werden, lassen sich nach einem Storage vMotion nicht mehr verwalten
NSX Edges, die mit MessageBus als Kommunikationsmodus ausgeführt werden, sind davon nicht betroffen. Problem in 6.3.2 behoben.

Behobenes Problem 1798469: Bei einigen NSX Edges können Split-Brain-Szenarien auftreten, auch wenn ihr Hochverfügbarkeitsstatus ordnungsgemäß angezeigt wird.
Aufgrund einer Race Condition im Hochverfügbarkeits-Mechanismus können bei einigen NSX Edges, die auf NSX 6.2.5 oder höher aktualisiert wurden, Split-Brain-Szenarien auftreten, auch wenn ihr Hochverfügbarkeitsstatus ordnungsgemäß angezeigt wird. Dies kann auch nach der erneuten Bereitstellung des Edge auftreten. Problem in 6.3.2 behoben.

Behobenes Problem 1828060: Am NSX Edge können bei hohem Datenverkehr während einem erzwungenen Synchronisationsvorgang Konnektivitätsprobleme auftreten.
Am NSX Edge können bei hohem Datenverkehr während der erzwungenen Synchronisierung Konnektivitätsprobleme auftreten. Problem in 6.3.2 behoben.

In NSX 6.3.2 behobene Probleme der Sicherheitsdienste

Behobenes Problem 1847753: Hosts schlagen beim Abrufen von Flows für ALG-fähige Protokolle mit einem violetten Diagnosebildschirm fehl.
Nach dem Upgrade von NSX for vSphere 6.2.4 auf 6.3.0 oder 6.3.1 mit in der Umgebung aktiviertem Flow Monitoring wird für den ESXi-Host ein violetter Diagnosebildschirm angezeigt. Problem in 6.3.2 behoben.

Behobenes Problem 1798537: Für den DFW-Controller-Vorgang auf ESXi (vsfwd) steht eventuell nicht mehr genügend Arbeitsspeicher zur Verfügung
In einer Umgebung mit einer großen Anzahl an Regeln oder mit großen Sicherheitsgruppen in der DFW-Konfiguration steht für den DFW-Controller-Vorgang auf ESXi (vsfwd) eventuell nicht mehr genügend Arbeitsspeicher zur Verfügung, sodass die Regeln für den Datenpfad nicht veröffentlicht werden können. Problem in 6.3.2 behoben.

Behobenes Problem 1853106: In der Benutzeroberfläche werden Fehler angezeigt, wenn die Zertifizierung deaktiviert wird oder wenn bestimmte Änderungen der IPsec-Konfiguration für das IPsec-VPN im PSK-Modus bearbeitet werden
Sie sehen die Fehlermeldung „Fehler beim Lesen von Zertifikaten und geheimen Schlüsseln. : 002 Kennwörter vergessen“ auf der Registerkarte „Globale Konfiguration“, wenn die Zertifizierung des PSK-Modus für IPsec VPN mit zertifikatsbasierter Authentifizierung deaktiviert ist oder geändert wurde. Problem in 6.3.2 behoben.

Behobenes Problem 1725524: Der Neustart von hostd führt eventuell zum Absturz von vsfwd, wenn Daten mithilfe von RabbitMQ gesendet werden
Alle Vorgänge zum Neustart des hostd-Vorgangs führen zum erneuten Aufbau von Verbindungen für vsfwd. vsfwd stürzt eventuell ab, wenn der Haupt-Thread die alte Verbindung deaktiviert, während einige andere Threads weiterhin Daten mithilfe des alten Kanals senden. Problem in 6.3.2 behoben.

Behobenes Problem 1800196: Die VMkernel-Protokollierung wird beendet, wenn eine große Anzahl von IP-Paketen mit Broadcast-MAC-Adressen einer DFW-Regel für die Ablehnung entspricht
DFW sendet Ablehnungspakete nur an Unicast-MAC-Adressen. Wenn IP-Pakete mit einer Broadcast-MAC-Adresse einer Ablehnungsregel entsprechen, wird kein Ablehnungspaket gesendet. Dieses Ereignis wird aber in der Datei vmkernel.log protokolliert. Wenn das Netzwerk mit diesem Datenverkehr geflutet wird, nimmt vmkernel.log wegen Überlastung keine Meldungen mehr auf, und die Protokollierung wird beendet. Das Ablehnen von Paketen mit Broadcast-MAC-Adressen wird jetzt nur dann protokolliert, wenn das Debugging aktiviert ist. Problem in 6.3.2 behoben. Die Ablehnung von Paketen mit Broadcast-MAC-Adressen wird jetzt nur dann protokolliert, wenn das Debugging aktiviert ist.

Behobenes Problem 1807152: Wenn eine virtuelle Maschine von einem Cluster in einen anderen neu vorbereiteten Cluster verschoben wird, werden Regeln, für die unter „Angewendet auf“ die virtuelle Leitung festgelegt ist, nicht für die VM angewendet.
Wenn dem Datencenter ein neuer Cluster hinzugefügt wird, wird die Cluster-Liste für Regeln, für die unter Angewendet auf die virtuelle Leitung festgelegt ist, nicht aktualisiert. Wenn dann eine virtuelle Maschine aus dem alten Cluster auf den neu vorbereiteten Cluster migriert wird, werden die Regeln nicht angewendet. Problem in 6.3.2 behoben.

Behobenes Problem 1812467: Container-Updates in umfangreichen VMs mit verschachtelten Sicherheitsgruppen führen zu erheblichen Verzögerungen bei Aktualisierungen auf dem Host
Wenn auf dem Host umfangreiche virtuelle Maschinen mit verschachtelt strukturierten Sicherheitsgruppen vorhanden sind, führt eine einzige Änderung der Bestandsliste zu einem Leeren des Container-Updates, sodass es bei einer damit eventuell verbundenen Änderung auf dem Host zu einer erheblichen Verzögerung kommt. Problem in 6.3.2 behoben.

Behobenes Problem 1847880: Das Entladen von VIBs von Hosts in einem gegebenen Cluster schlägt mit folgendem Fehler fehl: „vmkload_mod: Modul vsip kann nicht entfernt werden: Die Anzahl der belegten Ressourcen des Moduls ist nicht Null“
Nachdem die Deinstallation der VIBs ausgelöst wurde und andere NSX-VIBs deinstalliert wurden, zeigt der Befehl ssxcli software vib list| grep vsip an, dass esx-vsip noch installiert ist. Problem in 6.3.2 behoben.

Behobenes Problem 1812792: DFW verwirft Pakete im Zusammenhang mit Split TCP-Handshake
Die verteilte Firewall verarbeitet den Split TCP-Handshake nicht ordnungsgemäß. Sie ignoriert die Fensterskalierungsoption, was zu weiteren verworfenen Paketen führt, da das Fenster nicht korrekt berechnet wird. Dies wurde dadurch verursacht, dass das erste SYN ACK-Paket verloren ging und die Neuübertragung des SYN eine Challenge ACK generierte, die den Split TCP-Handshake verursachte. Problem in 6.3.2 behoben.

Die folgenden Probleme wurden in früheren 6.3.x-Versionen behoben:

In 6.3.1 und früher behobene allgemeine Probleme

Behobene Probleme 1575342, 1719402: Wenn in einer NSX for vSphere 6.x-Umgebung eine Dienst-VM (Service VM, SVM) migriert wird (vMotion/SvMotion), kann es zu einer Unterbrechung des Dienstes kommen oder der ESXi-Host kann abstürzen
Ab der Version 6.3.0 können Sie eine SVM nicht mehr mithilfe von vMotion/SvMotion migrieren. Die Dienst-VMs müssen für eine korrekte Ausführung auf dem Host verbleiben, auf dem sie bereitgestellt wurden.
Bisher war eine Migration auf einen anderen Host möglich. Sie wurde aber nicht unterstützt und führte zu einer Unterbrechung des Dienstes und zu Problemen mit dem Host.
Weitere Informationen dazu enthält der VMware-Knowledgebase-Artikel 2141410. Problem in 6.3.0 behoben.

Behobenes Problem 1708769: Erhöhte Latenz bei SVM (Dienst-VM) nach Snapshot in NSX
Dieses Problem tritt auf, weil durch die Ausführung eines Snapshots eines Dienst-VMs (SVM) zusätzliche Netzwerklatenz verursacht werden kann. Ein Snapshot wird mitunter durch in der Umgebung ausgeführte Sicherungsanwendungen aufgerufen. Problem in 6.3.0 behoben.

Behobenes Problem 1760102: Nach dem Löschen und erneuten Bereitstellen eines NSX Controllers zur Wiederherstellung nach einem Speicherausfall können virtuelle Maschinen gegebenenfalls nicht kommunizieren.
Im Falle eines Speicherausfalls wird ein NSX Controller für die vSphere 6.2.4/6.2.5-Umgebung gegebenenfalls in den schreibgeschützten Modus versetzt. Wenn Sie den Controller löschen und erneut bereitstellen, um diesen Zustand aufzuheben, können einige VMs unter Umständen nicht kommunizieren. Bei einem Speicherausfall eines Controllers sollte er sich nach einem Neustart nicht mehr im schreibgeschützten Modus befinden. Aktuell ist dies aber in NSX nicht der Fall. Problem in 6.3.0 behoben.

Behobenes Problem 1662842: Guest Introspection: Die Verbindung zwischen MUX und USVM wird bei dem Versuch getrennt, nicht auflösbare Windows-SIDs aufzulösen
Der Guest Introspection-Dienst befindet sich dann im Status „Warnung“, wobei der Status jedes Guest Introspection-Modul den Status „Warnung“ abwechselnd annimmt und wieder verliert. Netzwerkereignisse werden erst wieder an den NSX Manager übermittelt, wenn die Verbindung mit der Guest Introspection-VM wiederhergestellt wurde. Dies hat Auswirkungen sowohl auf Activity Monitoring als auch auf die ID-Firewall, wenn über den Guest Introspection-Pfad Anmeldeereignisse erkannt werden. Problem in 6.3.0 behoben.

Problem 1752051: Für Guest Introspection wird als Dienststatus „Nicht bereit“ gemeldet, wenn die Zeit für die Kommunikation von NSX Manager mit der USVM überschritten wird

Wenn die vorgesehene Kennwortänderung mit NSX Manager auf dem internen Nachrichtenbus (RabbitMQ) nicht durchgeführt werden kann, wird für die globale Guest Introspection-SVM eventuell eine Fehlermeldung in der Art „PLAIN-Anmeldung zurückgewiesen: Benutzer ‚usvm-admin-host-14‘ - ungültige Anmeldedaten“ angezeigt.

Problemumgehung: Um die Verbindung zwischen der USVM und NSX Manager wiederherzustellen, starten Sie die USVM neu oder löschen Sie diese manuell und klicken Sie dann auf die Schaltfläche „Auflösen“ in der Benutzeroberfläche von Service Composer, um eine erneute Bereitstellung der USVM nur für den betroffenen Host anzufordern.

Behobenes Problem 1716328: Entfernen eines Host im Wartungsmodus kann später zu einem Fehler in der Clustervorbereitung führen

Wenn ein Administrator einen NSX-aktivierten ESXi-Host in den Wartungsmodus versetzt und dann aus einem vorbereiteten NSX-Cluster entfernt, kann NSX die ID-Nummer des entfernten Host nicht löschen. Nachdem die Installation in diesem Zustand ist, schlägt die Clustervorbereitung für dieses Cluster fehl, wenn in einem anderen Cluster ein anderer Host mit derselben ID vorhanden ist oder dieser Host einem anderen Cluster hinzugefügt wird.

Problem in 6.3.0 behoben.

Behobenes Problem 1710624: Ereignisprotokollserver von Windows 2008 wird als „TYPE“ von „WIN2K3“ hinzugefügt, falls serverType nicht im REST-API-Anforderungstext angegeben ist

Wenn Sie eine API-Anforderung für den EventLog-Server erstellen, wird der Server als „TYPE“ von „WIN2K3“ hinzugefügt. Wenn Sie den EventLog-Server nur für IDFW verwenden, funktioniert IDFW eventuell nicht korrekt. Problem in 6.3.0 behoben.

In 6.3.1 und früher behobene Probleme der Installation und des Upgrades

Behobenes Problem 1808478: Der vsfwd-Dienst kann nicht gestartet werden, wenn der vmvisor-Arbeitsspeicher nach dem Upgrade von NSX 6.2.x auf NSX 6.3.0 nicht zugeteilt werden kann
Der vsfwd-Dienst kann nicht gestartet werden, wenn der vmvisor-Arbeitsspeicher nach dem Upgrade von NSX 6.2.x auf NSX 6.3.0 nicht zugeteilt werden kann. Weitere Informationen enthält der VMware-Knowledgebase-Artikel 2148974. Problem in 6.3.1 behoben

Behobenes Problem 1818257: Es werden keine VTEP-Informationen an die Controller übergeben, wenn für VXLAN nach dem Host-Upgrade von NSX 6.2.x auf NSX 6.3.0 mit ESXi 6.0 das erweiterte LACP-Protokoll verwendet wird
Beim Upgrade von NSX 6.2.x auf 6.3.0 mit ESXi 6.0 werden nach dem Hostupgrade die VTEP-Informationen nicht an die Controller übergeben, wenn das erweiterte LACP-Protokoll verwendet wird. Weitere Informationen enthält der VMware-Knowledgebase-Artikel 2149210. Problem in 6.3.1 behoben.

Behobenes Problem 1495307: Während eines Upgrades werden die L2- und L3-Firewallregeln nicht für Hosts veröffentlicht
Nach dem Veröffentlichen einer Änderung an der Distributed Firewall-Konfiguration lautet der Status sowohl auf der Benutzeroberfläche als auch in der API permanent InProgress und der Datei „vsfwd.log“ wird kein Protokoll für L2- oder L3-Regeln hinzugefügt. Problem in 6.3.0 behoben.

Behobenes Problem 1491820: Im NSX Manager-Protokoll werden nach dem Upgrade auf NSX 6.2 Meldungen mit dem Text WARN messagingTaskExecutor-7 angezeigt
Nach dem Upgrade von NSX 6.1.x auf NSX 6.2 wird das NSX Manager-Protokoll mit so oder ähnlich lautenden Meldungen überflutet: WARN messagingTaskExecutor-7 ControllerInfoHandler:48 - Host ist unbekannt: host-15 gibt leere Liste zurück. Dies wirkt sich nicht auf die Funktionsfähigkeit aus. Problem in 6.3.0 behoben.

In 6.3.1 und früher behobene NSX Manager-Probleme

Behobenes Problem 1671067: Das NSX-Plug-In wird nicht im vCenter Web Client angezeigt, wenn das ESXTOP-Plug-In ebenfalls installiert ist
Nach der Bereitstellung von NSX und einer erfolgreichen Registrierung mit vCenter wird das NSX-Plug-In im vCenter Web Client nicht angezeigt. Dieses Problem entsteht aufgrund eines Konflikts zwischen dem NSX-Plug-In und dem ESXTOP-Plug-In. Problem in 6.3.0 behoben.

In NSX 6.3.1 und früher behobene Netzwerk- und Edge-Dienste-Probleme

Behobenes Problem 1740231: IP-Adresse kann der Hochverfügbarkeits(HA)-Schnittstelle nicht hinzugefügt werden
Ab 6.3.0 können Sie IP-Adressen für die DLR-HA-Schnittstelle hinzufügen. Diese Funktionalität war in einigen älteren NSX-Versionen nicht verfügbar. Sie wurde wieder hinzugefügt, um die Kompatibilität mit dem API-Verhalten der DLR-HA-Verwaltungsschnittstelle zu gewährleisten. Problem in 6.3.0 behoben

Behobenes Problem 1716333: Durch die Änderung der Größe der Edge-VM oder eines Platzierungsparameters bei der Aktivierung oder Deaktivierung der Edge-Hochverfügbarkeit werden eventuell zusätzliche Edge-VMs erstellt
Wenn die Größe der Edge-VM oder eines Platzierungsparameters (wie z. B. ein Datenspeicher oder ein Ressourcenpool) geändert und gleichzeitig die Edge-Hochverfügbarkeit aktiviert oder deaktiviert wird, kann die NSX-Datenbank der verwalteten Objekte beschädigt werden, sodass Edge-VMs nicht mehr verwendet werden können. Darüber hinaus werden in einer Umgebung mit Cross-vCenter die verbleibenden Edge-VMs auf die sekundäre Site repliziert. Problem in 6.3.0 behoben.

Behobenes Problem 1717369: Bei einer Konfiguration im HA-Modus können sowohl aktive als auch Standby-Edge-VMs auf demselben Host bereitgestellt werden
Dieses Problem kommt zustande, weil bei Vorgängen zur erneuten Bereitstellung und bei Upgrade-Vorgängen keine Anti-Affinitätsregeln erstellt und automatisch auf die vSphere-Hosts angewendet werden. Bei einer HA-Aktivierung auf einem vorhandenen Edge tritt dieses Problem nicht auf.

Problem in 6.3.0 behoben. Das folgende Verhalten ist das erwartete Verhalten:

  • Wenn vSphere HA aktiviert ist, werden bei der erneuten Bereitstellung und bei Upgrades Anti-Affinitätsregeln für Edge-VMs eines HA-Paares erstellt.
  • Wenn vSphere HA deaktiviert ist, werden keine Anti-Affinitätsregeln für Edge-VMs eines HA-Paares erstellt.

Behobenes Problem 1675659: Unverankerte statische Routen werden gegenüber dynamischen Routen (OSPF) bevorzugt
Eine unverankerte statische Route zur Sicherung wird falsch in die Routing-Tabelle eines Edges eingegeben, wenn die Route Redistribution aktiviert ist, auch wenn eine OSPF-Route verfügbar ist. Problem in 6.3.0 behoben.

Behobenes Problem 1733165: IPsec verursacht u. U. das Entfernen dynamischer Routen aus der NSX Edge-Tabelle zum Weiterleiten
Wird ein über die dynamische Route erreichbares Subnetz als Remotesubnetz für die IPsec-Konfiguration verwendet, wird dieses Subnetz von NSX Edge aus der Tabelle zum Weiterleiten entfernt und nicht erneut installiert, auch nicht, nachdem dieses Subnetz aus der IPsec-Konfiguration entfernt wurde. Problem in 6.3.0 behoben.

Behobenes Problem 1663902: Das Umbenennen einer NSX Edge-VM unterbricht den Datenverkehr durch das Edge
Das Umbenennen einer NSX Edge-VM unterbricht den Datenverkehr durch das Edge. Problem in 6.3.0 behoben.

Behobenes Problem 1624663: Nach dem Klicken auf „Erweitertes Debugging konfigurieren“ wird die vCenter-Benutzeroberfläche aktualisiert und die Änderung wird nicht beibehalten
Nach dem Klicken auf „<Spezifische Edge-ID>“ > „Konfiguration“ > „Aktion“ > „Erweitertes Debugging konfigurieren“ wird die vCenter-Benutzeroberfläche aktualisiert und die Änderung wird nicht beibehalten. Problem in 6.3.0 behoben.

Behobenes Problem 1706429: Kommunikationsprobleme beim Aktivieren der Hochverfügbarkeit (HA) nach der anfänglichen Bereitstellung eines logischen (verteilten) Routers können dazu führen, dass beide logischen Router-Appliances aktiv sind.
Wenn Sie einen logischen Router ohne HA bereitstellen und HA später aktivieren (durch Bereitstellen einer neuen logischen Router-Appliance) oder wenn Sie HA deaktivieren und dann wieder aktivieren, fehlt einer der logischen Router-Appliances eine verbundene Route zur HA-Schnittstelle. Dies führt dazu, dass sich beide Appliances im Zustand „aktiv“ befinden. Problem in 6.3.0 behoben.

Behobenes Problem 1542416: Der Datenpfad funktioniert nach erneuter Bereitstellung des Edge und HA-Failover bei Teilschnittstellen 5 Minuten lang nicht
Nach erneuter Bereitstellung oder HA-Failover entsteht ein fünf Minuten langer Ausfall, wenn Teilschnittstellen verwendet werden. Das Problem wurde bei Schnittstellen nicht beobachtet. Problem in 6.3.0 behoben.

Behobenes Problem 1492547: Die Konvergenz dauert mitunter sehr lange, wenn der NSX-basierte OSPF-Area-Border-Router mit der höchsten IP-Adresse heruntergefahren oder neu gestartet wird.
Wenn ein NSSA-Area-Border-Router, der nicht über die höchste IP-Adresse verfügt, heruntergefahren oder neu gestartet wird, konvergiert der Datenverkehr schnell auf einen anderen Pfad. Wird ein NSSA-Area-Border-Router mit der höchsten IP-Adresse heruntergefahren oder neu gestartet, so nimmt die erneute Konvergenz mitunter einen Zeitraum von mehreren Minuten in Anspruch. Der OSPF-Vorgang kann manuell bereinigt werden, um die Konvergenzzeit zu verringern. Problem in 6.3.0 behoben.

Behobenes Problem 1510724: Nach der Universal Distributed Logical Router(UDLR)-Erstellung werden die Standardrouten auf den Hosts nicht aufgefüllt
Nach einer Änderung von NSX Manager vom eigenständigen in den primären Modus zum Konfigurieren von Cross-vCenter in NSX for vSphere 6.2.x treten möglicherweise die folgenden Symptome auf:

  • Beim Erstellen eines neuen UDLR werden die Standardrouten auf der Hostinstanz nicht aufgefüllt.
  • Die Routen werden zwar in der UDLR-NSX Edge Appliance (Kontroll-VM), aber nicht auf der Hostinstanz aufgefüllt.
  • Beim Ausführen des Befehls show logical-router host host-ID dlr Edge-ID route werden keine Standardrouten angezeigt.
Problem in 6.3.0 behoben.

Behobenes Problem 1704540: Hohes Volumen an Aktualisierungen der MAC-Lerntabelle mit NSX L2 Bridge und LACP kann dazu führen, dass nicht genügend Arbeitsspeicher verfügbar ist
Wenn eine NSX L2 Bridge eine MAC-Adresse unter einem anderen Uplink erkennt, meldet sie den Controllern über den netcpa-Prozess eine Änderung der MAC-Lerntabelle. Netzwerkumgebungen mit LACP lernen dieselbe MAC-Adresse an mehreren Schnittstellen, was zu einem sehr hohen Volumen an Tabellenaktualisierungen und zu einer potenziellen Erschöpfung des Arbeitsspeichers führt, der vom netcpa-Prozess für die Meldung benötigt wird. Informationen hierzu finden Sie im VMware-Knowledgebase-Artikel 2147181. Problem in 6.3.0 behoben.

Behobenes Problem 1716545: Eine Änderung der Appliance-Größe von Edge hat keinen Einfluss auf die CPU- und Arbeitsspeicherreservierung von Standby-Edges
Die Reservierungseinstellungen werden nur der ersten Edge-VM als Teil eines HA-Paares zugewiesen.

Behobenes Problem 1772004: Edge HA-Failover von Knoten 0 auf Knoten 1 nimmt mehr Zeit in Anspruch als erwartet
Ein Failover von Knoten 0 auf Knoten 1 nimmt in Edge HA-konfigurierten Umgebungen mehr Zeit in Anspruch als erwartet, der Datenverkehr-Failover von Knoten 0 auf Knoten 1 verläuft hingegen normal. Problem in 6.3.0 behoben.

Behobenes Problem 1726379: Wenn der IP-Multicast-Bereich in den letzten drei Oktetten einen oberen Grenzwert aufweist, der 99 überschreitet, schlägt die VXLAN-Trunk-Portgruppen-Konfiguration fehl.
Wenn Sie beim Konfigurieren der Segment-ID einen Multicast-IP-Bereich erstellen, der einen oberen Grenzwert aufweist, der in den letzten drei Oktetten über 99 hinausgeht, beispielsweise 1.100.100.100, und zudem einen Multicast- oder hybriden logischen Switch mit demselben Multicast-IP-Bereich erstellen, schlägt die VXLAN-Trunk-Portgruppen-Konfiguration fehl. Problem in 6.3.0 behoben.

In 6.3.1 und früher behobene Probleme der Sicherheitsdienste

Behobenes Problem 1767402: DFW-Regeln, für die „Angewendet auf“ auf eine Sicherheitsgruppe festgelegt wurde, werden nicht auf Hosts veröffentlicht.
DFW-Regeln, bei denen das Feld „Angewendet auf“ auf eine Sicherheitsgruppe festgelegt wurde, werden nicht auf ESXi-Hosts in einem neuen Cluster veröffentlicht. Problem in 6.3.0 behoben.

Behobenes Problem 1743366: Die NSX-Schwellenwertüberwachung ist standardmäßig deaktiviert, um einen potenziellen Absturz zu vermeiden
Wenn das Firewallmodul ausgeführt wird, deaktiviert NSX die Schwellenwertüberwachung für den Arbeitsspeicher, um einen potenziellen Absturz zu vermeiden. Wenn auf dem Host ESX 6.5P01 oder ESX 6.0U3 oder höher ausgeführt wird, wird die Schwellenwertüberwachung für den Arbeitsspeicher automatisch aktiviert. Problem in 6.3.0 behoben.

Behobenes Problem 1491046: IPv4-IP-Adresse wird nicht automatisch genehmigt
Die IPv4-IP-Adresse wird nicht automatisch genehmigt, wenn die SpoofGuard-Richtlinie in VMware NSX for vSphere 6.2.x auf „Vertrauen bei erster Nutzung“ (Trust On First Use, TOFU) festgelegt ist. Problem in 6.3.0 behoben.

Behobenes Problem 1686036: Firewallregeln können nicht hinzugefügt, bearbeitet oder entfernt werden, wenn der Standardabschnitt gelöscht wird
Wenn der Layer2- oder Layer3-Standardabschnitt gelöscht wird, kann das Veröffentlichen einer Firewallregel fehlschlagen. Problem in 6.3.0 behoben.

Behobenes Problem 1717994: Status-API-Abfrage für die verteilte Firewall meldet zwischenzeitlich den internen Serverfehler 500
Wird die Status-API-Abfrage für DFW ausgeführt, während ein neuer Host einem vorbereiteten Host-Cluster hinzugefügt wird, schlägt die API-Abfrage bei einigen Versuchen mit 500 internen Serverfehlern fehl und liefert erst dann wieder die korrekte Antwort, wenn auf dem Host mit der Installation von VIBs begonnen wird. Problem in 6.3.0 behoben.

Behobenes Problem 1717635: Der Firewallkonfigurationsvorgang schlägt fehl, wenn mehrere Cluster in einer Umgebung vorhanden sind und parallel Änderungen vorgenommen werden
Wenn in einer Umgebung mit mehreren Clustern zwei oder mehr Benutzer dauerhaft die Firewallkonfiguration in einer engen Schleife ändern, (z. B. Hinzufügen/Löschen von Abschnitten oder Regeln), schlagen einige Vorgänge fehl, und dem Benutzer wird eine API-Antwort angezeigt, die der Folgenden ähnelt: org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch update; nested exception is javax.persistence.PersistenceException: org.hibernate.exception.GenericJDBCException: Could not execute JDBC batch update
Problem in 6.3.0 behoben.

Problem 1707931: Die Reihenfolge von Distributed Firewall-Regeln ändert sich, wenn in Service Composer definierte Dienstrichtlinien vorhanden sind und wenn eine Firewallregel geändert oder mit in der Firewall-UI angewandtem Filter veröffentlicht wird
Beim Ändern der Reihenfolge, Hinzufügen oder Löschen von in Service Composer erstellten Dienstrichtlinien, nachdem unter „Networking & Security“ > „Firewall“ mindestens ein Veröffentlichungsvorgang durchgeführt wurde, ändert sich die Reihenfolge der Firewallregeln. Dies kann nicht beabsichtigte Folgen haben. Problem in 6.3.0 behoben.

Behobenes Problem 1682552: Schwellenwertereignisse für CPU/Speicher/CPS für die verteilte Firewall werden nicht gemeldet
Selbst wenn für die DFW-Schwellenwerte für CPU/Speicher/CPS die entsprechende Einstellung vorgenommen wurde, werden Schwellenwertereignisse beim Überschreiten von Schwellenwerten nicht gemeldet. Problem in 6.3.0 behoben.

Behobenes Problem 1620460: NSX kann nicht verhindern, dass Benutzer im Regelabschnitt von Service Composer Regeln erstellen
Im vSphere Web Client kann die Schnittstelle der Firewall für Netzwerk und Sicherheit nicht verhindern, dass Benutzer im Service Composer-Regelabschnitt Regeln hinzufügen. Das Hinzufügen von Regeln über/unter dem Service Composer-Abschnitt durch die Benutzer sollte zulässig sein, jedoch nicht innerhalb dieses Abschnitts. Problem in 6.3.0 behoben.

Behobenes Problem 1445897: In VMware NSX for vSphere 6.1.x und 6.2.x können Distributed-Firewall(DFW)-Regeln nicht veröffentlicht werden, nachdem das Objekt, auf das verwiesen wird, gelöscht wurde. Problem in 6.2.3 behoben.

Behobenes Problem 1704661, 1739613: Verlust der VM-Netzwerkverbindung mit folgendem Fehler: „Failed to restore PF state: Limit exceeded.“ (PF-Status konnte nicht wiederhergestellt werden. Grenzwert überschritten.)
Verlust der VM-Netzwerkverbindung mit folgendem Fehler: „Failed to restore PF state: Limit exceeded.“ (PF-Status konnte nicht wiederhergestellt werden. Grenzwert überschritten.) Problem in 6.3.0 behoben.

In 6.3.1 und früher behobene Probleme der Lösungsinteroperabilität

Behobenes Problem 1527402: Windows-VM mit einem NSX-Netzwerk-Introspektions-Treiber verliert TCP-Konnektivität
In einer VMware NSX for vSphere 6.x-Umgebung verliert die Windows-VM mit einem NSX-Netzwerk-Introspektions-Treiber (vnetflt.sys), die mit einer USVM (Guest Introspection-SVM) verbunden ist, zeitweilig die TCP-Netzwerkkonnektivität. Problem in 6.3.0 behoben.

Behobenes Problem 1530360: Nach einem Failover für eine NSX Manager-VM wird für Site Recovery Manager (SRM) fälschlicherweise ein Zeitüberschreitungsfehler angezeigt.
Nach einem Failover für eine NSX Manager-VM wird von SRM fälschlicherweise ein Zeitüberschreitungsfehler beim Warten auf VMware Tools angezeigt. In diesem Fall wird VMware Tools tatsächlich innerhalb eines Zeitüberschreitungsintervalls von 300 Sekunden ausgeführt. Problem in 6.3.0 behoben.

Revisionsverlauf der Dokumente


8. Juni 2017: Erste Auflage für NSX 6.3.2.
22. Juni 2017: Zweite Auflage für NSX 6.3.2. Behobenes Problem 1847753 wurde hinzugefügt.
11. August 2017: Dritte Auflage für NSX 6.3.2. Hinweis zur Unterstützung von Open VM Tools wurde hinzugefügt.
18. August 2017: Vierte Auflage für NSX 6.3.2. Problem 1878081 wurde hinzugefügt.
21. August 2017: Fünfte Auflage für NSX 6.3.2. Einige frühere Probleme wurden gelöscht.
2. Oktober 2017: Sechste Auflage für NSX 6.3.2. Empfohlene Versionen wurden aktualisiert.