vSphere ESX Agent Manager stellt VIBs auf ESXi-Hosts bereit.

Für die Bereitstellung auf Hosts muss das DNS auf den Hosts, auf vCenter Server und NSX Manager konfiguriert werden. Für die Bereitstellung ist kein Neustart des ESXi-Hosts erforderlich. Dieser muss allerdings bei Aktualisierungen oder nach dem Entfernen von VIBs vorgenommen werden.

VIBs werden auf NSX Manager gehostet und sind auch als ZIP-Datei verfügbar.

Die Datei kann von https://<NSX-Manager-IP>/bin/vdn/nwfabric.properties heruntergeladen werden. Die ZIP-Datei zum Herunterladen unterscheidet sich je nach NSX- und ESXi-Version. vSphere 6.0-Hosts verwenden z. B. die Datei https://<NSX-Manager-IP>/bin/vdn/vibs-6.2.3/6.0-3771165/vxlan.zip.

C:\Users\Administrator>curl -k https://nsxmgr-01a.corp.local/bin/vdn/nwfabric.properties
# 5.1 VDN EAM Info
VDN_VIB_PATH.1=/bin/vdn/vibs-6.2.3/5.1-2107743/vxlan.zip
VDN_VIB_VERSION.1=2107743
VDN_HOST_PRODUCT_LINE.1=embeddedEsx
VDN_HOST_VERSION.1=5.1.*

# 5.5 VDN EAM Info
VDN_VIB_PATH.2=/bin/vdn/vibs-6.2.3/5.5-3771174/vxlan.zip
VDN_VIB_VERSION.2=3771174
VDN_HOST_PRODUCT_LINE.2=embeddedEsx
VDN_HOST_VERSION.2=5.5.*

# 6.0 VDN EAM Info
VDN_VIB_PATH.3=/bin/vdn/vibs-6.2.3/6.0-3771165/vxlan.zip
VDN_VIB_VERSION.3=3771165
VDN_HOST_PRODUCT_LINE.3=embeddedEsx
VDN_HOST_VERSION.3=6.0.*

# 6.1 VDN EAM Info
VDN_VIB_PATH.4=/bin/vdn/vibs-6.2.3/6.1-3689890/vxlan.zip
VDN_VIB_VERSION.4=3689890
VDN_HOST_PRODUCT_LINE.4=embeddedEsx
VDN_HOST_VERSION.4=6.1.*

# Single Version associated with all the VIBs pointed by above VDN_VIB_PATH(s)
VDN_VIB_VERSION=6.2.3.3771501

# Legacy vib location. Used by code to discover avaialble legacy vibs.
LEGACY_VDN_VIB_PATH_FS=/common/em/components/vdn/vibs/legacy/
LEGACY_VDN_VIB_PATH_WEB_ROOT=/bin/vdn/vibs/legacy/

Die VIB-Namen lauten:

  • esx-vsip

  • esx-vxlan

[root@esx-01a:~] esxcli software vib list | grep -e vsip -e vxlan
esx-vsip                       6.0.0-0.0.3771165                     VMware  VMwareCertified   2016-04-20
esx-vxlan                      6.0.0-0.0.3771165                     VMware  VMwareCertified   2016-04-20

Allgemeine Probleme bei der Hostvorbereitung

Bei der Vorbereitung von Hosts können folgende, typische Probleme auftreten:

  • EAM kann keine VIBs bereitstellen.

    • Eine mögliche Ursache ist eine fehlerhafte Konfiguration des DNS auf den Hosts.

    • Eine andere mögliche Ursache ist eine Firewall, die die erforderlichen Ports zwischen ESXi, NSX Manager und vCenter Server blockiert.

  • Ein früheres VIB einer älteren Version ist bereits installiert. In diesem Fall muss der Benutzer die Hosts neu starten.

  • Bei der Kommunikation zwischen NSX Manager und vCenter Server treten Probleme auf:

    • Die Registerkarte Hostvorbereitung (Host Preparation) im Plug-In „Networking and Security“ zeigt einige Hosts nicht korrekt an.

    • Überprüfen Sie, ob mit vCenter Server alle Hosts und Cluster angegeben werden.

