Client NUT pour ESXi 5, 6 et 7

Dans un précédent article je vous présentait un client NUT natif pour éteindre automatiquement un serveur VMWare ESXi 4 sur une alerte onduleur. La solution présentée n’était pas compatible avec ESXi 5 dont l’architecture logicielle a évoluée. Voici une solution pour intégrer un client NUT natif à vSphere Hypervisor  (ESXi 5.0, 5.1, 5.5, 6.0, 6.5, 6.7, 7.0.0 testées). Le client NUT est désormais intégré et peut être contrôlé et paramétré depuis vSphere Client.

Mise à jour du 18/04/2020 : La version 2.1.0 du client NUT est compatible avec ESXi 7.0.0, son fonctionnement reste inchangé.

Mise à jour du 26/05/2019 : La version 2.1.0 du client NUT s’installe correctement dans une intégration ISO personnalisée de ESXi 6.x

Mise à jour du 29/01/2017 : La version 2.0 du client NUT a été largement repensé pour mieux s’intégrer dans l’architecture VMware ESXi. Les modifications suivantes ont été apportées :

  • Le client s’appelle désormais NutClient dans la liste des services
  • Les règles de firewall portent le nom de NutServer
  • Le fichier VIB respecte le standard CommunitySupported pour les versions 6.x de ESXi. Pour les versions 5.x il faudra toujours forcer l’installation avec l’option –no-sig-check
  • Le VIB est indépendant, il n’est plus nécessaire d’utiliser les scripts d’installation pour déployer le VIB. Vous pouvez utiliser les outils de déploiement de VMWare. Les scripts servaient à créer les variables UserVars.Nut* c’est désormais intégré dans le VIB.
  • Le client prend en charge les connexions SSL en utilisant la librairie LibreSSL 2.5.0 mais la validité du certificat du serveur NUT n’est pas contrôlé.
  • L’état du service est désormais correctement remonté dans l’interface d’administration vCenter ou le client HTML après un reboot de l’hyperviseur
  • Si les variables de configuration n’apparaissent pas dans l’interface d’administration après l’installation, lancez la commande /etc/init.d/hostd restart sur l’hyperviseur. Attention à ne pas avoir de jobs en cours si vous faites ça (prise de snapshot, VMotion, …).

Principe

La procédure consiste à installer dans l’hyperviseur les binaires et scripts nécessaires à la réception des alertes onduleur. Je reprend le schéma des connexions qui ne change pas.

Câblage Onduleur

Câblage Onduleur

Cette solution n’est pas officiellement supportée par VMWare et elle ne s’applique qu’à des hyperviseurs standalone. Elle ne peut pas convenir pour des fermes d’hyperviseurs sous le contrôle d’un VMWare vCenter. Seul le client NUT est ajouté à l’hyperviseur, l’onduleur doit être surveillé par un serveur NUT.

Évolutions par rapport à ESXi 4

Les différences qui font que la solution pour ESXi 4 ne fonctionne pas sous ESXi 5 :

  • La méthode d’installation utilise un fichier VIB (vSphere Installation Bundle). Les binaires qu’il contient correspondent à un client nut 2.7.4 (upsmon et upsc)
  • Dans /etc/passwd, l’utilisateur nobody n’existe plus. Le client tourne désormais avec le compte daemon.
  • Le module VIB ne respecte pas les préconisations de sécurité imposées par VMWare. Vous perdez le support de VMWare en installant ce package. Je bricole pour mes besoins personnels en utilisant une licence gratuite de ESXi sans support, j’ai donc ignoré cette restriction.

Téléchargement du module

L’installation se fait en ligne de commande sur l’hyperviseur : un fichier TAR compressé doit être déposé sur l’hyperviseur.

Téléchargez ici le fichier

Télécharger “NutClient-ESXi (binaires)” NutClient-ESXi-2.1.1.i386.tar.gz – Téléchargé 32323 fois – 856 Ko

Téléchargez les sources

Télécharger “NutClient-ESXi (sources)” NutClient-ESXi-2.1.1-src.tar.gz – Téléchargé 780 fois – 21 Ko

Installation

Activez l’accès ssh à votre host ESXi si ce n’est pas déjà fait. Cela est fait à partir du client vSphere ou de la console. A partir du client : dans l’inventaire choisissez votre hôte ESXi, onglet configuration, dans la liste Logiciel choisir profil de sécurité, dans services cliquez sur propriétés…, choisissez SSH puis options et enfin démarrer. Le service ssh sera actif jusqu’au prochain reboot de l’hyperviseur si vous ne le désactivez pas.

Copiez le fichier NutClient-ESXi-2.0.0.tar.gz dans le répertoire /tmp du host ESXi. Ici je vous  donne l’exemple  depuis une machine linux (remplacez 10.0.0.8 par l’adresse IP du host ESXi ou son nom FQDN). Depuis Windows vous pouvez utiliser l’outil gratuit WinSCP.

