Client NUT pour ESXi 5, 6, 7 et 8

Publié le par

Dans le but de pouvoir stopper proprement un hyperviseur VMware et ses machines virtuelles en cas d’alerte onduleur, voici une solution pour intégrer un client NUT (Network UPS Tools) natif à vSphere Hypervisor (ESXi 5.0, 5.1, 5.5, 6.0, 6.5, 6.7, 7.0, 8.0 testés). Le client NUT est installé dans l’hyperviseur et peut être contrôlé et paramétré depuis l’interface de configuration de ESXi ou depuis le vCenter s’il est géré.

Réflexion du 30/05/2024 : Broadcom a racheté VMware et a fait un grand ménage dans les formules commerciales. La plus impactante pour ce projet est l’arrêt des licences gratuites pour ESXi. Aujourd’hui les versions 7 et 8 sont celles qui continuaient d’être activement supportées par VMware. Aussi longtemps que je serai en mesure d’exécuter ESXi dans mon lab je continuerai de mettre à jour le client NUT pour ESXi.

Mise en garde 01/11/2023 : Sous ESXi 8.0 et à partir de la version 2.5.0 du client Nut, dans l’interface client HTML, vous ne verrez pas les descriptions associées aux UserVars du client NUT à jour tant que le host ESXi n’aura pas rebooté.

Mise à jour du 19/10/2022 : ESXi 8.0 est sorti ce 11/10/2022, seules les versions du module avec un numéro de version supérieur à 2.3.2 pourront s’installer sur cette nouvelle version de ESXi (abandon du support des binaires 32-bits et checksum SHA256 requis dans la signature du module).

Principe

La procédure consiste à installer dans l’hyperviseur les binaires et scripts nécessaires à la réception des alertes onduleur. Le schéma classique minimal des connexions entre les éléments d’un réseau électrique protégé par un onduleur est le suivant :

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 en cluster de haute disponibilité sous le contrôle d’un vCenter. Seul le client NUT est ajouté à l’hyperviseur, l’onduleur doit être surveillé par un serveur NUT indépendant.

Caractéristiques et fonctionnalités

  • La méthode d’installation utilise un fichier VIB (vSphere Installation Bundle). Il n’y a rien d’autre ce qui permet une installation rapide et sûre et une désinstallation propre en utilisant les standards de VMware.
  • La compatibilité du module a été assurée pour qu’il fonctionne sur toutes les versions de ESXi entre 5.0 et 8.0. Cependant pour les versions 5.x l’installation automatique par déploiement de ViB n’est pas possible, il faut l’installer manuellement en suivant les instructions ci-dessous et passer outre les avertissements de sécurité. A partir de la version 6.0 de ESXi il n’y a plus ce soucis.
  • C’est un client NUT 2.8.1 qui est inclus dans le paquetage. Il peut se connecter aux serveurs avec une version plus ancienne (disons 2.6.4 mais je n’ai pas testé les serveurs plus anciens).
  • Actuellement seule la version pour processeur x86 est disponible. Il n’y a pas de version pour ESXi ARM (je n’ai ni le besoin ni la plateforme de test/développement pour ça).
  • Le client (secondary dans la terminologie NUT) peut se connecter au serveur (primary) en privilégiant une connexion SSL/TLS si elle est disponible. Il ne sera pas fait de vérification de validité de certificat serveur et il n’y a pas de certificat client configurable.
  • Le client peut envoyer un mail très succinct à une adresse configurable lors de la réception d’un évènement onduleur (perte du secteur, batterie faible, engagement de l’arrêt, retour du secteur). L’outil mail est très simple et il récupère les informations pour l’envoi des messages du DNS (enregistrements MX). Vous pouvez aussi utiliser un relais SMTP personnel.
  • Le client peut se connecter à plusieurs serveurs NUT s’il y a plusieurs onduleurs (cas des serveurs avec une redondance d’alimentation). Il utilisera le même compte et le même mot de passe pour se connecter aux différents serveurs NUT. A vous de déclarer ce compte sur tous les serveurs NUT.
  • Normalement il est possible de préciser le port TCP de connexion au serveur NUT sous la forme onduleur@serveur:port mais ESXi impose des règles de firewall pour le trafic sortant et seul le port 3493 est autorisé. C’est le port par défaut des serveurs NUT.
  • Il est possible de demander l’arrêt du système ESXi après un laps de temps sur batterie configurable. Le client reste à l’écoute de l’évènement batterie faible et le système entamera sa procédure d’arrêt soit après le temps imparti soit sur évènement de batterie faible, au premier des deux qui surviendra quand le système est sur batterie. L’attente est interrompue si le courant secteur est rétabli entre temps, mais si la procédure d’arrêt a déjà été initiée, elle ira jusqu’à l’extinction du host ESXi.
  • Le redémarrage du serveur après une coupure de courant est aussi une phase importante mais c’est à vous de le prévoir avec d’autres outils. Personnellement (mais ce n’est qu’une suggestion) j’aime bien l’idée d’un chef d’orchestre qui redémarre automatiquement. Il surveille le retour des services tels que le réseau, le serveur NUT etc… et il envoie des trames WOL pour réveiller les machines dans l’ordre désiré. Configurez votre serveur NUT pour qu’il ordonne à l’onduleur de couper effectivement le courant pendant un petit laps de temps même si le courant est revenu pendant la procédure d’arrêt. La plupart des onduleurs ont cette fonction avec les libellés « Interval to wait after shutdown with delay command » et « Interval to wait before (re)starting the load ». Certains onduleurs ont aussi une valeur « Minimum battery level for restart after power off » qui est interessante pour attendre que l’onduleur ait suffisamment rechargé ses batteries avant de faire redémarrer le système. Le risque est de se retourner dans une situation où un second arrêt propre serait impossible si une nouvelle coupure de secteur se produit juste après le redémarrage (ce qui est plutôt fréquent).
  • Le client tourne avec le compte root. C’est habituellement déconseillé par la documentation du projet NUT mais l’hyperviseur a un nombre très limité de comptes locaux. Ce nombre de compte s’est beaucoup réduit au fil des versions. Des comptes restants, root est le seul encore utilisable.