Fehlerbehebung bei der Hostvorbereitung (VIBs)

  • Überprüfen Sie den Kommunikationskanalstatus für den Host. Weitere Informationen dazu finden Sie unter Überprüfen des Kommunikationskanalstatus.

  • Überprüfen Sie vSphere ESX Agent Manager auf Fehler.

    vCenter-Startseite > Verwaltung > vCenter Server-Erweiterungen > vSphere ESX Agent Manager (vCenter home > Administration > vCenter Server Extensions > vSphere ESX Agent Manager)

    Überprüfen Sie in vSphere ESX Agent Manager den Status der Agencys mit dem Präfix „VCNS160“. Befindet sich eine Agency in einem ungültigen Status, wählen Sie diese aus und überprüfen Sie die damit verbundenen Probleme.

  • Auf dem Host mit einem aufgetretenen Problem führen Sie den Befehl tail /var/log/esxupdate.log aus.

  • Siehe https://kb.vmware.com/kb/2053782.

Fehlerbehebung bei der Hostvorbereitung (UWA)

NSX Manager konfiguriert zwei Benutzerwelt-Agenten auf allen Hosts in einem Cluster:

  • Nachrichtenbus-UWA (vsfwd)

  • Steuerungskomponente-UWA (netcpa)

In seltenen Fällen kann es vorkommen, dass nach einer erfolgreichen Installation der VIBs ein oder beide Benutzerwelt-Agenten nicht korrekt funktionieren. Dies kann folgende Formen annehmen:

  • Die Firewall zeigt einen ungültigen Status an.

  • Die Steuerungskomponente zwischen Hypervisoren und den Controllern ist inaktiv. Überprüfen Sie die NSX Manager-Systemereignisse.

Ist mehr als ein ESXi-Host betroffen, überprüfen Sie den Status des Nachrichtenbusdienstes in der Web UI der NSX Manager-Appliance in der Registerkarte Übersicht (Summary). Wurde RabbitMQ gestoppt, starten Sie diesen Broker neu.

Wenn der Nachrichtenbusdienst für NSX Manager aktiv ist:

  • Überprüfen Sie durch Ausführung des Befehls /etc/init.d/vShield-Stateful-Firewall status auf den ESXi-Hosts den Status des Benutzerwelt-Agenten des Nachrichtenbusses auf den Hosts.

    [root@esx-01a:~] /etc/init.d/vShield-Stateful-Firewall status
    vShield-Stateful-Firewall is running
    
  • Überprüfen Sie die Protokolle des Benutzerwelt-Nachrichtenbusses auf den Hosts unter /var/log/vsfwd.log.

  • Führen Sie auf den ESXi-Hosts den Befehl esxcfg-advcfg -l | grep Rmq zur Anzeige aller Rmq-Variablen aus. Es müssen 16 Rmq-Variablen vorhanden sein.

    [root@esx-01a:~] esxcfg-advcfg -l | grep Rmq
    /UserVars/RmqIpAddress [String] : Connection info for RMQ Broker
    /UserVars/RmqUsername [String] : RMQ Broker Username
    /UserVars/RmqPassword [String] : RMQ Broker Password
    /UserVars/RmqVHost [String] : RMQ Broker VHost
    /UserVars/RmqVsmRequestQueue [String] : RMQ Broker VSM Request Queue
    /UserVars/RmqPort [String] : RMQ Broker Port
    /UserVars/RmqVsmExchange [String] : RMQ Broker VSM Exchange
    /UserVars/RmqClientPeerName [String] : RMQ Broker Client Peer Name
    /UserVars/RmqHostId [String] : RMQ Broker Client HostId
    /UserVars/RmqHostVer [String] : RMQ Broker Client HostVer
    /UserVars/RmqClientId [String] : RMQ Broker Client Id
    /UserVars/RmqClientToken [String] : RMQ Broker Client Token
    /UserVars/RmqClientRequestQueue [String] : RMQ Broker Client Request Queue
    /UserVars/RmqClientResponseQueue [String] : RMQ Broker Client Response Queue
    /UserVars/RmqClientExchange [String] : RMQ Broker Client Exchange
    /UserVars/RmqSslCertSha1ThumbprintBase64 [String] : RMQ Broker Server Certificate base64 Encoded Sha1 Hash
    
  • Führen Sie auf den ESXi-Hosts den Befehl esxcfg-advcfg -g /UserVars/RmqIpAddress aus. Als Ausgabe sollte die IP-Adresse von NSX Manager angezeigt werden.

    [root@esx-01a:~] esxcfg-advcfg -g /UserVars/RmqIpAddress
    Value of RmqIpAddress is 192.168.110.15
  • Führen Sie auf den ESXi-Hosts den Befehl esxcli network ip connection list | grep 5671 zur Überprüfung aus, ob die Nachrichtenbusverbindung aktiv ist.

    [root@esx-01a:~] esxcli network ip connection list | grep 5671
    tcp         0       0  192.168.110.51:29969            192.168.110.15:5671   ESTABLISHED     35505  newreno  vsfwd
    tcp         0       0  192.168.110.51:29968            192.168.110.15:5671   ESTABLISHED     35505  newreno  vsfwd
    

