vSphere ESX Agent Manager déploie des VIB sur des hôtes ESXi.

Le déploiement sur les hôtes requiert que le DNS soit configuré sur les hôtes, vCenter Server et NSX Manager. Le déploiement ne nécessite pas un redémarrage de l'hôte ESXi, contrairement aux mises à jour ou aux suppressions de VIB.

Les VIB sont hébergés sur NSX Manager et ils sont également disponibles sous forme de fichier compressé.

Le fichier est accessible à l'adresse https://<NSX-Manager-IP>/bin/vdn/nwfabric.properties. Le fichier compressé téléchargeable diffère selon la version de NSX et d'ESXi. Par exemple, les hôtes vSphere 6.0 utilisent le fichier 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/

Les noms de VIB sont :

  • 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

Problèmes courants lors de la préparation de l'hôte

Lors de la préparation d'hôtes, les problèmes typiques que l'on peut rencontrer sont les suivants :

  • EAM ne réussit pas à déployer des VIB.

    • Peut être dû à un DNS mal configuré sur des hôtes.

    • Peut être dû à un pare-feu bloquant des ports requis entre ESXi, NSX Manager et vCenter Server.

  • Un VIB précédent d'une version antérieure est déjà installé. Cela nécessite que l'utilisateur redémarre les hôtes.

  • NSX Manager et vCenter Server rencontrent des problèmes de communication :

    • L'onglet Préparation de l'hôte (Host Preparation) dans le plug-in Networking and Security n'affiche pas tous les hôtes correctement.

    • Vérifiez si vCenter Server peut énumérer tous les hôtes et les clusters.

Dépannage de la préparation de l'hôte (VIB)

  • Vérifiez la santé du canal de communication pour l'hôte. Reportez-vous à la section Vérification de la santé du canal de communication.

  • Recherchez des erreurs sur vSphere ESX Agent Manager.

    Accueil de vCenter > Administration > Extensions de vCenter Server > vSphere ESX Agent Manager (vCenter home > Administration > vCenter Server Extensions > vSphere ESX Agent Manager)

    Sur vSphere ESX Agent Manager, vérifiez l'état des agences avec le préfixe « VCNS160 ». Si l'état d'une agence est incorrect, sélectionnez l'agence et affichez ses problèmes.

  • Sur l'hôte qui a un problème, exécutez la commande tail /var/log/esxupdate.log.

  • Reportez-vous à la section https://kb.vmware.com/kb/2053782.

Dépannage de la préparation de l'hôte (UWA)

NSX Manager configure deux agents UWA (User World Agent) sur tous les hôtes d'un cluster :

  • Agent UWA du bus de messages (vsfwd)

  • Agent UWA du plan de contrôle (netcpa)

Dans de rares cas, l'installation des VIB réussit, mais, pour une raison quelconque, un agent UWA, ou les deux, ne fonctionne pas correctement. Cela pourrait se traduire par :

  • Le pare-feu indiquant un état incorrect.

  • Le plan de contrôle entre les hyperviseurs et les contrôleurs étant inactif. Consultez les événements système de NSX Manager.

Si plusieurs hôtes ESXi sont affectés, vérifiez l'état du service de bus de messages sur l'interface utilisateur Web du dispositif NSX Manager dans l'onglet Résumé (Summary). Si RabbitMQ est arrêté, redémarrez-le.

Si le service de bus de messages est actif sur NSX Manager :

  • Vérifiez l'état de l'agent UWA du bus de messages sur les hôtes en exécutant la commande /etc/init.d/vShield-Stateful-Firewall status sur les hôtes ESXi.

    [root@esx-01a:~] /etc/init.d/vShield-Stateful-Firewall status
    vShield-Stateful-Firewall is running
    
  • Consultez les journaux de l'agent UWA du bus de messages sur les hôtes à l'emplacement /var/log/vsfwd.log.

  • Exécutez la commande esxcfg-advcfg -l | grep Rmq sur les hôtes ESXi pour afficher toutes les variables Rmq. Il devrait y avoir 16 variables Rmq.

    [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
    
  • Exécutez la commande esxcfg-advcfg -g /UserVars/RmqIpAddress sur les hôtes ESXi. La sortie doit afficher l'adresse IP de NSX Manager.

    [root@esx-01a:~] esxcfg-advcfg -g /UserVars/RmqIpAddress
    Value of RmqIpAddress is 192.168.110.15
  • Exécutez la commande esxcli network ip connection list | grep 5671 sur les hôtes ESXi pour rechercher une connexion du bus de messages active.

    [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
    

Pour déterminer la raison pour laquelle l'agent UWA netcpa est inactif :

  • Vérifiez l'état de l'agent UWA netcpa sur les hôtes en exécutant la commande /etc/init.d/netcpad status sur les hôtes ESXi.

    [root@esx-01a:~] /etc/init.d/netcpad status
    netCP agent service is running
    
  • Consultez les configurations d'agent UWA netcpa /etc/vmware/netcpa/config-by-vsm.xml. Les adresses IP des instances de NSX Controller devraient apparaître.

    [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>
     ...
    
  • Exécutez la commande esxcli network ip connection list | grep 1234 pour vérifier les connexions TCP du contrôleur.

    >[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