Téléchargement du module

Pour toutes les versions de ESXi, l’installation peut se faire 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.2-2.6.2.x86_64.tar.gz – 821,90 Ko

A partir de ESXi 6.0 vous pouvez utiliser le bundle offline pour une installation en ligne de commande en appelant la commande « esxcli software vib install -d » . Ou par le manager de mises à jour du vCenter si vous en avez un.

Téléchargez ici le bundle offline.
Télécharger “NutClient-ESXi (offline bundle)” NutClient-ESXi-2.8.2-2.6.2-offline_bundle.zip – 823,83 Ko

Vous pouvez créer votre propre package personnalisé à partir des sources. Elles sont distribuées sous licence GPLv3 (GNU Public License version 3). Utilisez un environnement de développement linux 64 bits tel que CentOS 7 avec les outils de compilation et développement C habituels. Un fichier INSTALL décrit la procédure. Les sources sont disponibles également dans un dépot git publique : NutClient-ESXi

Téléchargez ici les sources
Télécharger “NutClient-ESXi (sources)” NutClient-ESXi-2.8.2-2.6.2-src.tar.gz – 121,64 Ko

Installation

Activez l’accès ssh à votre host ESXi si ce n’est pas déjà fait. Cela est fait à partir de l’interface d’administration ESXi ou de la console DCUI. A partir de l’interface d’administration : dans la rubrique gérer de votre hôte, onglet services, dans la liste sélectionnez TSM-SSH et démarrez le service. Le service ssh sera actif jusqu’au prochain reboot de l’hyperviseur ou pendant un temps limité selon la version de votre ESXi.

Copiez le fichier NutClient-ESXi-2.8.2-2.6.2.x86_64.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.2-2.6.2.x86_64.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.2-2.6.2.x86_64.tar.gz          100%  869KB  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.2-2.6.2.x86_64.tar.gz
/tmp # sh upsmon-install.sh
Installation Result
   Message: Operation finished successfully.
   Reboot Required: false
   VIBs Installed: Margar_bootbank_upsmon_2.8.2-2.6.2
   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 fichiers qui ont été créés dans /tmp et désactiver le service SSH

Configuration

A l’aide de l’interface d’administration du ESXi, rendez-vous dans la rubrique gérer de l’hôte. Sélectionnez les paramètres avancés de l’onglet Système et filtrez la liste sur UserVars.Nut, vous avez 8 variables à configurer :

ESXi7-NutParam