[root@linux ~]# scp NutClient-ESXi-2.1.0.tar.gz root@10.0.0.8:/tmp
The authenticity of host '10.0.0.8 (10.0.0.8)' can't be established.
RSA key fingerprint is 89:49:ce:6d:... ...:40:76:7a:4a:fe.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.0.8' (RSA) to the list of known hosts.
Password: (saisir le mot de passe administrateur ESXi)
NutClient-ESXi-2.1.0.tar.gz          100%  671KB  1.9MB/s   00:00

Passez votre hyperviseur au niveau d’acceptance Communauté si ce n’est pas déjà fait !

Connectez-vous root en ssh à l’hôte ESXi et tapez la suite de commandes suivantes pour installer le VIB (l’opération peu être longue si votre système est installé sur une clé USB lente) :

~ # cd /tmp
/tmp # tar -xzf NutClient-ESXi-2.1.0.tar.gz
/tmp # sh upsmon-install.sh
Installation Result
   Message: Operation finished successfully.
   Reboot Required: false
   VIBs Installed: Margar_bootbank_upsmon_2.7.4-2.1.0
   VIBs Removed:
   VIBs Skipped:

Vous n’avez pas besoin de rebooter pour commencer à utiliser le client NUT sur votre système. Vous devez toutefois le configurer avant son premier lancement.

Vous pouvez supprimer les fichier qui ont été créés dans /tmp et désactiver le service SSH

Configuration

A l’aide de vSphere Client, rendez-vous dans l’onglet configuration de l’hôte ESXi. Sélectionnez les paramètres avancés et sélectionnez les UserVars. Vous avez 6 variables à configurer :

Configuration du client NUT sous ESXi 5

Configuration du client NUT sous ESXi 5

  • UserVars.NutUpsName : Nom de l’onduleur sur le serveur NUT (sous la forme nom_onduleur@nom_ou_ip_serveur). Plusieurs onduleurs peuvent être saisis séparés par un espace. Il n’y aura pas d’arrêt système tant que le dernier onduleur encore debout n’aura pas donné l’ordre d’arrêt.
  • UserVars.NutUser : Nom du compte de connexion au serveur NUT
  • UserVars.NutPassword : Mot de passe du compte de connexion au serveur NUT
  • UserVars.NutFinalDelay : Secondes qu’il faudra attendre après la réception de l’événement batterie faible pour procéder à l’arrêt du système
  • UserVars.NutSendMail : A mettre à 1 pour que le client NUT envoie un e-mail à chaque évènement important de l’onduleur
  • UserVars.NutMailTo   : Adresse e-mail à laquelle envoyer les évènements de l’onduleur

Notez qu’à chaque modification de ces paramètres il sera nécessaire de faire un arrêt/relance du service pour leur prise en compte.

Lancement du service

A l’aide de vSphere Client, rendez-vous dans l’onglet configuration de l’hôte ESXi. Sélectionnez les profils de sécurité et les propriétés des services :

Services-ESXi5

Client NUT dans les services ESXi 5

Dans les options du service Network UPS Tools Client, choisissez le mode de démarrage (Démarrer et arrêter avec l’hôte me semble un bon choix). Vous pouvez également le démarrer immédiatement ou l’arrêter.

NutClientService-ESXi5

Configuration du lancement de NUT Client

Astuces

Utilisez l’onglet de configuration du host ESXi dans vSphere Client pour décider de l’ordre de démarrage et d’arrêt (ou suspension) des machines virtuelles. Cet ordre sera respecté par la procédure d’arrêt sur alerte onduleur.

L’arrêt propre des OS dans les machines virtuelles n’est possible que si les vmware tools sont installées.

Pour désinstaller le client NUT, utilisez le script upsmon-remove qui se trouve dans le fichier que vous avez téléchargé :

/tmp # sh upsmon-remove

Pour estimer le temps nécessaire au serveur pour s’éteindre sur alerte onduleur tapez la commande « /opt/nut/sbin/upsmon -c fsd » sur le host ESXi (par ssh ou sur la console). La procédure d’arrêt est immédiatement lancée.