Um festzustellen, warum der netcpa-Benutzerwelt-Agent inaktiv ist, führen Sie Folgendes durch:

  • Überprüfen Sie durch Ausführung des Befehls /etc/init.d/netcpad status auf den ESXi-Hosts den Status des netcpa-Benutzerwelt-Agenten auf den Hosts.

    [root@esx-01a:~] /etc/init.d/netcpad status
    netCP agent service is running
    
  • Überprüfen Sie die Konfigurationsdatei /etc/vmware/netcpa/config-by-vsm.xml für den netcpa-Benutzerwelt-Agenten. Es müssen die IP-Adressen der NSX Controller aufgeführt sein.

    [root@esx-01a:~] more /etc/vmware/netcpa/config-by-vsm.xml
    <config>
      <connectionList>
        <connection id="0000">
          <port>1234</port>
          <server>192.168.110.31</server>
          <sslEnabled>true</sslEnabled>
          <thumbprint>A5:C6:A2:B2:57:97:36:F0:7C:13:DB:64:9B:86:E6:EF:1A:7E:5C:36</thumbprint>
        </connection>
        <connection id="0001">
          <port>1234</port>
          <server>192.168.110.32</server>
          <sslEnabled>true</sslEnabled>
          <thumbprint>12:E0:25:B2:E0:35:D7:84:90:71:CF:C7:53:97:FD:96:EE:ED:7C:DD</thumbprint>
        </connection>
        <connection id="0002">
          <port>1234</port>
          <server>192.168.110.33</server>
          <sslEnabled>true</sslEnabled>
          <thumbprint>BD:DB:BA:B0:DC:61:AD:94:C6:0F:7E:F5:80:19:44:51:BA:90:2C:8D</thumbprint>
        </connection>
      </connectionList>
     ...
    
  • Führen Sie den Befehl esxcli network ip connection list | grep 1234 zur Überprüfung der Controller-TCP-Verbindungen aus.

    >[root@esx-01a:~] esxcli network ip connection list | grep 1234
    tcp     0   0  192.168.110.51:16594     192.168.110.31:1234   ESTABLISHED     36754  newreno  netcpa-worker
    tcp     0   0  192.168.110.51:46917     192.168.110.33:1234   ESTABLISHED     36754  newreno  netcpa-worker
    tcp     0   0  192.168.110.51:47891     192.168.110.32:1234   ESTABLISHED     36752  newreno  netcpa-worker