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
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 :
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:
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.
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).
Je pense avoir trouvé le problème, le dossier spécifié pour le POWERDOWNFLAG n’était pas correctement syntaxé. Juste une réelle dernière question, killpower est un fichier créé juste avant l’extinction du RPI ? Merci.
Le POWERDOWNFLAG doit être /etc/killpower . Ce fichier n’existe pas et il sera créé quand le serveur NUT voudra demander à l’onduleur de s’éteindre. Sur un système raspbian il sera détecté par le script de halt (/lib/systemd/system-shutdown/nutshutdown) qui appellera la commande upsdrvctl shutdown. C’est cette commande qui donne l’ordre à l’onduleur de s’éteindre.
Bonjour René.
Tout d’abord, ma langue maternelle est le néerlandais, ma deuxième langue est l’anglais. Le texte est traduit par deepl 🙂
Deuxièmement. Quel projet génial vous avez créé et entretenu. Existe-t-il un moyen de faire un don ?
Et maintenant, la vraie partie. Je pense que j’ai tout essayé, mais peut-être pourriez-vous m’éclairer sur ce point.
NUT est un NAS Synology
VMWare est ESXi Free 7.0 Update 3. Il tourne sur un HPE Proliant ML350Gen11 avec 128 Go de RAM.
Les temps d’arrêt sont pour MS Server 1 minute, ESX server 1 minute, NAS 1 minute.
Testé jusqu’à présent ;
– la connexion au serveur NUT fonctionne (les journaux affichent et le serveur s’arrête)
– Ajustement des temps d’arrêt et de démarrage de la VM
– J’ai joué avec les paramètres. Pour l’instant, ils sont les suivants
UserVars.NutFinalDelay 5
UserVars.NutMinSupplies 1
UserVars.NutOnBatteryDelay 300
– VMware Tools 12.3.5 build 22544099 is used
Merci d’avance !
———————————————————————————————–
Hi Rene.
First, my native language is Dutch, second language is Englisch. The text is translated by deepl 🙂
Second. What an awesome project you have created and maintaned. Is there a way to donate?
So now the real part. Somehow the VM is shutdown hard every time and i think i tried everything but perhaps you are able to shine a light.
NUT is a synology NAS
VMWare is ESXi Free 7.0 Update 3. Running on a HPE Proliant ML350Gen11 with 128Gb RAM.
Shutdown times are for MS Server 1 minute, ESX server 1 minute, NAS 1 minute
So far tested;
– connection to NUT server works (logs shows and server shutdown)
– Adjusted shutdown and startup time of the VM
– played around with the settings. At this moment they are:
UserVars.NutFinalDelay 5
UserVars.NutMinSupplies 1
UserVars.NutOnBatteryDelay 300
– VMware Tools 12.3.5 build 22544099 is used
Thanks in advance!
Hi Edwin,
Thank you for your support. This project is free and I am not expecting any donation. This is something I wrote for my own needs as I haven’t found any equivalent. I share it because it may be useful to others.
Regarding your configuration. Did you configure your VMs in the autostart sequence of ESXi ? (Host/Manage/System/Autostart in ESXi web UI). This configures the start and stop action of the VM when the ESXi starts and stops. You should configure the default stop action as « shutdown » for a clean shutdown with the vmware tools installed or « suspend » to freeze the VM if you don’t have the vmware tools installed in the VM. Then, there is a kind of very old bug where the default autostart behaviour is not applied to VMs if you have not configured individually each VM autostart first. Then you can configure them back to default, they just need to have been configured once.
The FinalDelay is not needed here, the default 5 is ok.
The NutOnBatteryDelay set to 300 is to wait no more than 300 seconds on battery before starting the shutdown sequence even if the UPS tells that it can last longer. If the UPS tells that is battery is low the shutdown will start sooner.
Can you tell me if the UPS is still on when the ESXi turns off? Normally, the NUT server has to wait for clients to disconnect before shutting down itself (there is a configurable timeout on the NUT server, if it takes too long). When powering off the NUT server, it may request the UPS to stop supplying power.
Hi Rene,
Does the final delay mean the delay AFTER the last VM had send a message that it has shutdown. So in fact the last VM is finished and then there is a 5 second wait BEFORE the host starts to shutdown?
Regards, Edwin
Sorry I had no time to make tests. My advise is to set a greater delay for VM shutdown because this is how much time ESXi waits before going to next VM shutdown and maybe to ESXi shutdown after the last VM. If VM can stop before this delay it will not wait more. I am not talking about the final delay parameter but the shutdown vm delay in auto start ESXi configuration.
No problem.
I will test and will let you know.
I’ve got it working.
Looks like you need to choose for shutdown on host as default and on guest choose for system default. As soon if i choose for hybernate on VM i’ve got the unsafe shutdown error i.e. VM has not doen a proper hybernate.
Still unsure about timing (autostart host, autostart VM, NUT Client) but running out of time to try all options and it is now working.
The setting i’m using now are…..
HPE Server:
BIOS Power => 60s delay (gives the UPS/GRID 60 seconds to stabilize)
Host/Manage/System/Autostart:
Enabled: Yes
Start delay: 30s (just to make sure its changed)
Stop delay: 180s (just to make sure its changed)
Stop action: Shut Down
Wait for hartbeat: No
NUT Client settings (Host/Manage/System/Advanced Settings):
UserVars.NutFinalDelay: 5 (default)
UserVars.NutOnBatteryDelay: 60 (because i do not want to drain the new battery totally)
UserVars.NutUpsName: ups@
UserVars.NutPassword: secret (for the Synology)
UserVars.NutUser: monuser
Start/Stop on Host (Host/Manage/System/Autostart)
Enabled: Yes
Start delay: 10s (just to make sure its changed)
Stop delay: 10s (just to make sure its changed)
Stop action: System Default
Wait for hartbeat System: System Default
Synology NAS
Model DS423 / DSM 7.2.1-69057 Update 5 (Latest release)
Configuration/Hardware&Power/UPS
UPS Support: enabled
UPS Type: USB UPS
Time Adjust: 25 min (Puts Synology into standby mode after 25 minutes which is more then enough time to shutdown NAS AND ML350)
Enable Switch of UPS when entering standby (this way I now for sure that the ML350 AND the NAS will boot as soon the power returns since the ML350 is set to power-up after power restore with a 60sec delay)
Enable Network server and whitelist IP adress of VMWare ESXi network (same IP as the GUI)
This now is a working setup for me. Thank you so much Rene for creating and helping troubleshooting!
10s for stop delay is definively too short to allow a clean OS shutdown.
Hi Rene,
Thnx for quick response, took me some time to test a few things.
First, yes the UPS is still on when the ESXi turns off. To test for sure i’ve put the ML350 in a fixed power outlet in the wall. So basically ESX powers down the ML350 but iLO can still be reached to see what is going on in the box.
I totally missed the Host/Manage/System/Autostart instead i adjusted the start/stop in the VM context (Virtual Machines/VM/Actions/Autostart) because i did read the note about the bug.
Enabled Yes
Start delay: 30s (just to make sure its changed)
Stop delay: 10s (just to make sure its changed)
Stop action: Suspend
Wait for hartbeat: No
So now I changed the settings ((Host/Manage/System/Advanced Settings):
I stopped the NUT Client service
Changed settings.
UserVars.NutFinalDelay: 5 (default)
UserVars.NutOnBatteryDelay: 120 (because i do not want to drain the new battery totally)
I started the NUT Client service
Start/Stop on Host (Host/Manage/System/Autostart)
Enabled Yes
Start delay 6s (just to make sure its changed)
Stop delay 10s (just to make sure its changed)
Stop action System Default
Wait for hartbeat System Default
Synology NAS
Model DS423 / DSM 7.2.1-69057 Update 5 (Latest release)
Configuration/Hardware&Power/UPS
UPS Support: enabled
UPS Type: USB UPS
Time Adjust: 25 min (Puts Synology into standby mode after 25 minutes which is more then enough time to shutdown NAS AND ML350)
Enable Switch of UPS when entering standby (this way i now for sure that the ML350 AND the NAS will boot as soon the power returns since the ML350 is set to power-up after power restore with a 60sec delay)
Enable Network server and whitelist IP adress of VMWare ESXi network (same as the GUI)
Still the ESX host shut’s down to soon, does not wait for the end of the suspend process.
Suspend proces comes to around approx. 78% and then the host is starting to shutdown.
So close but not ok, yet…..
Tried again with a bit different settings.
UserVars.NutOnBatteryDelay: 240 (also tried 60 and 180sec)
Now suspend command comes around 240 (60/180)sec after power-loss. I can see the suspended tasks starting and run to about 80% and then the VM Console shows that the VM has been suspendid.
Right after that the ESX starts to shutdown.
BUT, After startup you get after logon to the VM the notification that system has been shutdown unexpected (i tried manually suspend and that is working ok)
So i’ve got the impression that the ESX host is just to fast in shutting down (or the hardware is faster then expected).
Is it possible to let the esx host wait a few seconds before shutting doen the host hardware?
Unable to correct but you’re right. Bad case of false cut & paste. Correct infor should have been:
The setting i’m using now are…..
HPE Server:
BIOS Power => 60s delay (gives the UPS/GRID 60 seconds to stabilize)
Host/Manage/System/Autostart:
Enabled: Yes
Start delay: 30s (just to make sure its changed)
Stop delay: 180s (just to make sure its changed)
Stop action: Shut Down
Wait for hartbeat: No
NUT Client settings (Host/Manage/System/Advanced Settings):
UserVars.NutFinalDelay: 5 (default)
UserVars.NutOnBatteryDelay: 60 (because i do not want to drain the new battery totally)
UserVars.NutUpsName: ups@
UserVars.NutPassword: secret (for the Synology)
UserVars.NutUser: monuser
Start/Stop on VM (Virtual Machines/VM/Actions/Autostart)
Enabled: Yes
Start delay: 10s (just to make sure its changed)
Stop delay: 10s (just to make sure its changed)
Stop action: System Default
Wait for hartbeat System: System Default
Synology NAS
Model DS423 / DSM 7.2.1-69057 Update 5 (Latest release)
Configuration/Hardware&Power/UPS
UPS Support: enabled
UPS Type: USB UPS
Time Adjust: 25 min (Puts Synology into standby mode after 25 minutes which is more then enough time to shutdown NAS AND ML350)
Enable Switch of UPS when entering standby (this way I now for sure that the ML350 AND the NAS will boot as soon the power returns since the ML350 is set to power-up after power restore with a 60sec delay)
Enable Network server and whitelist IP adress of VMWare ESXi network (same IP as the GUI)
Unfortunanly unable to cleanup the mess I created in the comments….
Bonjour René, ce module fonctionnerait-il avec un UPS branché à l’hôte/serveur ESXi directement via un cable USB? Si tel est le cas, quelles sont les valeurs à saisir pour les différentes variables? Je n’ai qu’un seul UPS avec un seul serveur. Le UPS que j’ai n’a pas d’option réseau.
Merci
L’hôte ESXi ne peut pas être lui-même à la fois serveur et client NUT. Ceci est lié à une limitation de ESXi qui ne permet pas d’attaquer directement le port USB depuis l’hôte. En revanche certains utilisateurs ont réussi à créer une VM en lui passant l’accès direct au périphérique UPS en USB. Sur cette VM, un Linux minimaliste et le serveur NUT. Toutefois la configuration des paramètres de timing est assez fastidieuse, car la VM s’arrête avant l’hôte ESXi donc le serveur NUT s’arrête avant le client ce qui n’est pas du tout ce qui est recommandé par le projet NUT. En résumé, c’est possible de cette façon mais vous devrez vous tourner vers la communauté NUT avoir de l’aide si besoin.
Bonjour René.
Très bon job. Y a t-il un mode debug. Car, je ne vois pas où est configurer le port. Le serveur NUT est sur un Raspberry et il fonctionne bien avec les client sur les VM windows avec WinNut et sur OPNsense.
Cependant, j’ai des soucis sur les hôtes ESX, le syslog montre à chaque fois une erreur en access denied. J’ai essayé de mettre le port à la fin eaton@IP:Port mais rien n’y change.
2024-08-29T21:21:57Z upsmon[2117291]: Startup successful
2024-08-29T21:21:57Z upsmon[2117291]: Warning: running as one big root process by request (upsmon -p)
2024-08-29T21:21:57Z NUT: NUT client started
2024-08-29T21:21:57Z upsmon[2117291]: upsnotify: failed to notify about state 2: no notification tech defined, will not spam more about it
2024-08-29T21:21:57Z NUT: NUT client is running
2024-08-29T21:22:00Z upsmon[2117291]: Login on UPS [eaton@172.16.200.3] failed – got [ERR ACCESS-DENIED]
Le port TCP vers le serveur est le 3493 et je déconseille d’en utiliser un autre à cause des règles de firewall internes à ESXi. Le message Access-Denied signifie que le client NUT a été capable d’atteindre le serveur mais que ce dernier à refusé le couple user/mot de passe fourni. Il n’y a pas de mode débug prévu à moins de tuer le processus upsmon et de le relancer à la main avec l’option -D (autant de fois -D que de détails voulus)
rep,
Effectivement cela fonctionne avec le compte master et non avec le compte slave.