Configuration du client NUT sous ESXi7

  • 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.NutOnBatteryDelay : Délai en secondes après le début du passage sur batterie de l’onduleur pour stopper le système. Si la valeur est 0 alors le client NUT attendra l’évènement batterie faible pour stopper le système. La valeur par défaut est 0, c’est le fonctionnement normal pour garder le système en fonctionnement le plus longtemps possible. Si l’onduleur repasse sur secteur avant la fin du délai, le système ne sera pas stoppé.
  • UserVars.NutSendMail : A mettre à 1 pour que le client NUT envoie un e-mail à chaque évènement important de l’onduleur. La valeur 2 permet d’avoir dans le mail l’état des l’onduleurs lors de l’évènement.
  • UsersVars.NutSmtpRelay : Nom ou IP d’un relai SMTP pour y faire transiter le mail. Laisser vide ou saisissez none pour ne pas utiliser de relai (none par défaut).
  • 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 l’interface d’administration du ESXi, rendez-vous dans la rubrique gérer de l’hôte. Sélectionnez l’onglet Services, trouvez et sélectionnez le service NutClient dans la liste:

Services-ESXi7

Client NUT dans les services ESXi7

Dans les actions du service, choisissez la stratégie 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-ESXi7

Configuration du lancement de NUT Client

Astuces

Utilisez la rubrique démarrage automatique de l’onglet Système de l’hôte ESXi 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. Un bug de ESXi fait que les valeurs par défaut ne sont pas respectées. Vous devez configurer ces paramètre pour chaque VM au moins une fois (quitte à la dé-configurer ce qui la fera réellement suivre les règles par défaut).

Important : L’arrêt propre des OS dans les machines virtuelles n’est possible que si les vmware tools sont installées. Sinon l’arrêt sera brutal, préférez alors une suspension dans la configuration d’arrêt de la VM.

Là encore je rappelle que cette solution n’est pas adaptées aux fermes cluster avec haute disponibilité. Si HA est activé sur la machine hôte le mécanisme d’arrêt propre des VM n’est plus respecté et l’arrêt sera brutal pour toutes les VM.

UEFI secure boot

Si votre hôte ESXi est configuré pour booter en mode UEFI secure boot, l’installation du ViB restera compatible avec cette configuration. En revanche vous ne pouvez pas descendre le niveau d’acceptation à CommunitySupported quand secure boot est activé. Vous devrez :

  • rebooter pour aller dans les paramètres UEFI de votre carte mère
  • désactiver le secure boot dans les paramètres UEFI de votre carte-mère
  • booter (sans secure boot)
  • descendre le niveau d’acceptation à CommunitySupported
  • Rebooter une seconde fois pour retourner dans les paramètres UEFI
  • réactiver le secure boot
  • booter (avec secure boot).

Vous aurez secure boot actif et le niveau d’acceptation minimal à CommunitySupported.

Désinstallation

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

Test

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 (ne faites pas ça si vous n’aviez pas prévu d’arrêter votre machine).

