Dieser Abschnitt enthält Informationen zur Fehlerbehebung bei Problemen mit der Installation.

Grundlegende Infrastrukturdienste

Die folgenden Dienste müssen auf den Appliances und Hypervisoren ausgeführt werden. Das gilt auch für vCenter Server, wenn es als Compute Manager verwendet wird.
  • NTP
  • DNS

Achten Sie darauf, dass die Firewall nicht den Datenverkehr zwischen NSX-T-Komponenten und -Hypervisoren blockiert. Achten Sie darauf, dass die erforderlichen Ports zwischen den Komponenten geöffnet sind.

Melden Sie sich zum Leeren des DNS-Cache im NSX Manager über die SSH als Root beim Manager an und führen Sie den folgenden Befehl aus: 
root@nsx-mgr-01:~# /etc/init.d/resolvconf restart
[ ok ] Restarting resolvconf (via systemctl): resolvconf.service.
Daraufhin können Sie die DNS-Konfigurationsdatei überprüfen. 
root@nsx-mgr-01:~# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.253.1
search mgt.sg.lab

Melden Sie sich als Root-Benutzer an und führen Sie su admin aus, um nsxcli in NSX Manager zu starten. Für Admin-Benutzer ist nsxcli die standardmäßige Eingabeaufforderung.

Überprüfen Sie die DNS-Server mit dem folgenden nsxcli-Befehl:

get name-servers 
198.10.10.1
198.10.10.2
198.10.10.3

Überprüfen der Kommunikation vom Host zum Controller und Manager

Auf einem ESXi-Host mit NSX-T-CLI-Befehlen: 
esxi-01.corp.local> get managers
- 192.168.110.19   Connected
 
esxi-01.corp.local> get controllers
 Controller IP    Port     SSL         Status       Is Physical Master   Session State  Controller FQDN
 192.168.110.16   1235   enabled     connected             true               up               NA
Auf einem KVM-Host mit NSX-T-CLI-Befehlen: 
kvm-01> get managers
- 192.168.110.19   Connected
 
kvm-01> get controllers
 Controller IP    Port     SSL         Status       Is Physical Master   Session State  Controller FQDN
 192.168.110.16   1235   enabled     connected             true               up               NA
Auf einem ESXi-Host mit Host-CLI-Befehlen: 
[root@esxi-01:~] esxcli network ip  connection list | grep 1235
tcp         0       0  192.168.110.53:42271                        192.168.110.16:1235   ESTABLISHED     67702  newreno  nsx-proxy
[root@esxi-01:~]
[root@esxi-01:~] esxcli network ip  connection list | grep 5671
tcp         0       0  192.168.110.253:11721             192.168.110.19:5671   ESTABLISHED   2103688  newreno  mpa
tcp         0       0  192.168.110.253:30977             192.168.110.19:5671   ESTABLISHED   2103688  newreno  mpa
Auf einem KVM-Host mit Host-CLI-Befehlen: 
root@kvm-01:/home/vmware# netstat -nap | grep 1235
tcp        0      0 192.168.110.55:53686    192.168.110.16:1235     ESTABLISHED 2554/nsx-proxy
root@kvm-01:/home/vmware#
root@kvm-01:/home/vmware#
root@kvm-01:/home/vmware# netstat -nap | grep 5671
tcp        0      0 192.168.110.55:50108    192.168.110.19:5671     ESTABLISHED 2870/mpa
tcp        0      0 192.168.110.55:50110    192.168.110.19:5671     ESTABLISHED 2870/mpa

root@kvm-01:/home/vmware# tcpdump -i ens32 port 1235 | grep kvm-01
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens32, link-type EN10MB (Ethernet), capture size 262144 bytes
<truncated output>
03:46:27.040461 IP nsxcontroller01.corp.local.1235 > kvm-01.corp.local.38754: Flags [P.], seq 3315301231:3315301275, ack 2671171555, win 323, length 44
03:46:27.040509 IP kvm-01.corp.local.38754 > nsxcontroller01.corp.local.1235: Flags [.], ack 44, win 1002, length 0
^C
<truncated output>
root@kvm-01:/home/vmware#