500 réflexions sur « Client NUT pour ESXi 5, 6 et 7 »

  1. Hi,

    Is there a way to test if the client is seeing the master correctlty? I want to to a plug test, but want to verify if all communication is working first.

    Thank you for your hard work on this.

    • First you can check in the system log file for error messages. Just grep upsmon in /var/log/syslog.log in ESXi shell. If everything is OK you should get :
      2020-07-27T08:05:43Z upsmon[36384643]: Startup successful
      2020-07-27T08:05:43Z upsmon[36384643]: Warning: running as one big root process by request (upsmon -p)

      If you have wrong parameters or network settings you will have error messages :
      2020-07-27T08:05:43Z upsmon[36384643]: UPS [myups@mywrongserver]: connect failed: No such host
      2020-07-27T08:05:43Z upsmon[36384643]: Communications with UPS myups@mywrongserver lost
      2020-07-27T08:05:48Z upsmon[36384643]: UPS [myups@mywrongserver]: connect failed: No such host
      2020-07-27T08:05:53Z upsmon[36384643]: UPS [myups@mywrongserver]: connect failed: No such host
      ...

      Then you can check thet the client is able to read the server : on ESXi shell execute /opt/nut/bin/upsc upsname@upsserver (replace this last by your config names). This should give you the attributes of your UPS.

      • I was able to see the UPS data, and did a plug test and all went smoothly. Windows events show clean shutdown.

        One more question. Is there a way to configure the client to shut down on a ‘OB’ event instead of a ‘OB + LB’ event?

        I have multiple ESXi hosts, and want to do a staggered shutdown to keep critical infrastructure on the longest, while shutting down the non-critical infra first.

        Thanks Again!

        • I don’t understand why so many people are asking me to shutdown when UPS goes ont battery. If you have a 1 second power cut it will shutdown everything even is the battery has been able to hide the power loss. Your UPS will also enter ONBATT if the input voltage is out of a configurable range, this is not a power loss. Here is what I already wrote in a previous comment :
          You need to understand how NUT works. First, on power loss, the NUT server will send to NUT clients (ESXi) a ONBATT event to tell that the power is now from the UPS battery. Then, at a configurable % value of remaining time or battery charge, the NUT server will send a LOWBATT event to clients. This is to inform the clients it is time to start a SHUTDOWN. The threshold level to send the LOWBATT event depends on the UPS. Some can be configured using the upsrw tool on the NUT server. On your uspc output command you can see this value named battery.runtime.low (if UPS calculates the remaining runtime depending on the charge, mostly high-end UPSes) or battery.charge.low (if UPS only know about the battery charge and you have to estimate the remaining runtime before complete power loss).

          If power is back before the reaching this low level. The server will send the ONLINE event and no shutdown will be started. Command upsrw on server is part of NUT project, you should consider reading the NUT documentation.

          • For the staging shutdown of several ESXi, this is not doable with the current VIB NUT client as each ESXi is not aware of the others. Maybe possible with multiple NUT server configurations but this is a NUT project question and I can’t answer for them.

          • Great info, Rene
            What would happen if everything is shutdown (after LoBat) and the power comes back on ? You said ONLINE is send out but what if everything is already shutdown?

          • In this particuliar case where, no luck, the power comes up again after sending the LOWBATT event, the shutdown has already started. The rule is to continue shutdown for all the NUT clients and also for the NUT server. At the end, just before the NUT server goes off, it has to send the POWERKILL message to the UPS to tell that everything has been shut down. The UPS should then electrically stop powering all the machines connected to it and then bring the power on again after a configurable delay (a real power cycle). There are 2 parameters usually for that: ups.delay.shutdown which gives how many seconds to wait to power off the UPS output sockets when the server sends the powerkill event. And ups.delay.start, the minimum time to wait in seconds to bring the power back. Some UPSes have even a parameter to prevent to restart if the battery is too low and servers will be unable to boot and shutdown properly in case of a second power disaster (batery.charge.restart is minimum % battery level on APC). Then, when the power is back the hosts should be configured to auto start in their BIOS configuration.

  2. Bonjour René,
    Tout d’abord merci beaucoup pour ce super boulot 🙂

    J’ai le même problème que Bedard, impossible de télécharger le fichier 🙁 Retour direct sur la page d’accueil du blog.

  3. I installed everything on the latest vSphere 7 environment and all went smoothly but at the end on the ESXi command line I just cannot execute the « upsc » command because it is missing. It’s just giving me the following output:

    « -sh: upsc: not found »

    I was looking inside « /opt/nut/sbin » but there is only the « upsmon » command. Did something change about the « upsc » command? Where is the location of « upsc » supposed to be on ESXi’s file system?

      • Thanks, that worked. Another question: I mentioned I can configure an E-Mail notification by UserVars. But where can I configure the according SMTP server settings? Or does it take a default SMTP server to send mails? If yes, which one?

          • Sorry, I don’t get it. Somewhere I have to put my user credentials for SMTP server setting so the ESXi will be able to send mails.

        • There is no SMTP credentials. The SMTP client embedded in the ViB is not that smart. It’s a very simple and straightforward tool called smtpblast. It will assume that the destination SMTP server can be accessed and will allow mail delivery to mailbox with no credential.

          • OK, got it now. So just for testing I tried to execute the smtpblast as described here:

            https://www.linuxcertif.com/man/1/smtpblast/

            Like this in my case:

            ./smtpblast -r « mySMTPServer.myDomain.com » -p « 2500 » -f «  » -t « foo@bar.com »

            but the connection times out everytime. Firewall on SMTP server side and on ESXi side is temporarly disabled for troubleshooting purposes.
            The SMTP server is working as I am using it for a lot of other SMTP clients.

            Don’t know what is wrong. Am I missing something?

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *