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 testées). Le client NUT est désormais intégré et peut être contrôlé et paramétré depuis vSphere Client.

A faire : Rafraîchir cet article avec des captures d’écran de ESXi 7.0. Ce sont encore des captures de ESXi 5.0 !

Mise à jour du 02/05/2022 : La version 2.3.0 inclue la version 2.8.0 du client NUT. Il est rétro compatible avec les serveurs NUT 2.7.x . La librairie libressl passe en version 3.5.2 . Aucune nouvelle fonctionnalité.

Mise à jour du 15/02/2022 : La version 2.2.0 du client NUT apporte une nouvelle fonctionnalité: Pour les système avec plusieurs onduleurs vous pouvez définir le nombre d’onduleurs requis avec assez de d’autonomie avant d’enclencher le shutdown (paramètre MINSUPPLIES du client NUT). Dans les versions précédentes ce nombre était fixé à 1.

Mise à jour du 02/10/2021 : La version 2.1.6 du client NUT est une évolution mineure. Elle n’apporte aucune nouvelle fonctionnalité, elle utilise la librairie libressl 3.3.4. Un « offline bundle » est proposé au téléchargement pour la création d’une ISO personnelle d’installation de ESXi ou sa diffusion par vCenter.

Mise à jour du 18/04/2020 : La version 2.1.0 du client NUT est compatible avec ESXi 7.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ée 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.8.0 (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.8.0-2.3.0.i386.tar.gz – Téléchargé 43667 fois – 788 Ko

Téléchargez ici le bundle pour une installation via vCenter ou la creation d’une ISO d’installation de ESXi

Télécharger “NutClient-ESXi (offline bundle)” NutClient-ESXi-2.8.0-2.3.0-offline_bundle.zip – Téléchargé 1259 fois – 790 Ko

Téléchargez les sources

Télécharger “NutClient-ESXi (sources)” NutClient-ESXi-2.8.0-2.3.0-src.tar.gz – Téléchargé 1849 fois – 24 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.8.0-2.3.0.i386.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.8.0-2.3.0.i386.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.8.0-2.3.0.i386.tar.gz          100%  789KB  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.8.0-2.3.0.i386.tar.gz
/tmp # sh upsmon-install.sh
Installation Result
   Message: Operation finished successfully.
   Reboot Required: false
   VIBs Installed: Margar_bootbank_upsmon_2.8.0-2.3.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
  • UserVars.NutMinSupplies : Pour les systèmes multi onduleurs. Le nombre d’onduleurs qui doivent être en capacité d’alimenter le système avant d’entamer un arrêt. Ce nombre doit être inférieur ou égal au nombre d’onduleurs définis dans UserVars.NutUpsName. Si vous ne respectez pas cette contrainte, le client ne démarrera pas. Avec un seul onduleur, laissez la valeur à 1.

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.

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

  1. Thank you very much for your work.
    Will be possible to add also variable to define MinSupplies (UserVars.NutMinSupplies)? If I’m right, currently it is fixed 1.
    Thank you in advance

    • Hi, I think that this should not be a very big deal to implement. But I have no easy way to test it. Just to remember you that is this is a package I wrote for my own needs because I found nothing existing around. I have several UPSes for my servers but each server has only one UPS. You can already declare several UPSes but MINSUPPLIES parameter in upsmon config is set to its default value : 1.
      For curiosity, which kind of situation needs more than 1 UPS running ? I work with servers using redundant power supplies, they can run as long a one power supply is powered. That’s how redundancy work.

      • Hello, thanks again for your compilation of NUT for vmware. In principle, 1PSU should be enough, but due to the quality of the UPSs, I wanted to start the shutdown after the LowBattery of the first of the two UPSs, as shutting down VMs takes a while and one remaining UPS may not last long enough as the requirements for it double.

  2. Bonjour René!
    Il semble y avoir un enjeu avec la détection de la version pour Lifecycle Manager.
    Je viens de mettre à jour le package dans LM, mis à jour ma ligne d’extension, mais LM considère que mes hôtes sont à jour.

    Tu peux me contacter si tu as besoin d’aider à diagnostiquer.

    Merci pour ton package, ça fait vivre mon laboratoire à la maison 🙂

    • Hélas oui! Je suis au courant du problème et j’y travaille. En ligne de commande esxcli sur l’hyperviseur il détecte bien que c’est une mise à jour mais avec vCenter Lifecycle Manager non. Je me demande si c’est l’encodage du numéro de version (2.7.4-2.2.0) qui le perturbe. J’utilise le même mécanisme à mon travail pour générer des packages mais avec des numéros de versions classiques (au format 1.2.3) et je ne rencontre pas le soucis ni avec vCenter 6.7 Update Manager ni en vCenter 7.0 Lifecycle Manager. Pour l’instant je tente de trouver de la documentation à propos du fichier bulletin.xml qui décrit le bundle mais VMware n’a pas publié grand chose ou alors c’est réservé à leurs partenaires. Ils utilisent des numéros de version bien plus tordus pourtant.

  3. Bonjour. Comment contrôler que la communication est bien établie avec mon UPS ? Les paramètres ont bien été configuré dans mon Esxi 7 et le service est bien démarré. Mon UPS APS avec carte AP9630 a bien le service SNMPv1 activé. Les règles de démarrage et d’arrêt automatique sont bien établies dans ESXI. Malgré cela un test avec épuisement de batterie ne déclenche pas l’arrêt automatique. De plus NutClient n’envoie pas d’émails d’avertissement.
    Merci pour votre aide.

    • Ceci est un client NUT. Il ne sait communiquer qu’avec un serveur NUT et non un SNMP. En revanche un serveur NUT peut comprendre un UPS SNMP. Il faudra donc un serveur NUT entre l’UPS et l’ESXi

  4. Bonjour,
    j’ai installé le client NUT sur mon Esx en suivant votre tuto. Il y a une VM Windows serveur d’installé sur celui-ci mais nous n’avons pas de serveur physique sur le site. Pour information nous avons 10 sites distants à équiper et à configurer.
    Est-il possible d’installer le serveur NUT sur le serveur Windows ou faut-il ajouter un serveur physique ? J’ai vu sur le net qu’on pouvait l’installer sur un Raspberry, pourriez-vous me le confirmer s’il vous plaît ?

    Merci pour votre tuto
    Cordialement,
    Franck

    • Je déconseille d’installer le serveur NUT sur une VM qui est hébergée sur le ESXi qui est client NUT. Personnellement la solution du raspberry pi est de loin la meilleure s’il n’y a rien d’autre de disponible. Un raspberry pi consomme très peu de courant. Pas la peine d’avoir le modèle le plus puissant. Juste vérifier que l’onduleur est bien pris en charge par NUT par un port USB. Le linux raspbian habituellement installé sur ces petites machines dispose du pkg not-server. Il faudra installer aussi nut-client et le configurer pour qu’il s’éteigne aussi lui même proprement en cas de d’alerte de batterie faible sur coupure de courant.

  5. Bonjour,

    Merci pour ce client NUT, ça marche parfaitement !

    J’avais juste une question, serait-il possible d’ajouter une uservar pour personnaliser la SHUTDOWNCMD?

    J’ai modifié les sources mais je ne trouve pas la toolchain pour recompiler le package moi-même

    Merci à vous !
    Alex

    • Bonjour,
      Je n’ajouterai pas ce type de uservar. Ce n’est pas dans l’esprit du module qui convient a la grande majorité des utilisateurs. Pour la compilation j’utilise encore un vieux CentOS 5.11 en 32 bits pour rester compatible avec les anciennes versions de ESXi.

  6. Hello!

    I have this installed but it doesn’t seem to work. The service gets started and is immediately stopped, with logs looking like the following:

    2022-06-03T00:22:49.354Z NUT[548216]: NUT client is not running
    2022-06-03T00:22:49.539Z NUT[548229]: NUT client started
    2022-06-03T00:22:49.635Z NUT[548239]: NUT client is not running

    Any ideas?

    Thanks!

  7. Hello,
    first of all: great work!
    In a lot of cases it is neccesary to configure an internal smtp relay.
    Normally it is no problem to modify your notify.sh, for example:

    /opt/nut/bin/smtpblast -f « ${FROM} » -t « ${TO} » -r « ${SMTPHOST} »
    But due to new security features in ESXi 7 it is not possible to change the file, even if root and 755 rights on the file.

    It would be glad, if you could add the « -r » Prarmeter in the notify.sh and in the Uservars-Section resp. notify.conf!

    • This feature (to send an email) is not mandatory and it uses smtpblast that is a very simple (and old) direct SMTP client. As I want to keep this module as simple as possible it will not match all the needs for everybody. If the mail feature does not work out of the box due to special local network configuration that needs a custom smtp relay you can still download the sources and create your own version of the notify.sh script. You can probably configure your NUT server to send some kind of notification on UPS events. So the answer is : I already know that but I won’t do it. Sorry.

  8. Hi, it’s really a great tool used by many people and has been a standard way to connect UPS to ESXi for past 10+ years. I just recently started the idea to add UPS to my ESXi server and learnt form Google all these. However I can’t find the clue what in particular ESXi doesn’t support so make it ESXi impossible to connect UPS via USB directly, lack of drivers for UART or what? Even though it can passthrough USB to VM for scan. And why ESXI doens’t evolve for such a long time, or it’s just a limitation to free license but always supported on paid license?

    • Thank you, it’s always a pleasure to see that my package is useful for some people. At the beginning I created this package to answer a personal need as VMware was not providing any solution. Now I understand that VMware wants to keep ESXi as small as possible to have the minimum footprint on the host. Compared with other virtualization solutions it’s a success. ESXi has very small overhead and most of the ressources are available for the VMs. To achieve this goal, the ESXi kernel looks like a linux kernel but only the minimum drivers have been implemented. Only low level USB is supported mainly to redirect USB trafic to VMs with passthrough even on paid licences. Same for UARTs. I have not tried recently to compile the server part of NUT to make it run on ESXi because it needs a lot of libraries and dependencies unavailable on ESXi. I could compile all the needed libraries to check if this is possible but when I tried (was ESXi5.0) it was just a nightmare to solve all the dependencies. The client part of Nut is very simple compared with the server. Then understand that this is mainly designed for a standalone,e ESXi server. For a farm managed by vCenter it could be a bit tricky to use the package. There are solutions provided by some UPS manufacturer that can be used for vCenter but globally those solutions eat a lot of resources as they need a dedicated VM to handle UPS events. The goal of my solution was to keep the NUT client as small as possible. Resources are too valuable to waste them.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.