root@kvm-01:/home/vmware# tcpdump -i ens32 port 5671 | grep kvm-01
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens32, link-type EN10MB (Ethernet), capture size 262144 bytes
03:51:16.802934 IP kvm-01.corp.local.58954 > nsxmgr01.corp.local.amqps: Flags [P.], seq 1153:1222, ack 1790, win 259, length 69
03:51:16.823328 IP nsxmgr01.corp.local.amqps > kvm-01.corp.local.58954: Flags [P.], seq 1790:1891, ack 1222, win 254, length 101
^C
<truncated output>

Host-Registrierungsfehler

Wenn NSX-T die falsche IP-Adresse verwendet, schlägt die Hostregistrierung fehl. Dies kann geschehen, wenn ein Host über mehrere IP-Adressen verfügt. Beim Versuch, die Transportknoten zu löschen, verbleiben diese im verwaisten Zustand. So lässt sich das Problem beheben:
  • Klicken Sie auf Fabric > Knoten > Hosts, bearbeiten Sie den Host und entfernen Sie alle IP-Adressen außer der Management-IP-Adresse.
  • Klicken Sie auf die Fehler und wählen Sie Beheben.

Probleme beim KVM-Host

Probleme beim KVM-Host werden manchmal durch unzureichenden Festplattenspeicher verursacht. Das /boot-Verzeichnis kann sich schnell füllen und Fehler verursachen, wie zum Beispiel:
  • Softwareinstallation auf Host fehlgeschlagen
  • Kein Speicherplatz frei auf Gerät
Sie können den Befehl df -h ausführen, um zu überprüfen, wie viel Speicher verfügbar ist. Wenn das /boot-Verzeichnis bei 100 % angekommen ist, können Sie Folgendes tun:
  • sudo dpkg --list 'linux-image*' | grep ^ii ausführen, um alle installierten Kernels anzuzeigen.
  • uname -r ausführen, um Ihren derzeit ausgeführten Kernel anzuzeigen. Entfernen Sie diesen Kernel nicht (linux-image).
  • Mithilfe von apt-get purge nicht mehr benötigte Images entfernen. Führen Sie zum Beispiel sudo apt-get purge linux-image-3.13.0-32-generic linux-image-3.13.0-33-generic aus.
  • Den Host neu starten.
  • In NSX Manager die Fehler überprüfen und Beheben auswählen.
  • Überprüfen, ob die VMs eingeschaltet sind.

Konfigurationsfehler bei der Bereitstellung einer Edge-VM

Nach der Bereitstellung einer Edge-VM zeigt NSX Manager als Status der VM Konfigurationsfehler an. Das Manager-Protokoll weist sinngemäß die folgende Meldung auf: 
nsx-manager NSX - FABRIC [nsx@6876 comp="nsx-manager" errorCode="MP16027" subcomp="manager"] Edge 758ad396-0754-11e8-877e-005056abf715 is not ready for configuration error occurred, error detail is NSX Edge configuration has failed. The host does not support required cpu features: ['aes'].

Mit einem Neustart des Edge-Datenpfaddienstes und anschließendem Neustart der VM sollte das Problem behoben werden.

Erzwingen des Entfernens eines Transportknotens

Mit dem folgenden API-Aufruf können Sie einen Transportknoten entfernen, der im verwaisten Zustand steckengeblieben ist: 
DELETE https://<NSX Manager>/api/v1/transport-nodes/<TN ID>?force=true

NSX Manager werden führt keine Validierungen im Hinblick darauf durch, ob aktive VMs auf dem Host ausgeführt werden. Sie sind für die Löschung von N-VDS und VIBs verantwortlich. Wenn Sie den Knoten über den Compute Manager hinzugefügt haben, löschen Sie den Compute Manager zuerst und löschen Sie dann den Knoten. Der Transportknoten wird ebenfalls gelöscht.