Client NUT pour ESXi 5, 6, 7 et 8

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é.

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.1-2.6.1.x86_64.tar.gz – 868,91 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.1-2.6.1-offline_bundle.zip – 870,81 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.1-2.6.1-src.tar.gz – 121,92 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.1-2.6.1.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.1-2.6.1.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.1-2.6.1.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.1-2.6.1.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.1-2.6.1
   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).

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

  1. Hello Rene,
    i have found your great NUT Client for ESXi and I have already installed on 6.7 (X) and want to check if it is running and proper connected to my QNAP NUT Server.
    In Syslog I only find this after a restart of NutClient in ESXi Web Consol:

    22-12-30T14:47:17Z NUT: NUT client is running
    2022-12-30T14:47:17Z upsmon[2098365]: Signal 15: exiting
    2022-12-30T14:47:17Z NUT: NUT client stopped
    2022-12-30T14:47:17Z upsmon[2100106]: Startup successful
    2022-12-30T14:47:17Z upsmon[2100106]: Warning: running as one big root process by request (upsmon -p)
    2022-12-30T14:47:17Z NUT: NUT client started
    2022-12-30T14:47:17Z NUT: NUT client is running
    2022-12-30T14:47:17Z sfcbd-config[2100153]: new install or upgrade previously completed, no changes made at version 6.7.0
    2022-12-30T14:47:17Z sfcbd-config[2100153]: file /etc/sfcb/sfcb.cfg update completed.
    2022-12-30T14:47:25Z sftp-server[2098622]: open « /var/log/syslog.log » flags READ mode 0666

    Noting similar to the syntax I found on the web:
    2019-09-22T13:28:07Z upsmon[2111424]: Communications with UPS ups@UPSHOST established

    And also with ps I do not find a running process « nut » or what is the right namen?

    Can you please tell me how I can properly check if the Client is running and connected?

    Thank you
    Best regards
    Bernd

    • Process name is upsmon. You will get no message in the /var/log/syslog.log file if the connection is established successfully with the Nut server, but you will get error messages if it cannot be established. Messages may look like this :
      2022-12-30T15:56:52Z upsmon[2099961]: UPS [upsname@192.168.1.1]: connect failed: Connection failure: Connection timed out
      2022-12-30T15:56:54Z upsmon[2100193]: UPS [upsname@upsserver]: connect failed: No such host
      2022-12-30T15:56:54Z upsmon[2100193]: Communications with UPS upsname@upsserver lost

      On Nut server side you should see a line in system log file like :
      Dec 30 17:00:12 servname upsd[9224]: User upsuser@192.168.1.2 logged into UPS [upsname]

      • Hello René,

        thanks for your fast respond. Looks like Nut Client is running:

        [root@XXX-ESXi3:~] ps | grep upsmon
        2100106 2100106 upsmon

        As Nut server is a QNAP NAS I will need to look for the right log file.

        Thank you very much for the Client and your support on it! Great Project!!!

        Best regards
        Bernd

  2. Bonjour René,
    J’essaye de faire fonctionner NutClient-ESXI sur mon serveur sans succès.
    J’utilise «ESXi-7.0U3-18644231-standard» avec le VIB Offline NutClient-ESXI-2.8.0-2.4.0

    Je suis capable d’obtenir du data du serveur NUT avec la commande «/opt/nut/bin/upsc ups@…»

    J’en conclu que la communication fonctionne bien.

    La commande «/opt/nut/sbin/upsmon -c fsd» fonctionne aussi parfaitement.
    Elle éteint chacune de mes VM et termine avec le host sans problème.

    Cependant, lors d’un test réel, le temps du paramètre «UserVars.NutOnBatteryDelay» n’est jamais respecté.
    La batterie de mon UPS se vide littéralement avant que la routine commence.

    Voici mes paramètres avec le «UserVars.NutOnBatteryDelay» poussé à l’extrême:
    UserVars.NutFinalDelay 5
    UserVars.NutMinSupplies 1
    UserVars.NutOnBatteryDelay 1

    J’en suis à me demander si le service fonctionne réellement, même s’il est indiqué comme étant «démarré».

    Peux-tu m’aider?
    Mathieu

    • Il faut s’assurer que le client NUT est bien connecté au serveur. Sinon il ne reçoit pas les événements onduleur. Les Username/Password et le nom de l’onduleur sont corrects ? Si c’est pas le cas il devrait y avoir des messages d’erreur de upsmon dans /var/log/syslog.log sur l’ESXi.

      • Effectivement, j’ai une avalanche d’erreurs.
        Je recois constamment des :
        «UPS [ups]: connect failed: Connection failure: Connection refused» au 5 secondes.
        Le Username/Password est correct, car la commande «/opt/nut/bin/upsc ups@…» retourne du data valide concernant mon UPS.

        • Je viens de trouver mon problème! Il y avait une coquille dans l’adresse dans le paramètre «UserVars.NutUpsName». C’est pour cette raison que la commande «/opt/nut/bin/upsc» passait, mais pas le service upsmon. Merci pour ton aide.

          • Content que tu y sois arrivé. Configure le délai avec une valeur appropriée et relance le service pour sa prise en compte.

  3. Thank you for this article. I have correctly configured teh syonolody and installed the Esxi component. But, I cannot get a response back!

    Where is the problem? Is this an issue in the Synology or ESXi?

    [root@localhost:/opt/nut/bin] ./upsc apc@192.168.0.41
    Error: Unknown UPS
    [root@localhost:/opt/nut/bin]

    • The error you get with the upsc command means the the server IP address is correct (because you have an answer) but the UPS name is not correct (because the Nut server tells you the the UPS is unknown). Your ups name is not « apc », check the Synology NUT configuration to get the name. I have read that the default UPS name on Sinology is « ups » but I can’t confirm this as I don’t own a Sinology NAS.

  4. Hello René,

    thank you for your great work. I’ve modified your Bundle, so that the shutdown cmd can be customized in the UI. Reason is that simply calling poweroff is not shutting down the VMs in a clean way. I’ve modified the command to call the autostart/shutdown routine and wait for the VMs to shut down before the host is shut down. Currently, thats done via a sleep command – which is not very nice, but works. I am happy to share the new bundle, so that you can offer that for download.

    • The shutdown command will properly call the autostartmanager/autostop routine but you have to configure autostart/shutdown at least once per VM even if you set the configuration back to default after that. This is a known issue on ESXi (all versions), the default behavior is not respected if you haven’t changed at least once the autostart/shutdown of the VM. Once it’s done, it will follow the autostart/shutdown for that VM otherwise it will power off the VM brutally.
      I took a look in your package and I confirm that it is not very nice, I would never call a command in a configuration variable. It is a big security issue as it will be executed with root privileges. I will check how it works. You need the 80 seconds delay because the hostsvc/autostartmanager/autostop will not wait the end of VM shutdown ?

    • I have tested the hostsvc/autostartmanager/autostop in ESXi7 and the bug is the same as in poweroff. Any new VM that has not been configured in the autostart/top sequence at least once will not be stopped. This was the solution I was using in a very old NUT support in ESXi 4.0 and described in an old article. I am no longer using this command, only the power off command as it will do the same VMs shutdown with the same bug.
      Concerning your effort to update the bundle I am happy to see that you understood how the configuration works and how to implement new features. Great !

  5. Merci René pour ceci, vraiment apprécié!

    Un de mes hôte ESXi a souffert lors d’une panne électrique il n’y a pas longtemps. Il était alors temps que je mettes en place une solution pour mes UPS existant. C’est là que je suis tombé sur Nut Server. Une recherche pour le support de VMware pointe directement sur cette page.

    Ceci est pour un lab à la maison mais sur lequel il repose une dépendance après toutes ces années.

    En direct du Canada 😉

  6. Hi Rein,

    Recently I configured the new nut client on ESXi 8.0a, and noticed that I get the following error message:

    2023-02-07T18:55:39.117Z Er(27) upsmon[583523]: Login on UPS [ups@192.168.xx.xx] failed – got [ERR ACCESS-DENIED]
    2023-02-07T18:55:44.117Z No(29) upsmon[583523]: Communications with UPS ups@192.168.xx.xx established

    but when i look at « /opt/nut/etc/upsmon.conf » the below is setup. I tried to change the word secondary to « master » or « slave » but it doesn’t seem to let me change it.

    MONITOR ups@192.168.xx.xx 1 upsuser upspassword secondary

    So my question, is there a way to change the word « secondary » to something else, or what would be the best way to fix/troubleshoot the authentication issue? Thanks!

    • In upsmon.conf, secondary is a synonym of slave. It can’t be master or primary as this can only be used on the server side.
      The access denied error seems to come from wrong values of upsuser or upspassword. Check what are the values configured on the NUT server.
      You can’t change the configuration file, this file is recreated from upsmon.conf.template each time the service is restarted. And you can’t change upsmon.conf.template file as this file is read-only and protected by the system.

      • Hi Rein,

        I’ve validated my configuration and it is correct, but I think instead of « secondary », it is expecting the word « slave » as I have other devices connected to my nut server.

        If you feel there is something I am missing, I am all ears, thanks!

        • Secondary is valid and introduced un NUT 2.8.0 which is the running version with the package you installed on ESXi. It can communicate with earlier versions of NUT servers. Secondary and slave are the same feature. The NUT project has just decided to stop using slave/master keywords and to prefer secondary/primary keywords. What is your NUT server ? Can you access the upsd.users file ? Username should be into brackets followed by password=upspassword in the next lines.

          • Hi Rein,

            Thanks for trying to help me with this issue, i think the issue is with synology as the problem seemed to have arised in a more recent version of DSM, where it doesn’t seem to be honoring the upsd.users file. When I tried to define the password for monuser it wouldn’t take anything besides « secret ». Also when I created other users, it also isn’t recognizing the other users either. So many apologies, and also many thanks for looking and providing some pointers.

  7. Hello Rene,
    thank you very much for making this package.
    People like you make the home-lab area worthwile!

    It took a bit to find your page googling, the nut homepage does not reflect the latest package somehow. Was a breeze to install it on my ESXI 8.0c servers!

    • Thank you for your feedback. I try to keep this module as simple as possible. I have a redirection on my website when you try to download the package from the Nut website it will download the latest version even il the link is pointing to an very old version.

      • Yes, you’re right. I came from another link I’ve found..

        To sum things up I’ve read here:
        So you call in ‘powerdown’ the call from a regular esxi-shutdown (without maintenance), right? And that needs to have each VM set to ‘suspend’ or ‘shutdown’ individually, not by system defaults? So once set, I can ‘dry-run’ a shutdown from esxi menu?

        Again, great work, Rene!

        • You are right. The host is not set to maintenance mode. It is a regular ESXi shutdown and it will shutdown/suspend the VM according to your settings. You should not rely on defaults and edit the settings at least one for each VM. (Then you can set it back to default). For a clean VM shutdown it must run the vmware tools (or open-vm-tools) to execute the embeded shutdown sequence. Personally I prefer to suspend VM as it is faster in stop and also start but some applications may not support it correctly (time clock jumps or network connexions). Once configured, you can start a shutdown on ESXi ans you should see the VM to stop as configured before the ESXi poweroff.

  8. Bonjour René,

    Je viens de mettre à jour mon Esx en 8.0 ainsi que mon NAS.
    J’ai vu dans des commentaires précédents que Synology a bloqué le fichier upsd.users.
    Est-il possible de contourner le problème ?
    En sachant que Synology limite à l’IP, est-il possible d’accepter la valeur NutPassword sans mot de passe ?
    Car quand je fais /opt/nut/bin/upsc ups@192.168.50.3, cela me ressort toutes les infos de mon onduleur.
    A te lire.

  9. Hello René,

    First of all congratulations for this work.
    I would like to know. Is it possible to connect directly via usb? Or can you only connect to a say with IP?

    kind regards.

      • Regarding this part – I wonder if NUT part for networked drivers (SNMP, NetXML, …) might be viable? For larger setups with a rack of servers fed off an SNMP-capable UPS, it might make more sense for VM hosts to drive their shutdowns (and eventually physical power-off), than one of guest VMs doing so…

        • I have never been in favor of using a VM as a NUT server. The behavior is too uncertain and the timing becomes critical and difficult to configure. I like when things are simple and clear but I know that this is a frequent request from the users. In my lab I only have UPS with USB or RS232 port. I quickly understood that access to physical ports (USB and serial) was practically impossible from the hypervisor, which prohibited the installation of the server part on ESXi. For network UPS it may be a different story. In any case, another concern is the availability of libraries and dependencies. Sometimes you have to compile them and embed them with you on the hypervisor and it can quickly become crowded. Here again I favor the smallest size for the package because the space available in the ESXi boot partitions is not unlimited.

  10. Hello. I am not sure if WP ate my previous comment a couple of days ago, or if it is just waiting for anti-spam approval? Just in case, posting again 🙂

    I am the current NUT maintainer, and wondered if your recipes for building the VMWare integration packages are publicly available – so people could roll their own from newer NUT releases or master-branch snapshots.

    Feel free to post a PR with a `scripts/…` contributed directory (a README file with an English retelling of this blog and earlier Q&A would be great) to the main NUT repository. Alternately if it makes more sense, a separate repo i the organization can be arranged.

    https://github.com/networkupstools/nut/issues/1961

    • Hi, your previous comment posted yesterday was in the spam list but I was not notified about it, strange. Sorry, this is a default feature of WP.

      Here is a small history about the sources of this project :
      Before may 2019 the procedure to build the package was mostly manual and would require a big document to describe all the steps to compile and create the VIB file. Not very developper friendly. Then I decided to write scripts to make it possible to build everything just launching one make command. I am using my own git server since may 2019 and I have published the sources on this website in a tarball and can be downloaded and modified by anyone. I could create a clone of the repo on GitHub, but I still haven’t did it because sources are not very popular in the download stats.
      The project mostly includes scripts, templates and makefiles to build the package. It will use 3 external source tarballs : Nut, LibreSSL and SMTPTools. Everything is compiled statically with no dynamic libraries to prevent depending on ESXi libraries versions that can be changed/deleted by VMware at anytime though the ESXi updates (I had bad experience with openssl lib in the past). It will download the external sources from official URL if they are not already in the root project directory.
      There is no check of the current dev environment dependencies, there is no autoconf/configure script. I am using CentOS/Rocky linux distributions for the build process and I don’t know if it works on other distributions. I just don’t have time for that. As you can see it is a bit ugly but it works and I manually test all the binary releases on the ESXi 5 to 8 in my lab before publishing them. There is one patch applied to the vanilla Nut sources before compilation to remove a call to « initgroups » because this feature introduced in Nut-2.7.4 was failing on ESXi libc, preventing to start the upsmon process.

      The NUT web site has a link to my initial post in my WP blog. I have been maintaining the package since may 2012 using the latest available sources for Nut and LibreSSL (SMTPTools are not maintained anymore). So even if you use the old 1.4.0 link still in https://networkupstools.org/download.html page you will download the latest version of the package (currently 2.4.1). Arnaud Quette from the NUT project contacted me to add this link back in 2012.

      I will take a look at your git issue and add a comment.

Répondre à Bernd Annuler la réponse

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