Articles similaires:

  1. Client NUT natif pour VMWare ESXi 4
  2. Arrêt d’un VMWare ESXi sur alerte onduleur
  3. Passer des informations de l’hyperviseur ESXi à une VM et inversement
  4. Réduire la consommation CPU d’une machine virtuelle sous VMWare
  5. Administrez votre infrastructure VMware depuis votre mobile

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

  1. Thank you for the quick response and sorry for my delayed reply.
    I tried it, but unfortunately with the same result:

    [root@localhost:/tmp] ls
    NutClient-ESXi-2.8.0-2.3.2-offline_bundle.zip
    vmware-root
    wbem-vm-report.xml

    [root@localhost:/tmp] esxcli software vib install -d /tmp/NutClient-ESXi-2.8.0-2.3.2-offline_bundle.zip
    [KeyError]
    « filename ‘var/db/payloads/boot_loader_efi/BOOTx64.EFI’ not found »

    Acceptance level is set to community.

    Répondre ↓

    • Some questions to understand: how was installed ESXi? Does your system use UEFI boot or legacy BIOS boot? Have you ever been able to update/patch your ESXi? What is the build version number of you system?

      Répondre ↓

  2. The server has been running unchanged since it went live in 07/2021…
    In the documentation for the server I find installation type: UEFI.

    Clientversion: 1.34.8
    Client-Build-Nummer: 17417756
    ESXi-Version: 7.0.2
    ESXi-Build-Nummer: 17867351

    Répondre ↓

      • Thank you for the note and the link.
        With this I was able to solve the problem and successfully install the client.
        I also like the new option to shut down the server after a fixed period of time.

        Elsewhere you mentioned a « NUT manual ».
        Did I miss something, or do you mean your blog?

        I am happy about the client, your support and appreciate your work and time.
        How can I say thank you and support your work?

        Do you have an IBAN I can transfer to?

        Best regards
        Martin

        Répondre ↓

        • The NUT manual is on the official NUT site. I am only compiling and packaging the client without modifying it. The shutdown after a fixed amount of time on battery is not a client feature. It is done by an external script I wrote. Called by the upsmon binary. This package is free and I started doing it 10 years ago for my own needs on my personal ESXi server (was ESXi 5). I am just sharing it as it seems that it can be helpful for other people. I am supporting it on my spare time and it does not take me too much time. Do you really want to pay for it? Telling me that it is useful for you makes me happy. Sometimes I would like to know about the use cases. I don’t know if anyone is using it on managed servers (using vCenter and an HA cluster, maybe vSan also). As this package is not signed it’s a risk to loose part of VMware support. I work and I am in contact with WMware but I have never told them about this package. Thank you Martin.

          Répondre ↓

          • The reason for my ESXi server was that the NetWare 4.11 server started to cause problems. I was able to virtualize it with kind support.

            So I can still use our old ERP system that we programmed many years ago with dBASE. Admittedly, there is also some nostalgia involved.
            That’s how I got to know and appreciate VMware.
            All beginnings are difficult.
            I really liked that your block is understandable even for beginners.
            This enabled me to achieve my goal of cleanly shutting down the server in the event of a power failure.
            I could have gotten that somewhere else for money.
            It is not a matter of course if you make the effort and help.

            So thank you very much!
            Martin

          • I understand that virtualization makes possible to run old software on new hardware. For a clean shutdown with you UPS you need the VMware-tools to be installed on your operating system. VMware-Tools for Novell Netware are no longer maintained but they can still be downloaded from VMware as legacy software and should work. If you can’t install the VMware tools consider suspending the VM instead of shutting it down in the auto start/stop VM configuration of the ESXi host.

  3. Thanks for this great article and client!

    I’ve just installed on ESXi 7u3 (free version) and I don’t think it didn’t shut down after 5 seconds. I unplugged the UPS for about a minute and plugged it in, but when I logged back in to ESXi it was still running as were the VMs.

    My UPS is faulty and only lasts about 5 minutes so I want ESXi to shut down as soon as possible..

    What is the best way to debug? Is there somewhere in the logs I can check if the client is properly communicating with the server and if it received the on battery power signal?

    Merci!

    Répondre ↓

    • Hi Juan. You should read the NUT manual to understand how it works. It will start the shutdown process only when the nut server sends the event “low battery”. If you unplug the UPS and plug it again before the UPS battery ran low it will not send this event. Then if your UPS is faulty (batteries too old?) and is unable to have an accurate status of the remaining battery charge it may not sent the event. This is not an NUT issue, you need to replace the batteries or the UPS. The final delay is only a laps of time the NUT client will spend before starting the power off command when the shutdown event is received.

      Répondre ↓

      • Yes, unfortunately my batteries are old.
        Thanks for the clarification. I saw that on the windows NUT client you can specify the battery % as the trigger and wasn’t sure if this was supported.
        I’ll do another test and let it run lower and see if it works.
        How can I test the connectivity/logs to make sure everything is working well?

        Répondre ↓

        • The battery % is usually a UPS configurable parameter. It can sometimes be configured on the NUT server but not on the NUT client that is not directly connected to the UPS. The client is very stupid and only follows the orders received from the server.

          Répondre ↓

  4. Hi, i’m testing the package and is working but i have a necessity: shutdown my host x minutes after the ups goes from online to battery instead of x minutes when the ups is low on battery.

    There is a version with this modification? Thanks

    Répondre ↓

    • Hi. None of my versions have this feature. I think that m this is not possible with only upsmon configuration. You are not the first one to ask for this. Maybe I will take a look.

      Répondre ↓

        • On new version 2.4.0, you can now set UserVars.NutOnBatteryDelay to shutdown the system x seconds after UPS goes on battery. Set it to 0 to keep previous behavior. If UPS goes on low battery then ESXi will shutdown before the end of the delay. If the UPS goes online, the delay will be aborted and system will not shutdown.

          Répondre ↓

          • Hi. I tested UserVars.NutOnBatteryDelay on ESXi 8.0.0. and it works great except it doesn’t honor UserVars.NutMinSupplies. If I have 2 UPS systems, I expected NUT client to wait until both UPS are on battery. Instead it triggered shutdown when first UPS went on battery while the other was online. Is it possible to change this behavior?

          • Now I realise that I haven’t tested this situation. Maybe I would not have created the feature if this was a problem. Shutdown on delay is not handled bu the NUT client but by an external script. I will take a look but don’t expect a fix soon.

          • Maybe create an uservar and inside it an array whit a specified time one for each ups.
            The feature that you added in my opinion is a must have and I would like that this option will stay in the future releases

          • I have made a quick analysis of the problem and it looks much simplier than I though at the first glance. I have all the information to check that the Delay has to be started only if we have less than the min supplies UPSes still online. So now I think this will be fixed sooner than expected. It will take me much more time to test the solution than to code it.

          • upsc is a command, not a directory. You have to type :
            /opt/nut/bin/upsc ups_name@nut_server
            (replace ups_name@nut_server with your values)

            You should get a list of attribute/value pairs. I would like to know what’s the value of ups.status attribute. The exact line with spaces, etc…

          • OL is correct. It stands for On Line (OB = On Battery, LB = Low Battery). When this value changes it creates an event the server sends to the clients. You are using the same UPS as I am using : APC SmartUPS 3000. I was not able to reproduce your issue. When the power is back before the end of the delay, the delay process is killed. It is a single UPS configuration and UserVars.NutMinSupplies is set to 1, right ?

          • I am using a simple Linux box with NUT server on it. I am also using small raspberry Pi linux boxes with a NUT server on them for other smaller UPS. But they all work the same.

          • Now I know what’s the problem and everything is working as expected :

            2022-12-24T08:25:16.931Z No(29) upsmon[1049582]: UPS UPS_RACK@192.168.2.2 on battery
            2022-12-24T08:25:21.951Z In(30) upsmon[1049582]: Signal 10: User requested FSD

            The time elapsed between the ONBAT event and the SHUTDOWN action is 5 seconds… as requested by the NutOnBatteryDelay. I think you did not read carefully the readme file or this article. The unit time used by the NutOnBatteryDelay are seconds not minutes. If you want 5 minutes you have to enter 300. All the configurable delays are in seconds (NutOnBatteryDelay and FinalDelay).

        • Found a strange issue.
          If for example i have a machine setted up to shutdown after 5 minute of UPS on battery, if i put the UPS in battery state for 30 seconds and then i switch it back online the machine after 5 minutes will shoutdown anyway. Maybe after the shoutdown is better to check again if the UPS is still on battery state

          Répondre ↓

          • Strange because this is a situation I have tested. It UPS is back online the shutdown on delay is stopped. Have you configured the client to send an email on event? Did you received the ONLINE mail event after the 30 seconds on battery? Can you give me the line ups.status in the output of upsc command when UPS is online?

          • running upsc command on ssh give me « upsc:not found ».
            I setted up email allerts but i’m not receiving it, maybe i need to setup something else in esxi?

    • Thank you Andrea. You may have the description missing bug on your interface for UverVars. I will wait for this to be fixed before taking new snapshots. I can run a nested ESXi8 for testing purposes. My CPU are too old and I have to force the installation it it works for my tests. What kind of hardware are you using? (Network cards?)

      Répondre ↓

  7. Hello Rene! First a huge thanks for this piece of software. Helped me tremendously on my 5.5 ESXi installation years ago.

    Now I’ve got two 7U3 servers in a cluster. I have an Eaton 93PS UPS that has a network card. It definitely supports SNMP as well as some Eaton protocols (eg IPMI).

    Got a couple of questions, any help will be appreciated:
    1) What user/password do I specify for this SNMP ups? My synology NAS can connect to this Eaton SNMP UPS without any special configuration, apart from the UPS ip address of course. Should I leave nut user and password fields empty in uservars?

    2) Do you feel there is some sort of special configuration regarding a cluster setup?

    Again THANK you for some awesome work! Especially with the NutOnBatteryDelay parameter: this will allow me to shut down my hosts first and on low-battery the NAS/SAN itselft.

    You’re awesome!

    Répondre ↓

    • Hi Michael. First the NUT client running on ESXi does not connect directly to the UPS. It will need an NUT server. In your case you may use your synology NAS server as a NUT server. Then you mays have to define a user/passwor in your synology NUT configuration to allow clients to connect. I can’t help you on that specific topic, I don’t own a synology NAS.
      Secondly, my NUT package is not supposed to run on a vSphere cluster as it may not respect the HA configuration. Currently the NUT client will poweroff the node and hosted VMs will shutdown/suspend properly depending on the configuration and the availability of the vmware-tools on them. On a cluster, it should try to evacuate the VMs to another cluster node using live migration unless all nodes are running out of power supply. I have never tried this on my Lab as I’m using a single node ESXi. I could trie to run a nested cluster but I probably will run out of RAM, my home lab is a small configuration.
      I am glad that my work is usefull for people but unfortunately I can’t test all configurations. This project was a small need I had in my home configuration and I decided to share it as it may be usefull and I didn’t found any simple solution on the internet ten years ago (and even now).

      Répondre ↓

      • Thank you for your extremely fast reply!

        Regarding the need to have a NUT server in server mode (ie allowing connections from NUT clients) I’ve already found a blog regarding the case, writing it here in case someone needs to do the exact same thing 🙂 https://www.gooksu.com/2022/01/esxi-7-x-nutclient-to-query-upsmon-on-synology/

        As for taking care of a cluster, well I’ll just simulate this and check what happens 😀

        And no worries about what you can and can’t do. Your work has helped me ENORMOUSLY! It allows me to do things in a much cleaner way, without having to involve the Eaton software!!!!

        One final question: should I re-install your package in case I do some sort of update on my ESXi hosts?

        Looking forward to your next versions 🙂

        Répondre ↓

        • If you update your ESXi host, the NUT client will remain installed and configured as long as your ESXi acceptance level is set to « Community Supported » (otherwise the upgrade process will complain about the Vib acceptance level compliance). Tested using :
          1) « update manager/lifecycle manager » feature on vCenter Server
          2) doing it manually with the ESXi command line « esxcli software vib update -d … »
          3) using the update module feature of the ESXi web-ui interface
          Of course if you do a complete reinstall of the ESXi you will need to reinstall the NUT client ViB.
          The offline bundle is now the better choice for NUT client installation on ESXi 6+ as it can also be included in a custom ESXi installation ISO

          Répondre ↓

          • I got stuck here. Please note that my knowledge of ESXi is rather limited here.

            I tried installing with sh upsmon-install.sh. Got the warning about having to enable community. Trtying to enable it with « esxcli software acceptance set –level=CommunitySupported » I’ve received the following error, due probably to the fact that both of my hosts have been configured to boot with secure boot enabled:

             » [AcceptanceConfigError]
            Secure Boot enabled: Cannot change acceptance level to community.
            Please refer to the log file for more details. »

            Can I install it in another manner? This is a production environment and I’m afraid to disable secure boot…

          • Secure boot will not allow you to lower the acceptance level to CommunitySupported. Thus it will not allow you to install the NUT client VIB as it is not signed by VMware or any of their partners. On a production server with VMware support, if you open a ticket, VMware may tell you that your configuration is not compliant with support requirements and can blame the unsigned ViB to be the cause of your problem without trying to investigate. As always, the NUT client is provided ‘as is’, and users are the only responsibles for its use. I can only warn you. This ViB was designed for a single ESXi host using the free licence. On a cluster with HA enabled, the startup/shutdown VM order configuration is not used. HA configuration comes first.

  8. I do not worry about the startup/shutdown order, my VMs are not really sensitive on the startup order. Stability-wise your package has worked like a charm.

    Plus, the alternative would be utilizing the supported, albeit bloated, Eaton IPM on an extra needed physical host, with a lot of customization that has to take place. Seriously now, it’s not worth that hussle!

    Wondering here (please don’t laugh, not an expert here): if I disable secure boot, set acceptance level to community and install your package, can I then revert the level to whatever it was before in order to re-enable secure boot?

    Répondre ↓

  9. Rene apart from my esxi hosts that I’m now using your latest software version I also have a Debian physical host running the latest NUT. Do you know how I could implement the functionality of you NutOnBatteryDelay on a plain NUT installation?

    Répondre ↓

  10. Assuming I set the start order to be the NUT server first, is there any reason why I can’t install NUT server as a Linux-based VM on the same ESXi host where the NUT client will be installed?

    Répondre ↓

    • Nut server should be the last service UP. As a VM it can’t be this way. Some people have done this successfully but I totally discourage this. You want to save an external NUT server, right?

      Répondre ↓

        • You may need to fine tune the FinalDelay in order allow the NUT server to shutdown and send the poweroff action to the UPS before shutting down the other VMs and ESXi itself. Then on your UPS you will have to configure the « Interval to wait after shutdown with delay command » to allow everything to power off gracefully. Not so easy as normally everything is supposed to already be powered off but the NUT server when the UPS receives this command from the NUT server.

          Répondre ↓

Laisser un commentaire

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