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 24/10/2022 : Sous ESXi 8.0 dans l’interface client HTML, vous ne verrez pas les descriptions associées aux UserVars du client NUT. Ceci est un bug du client HTML de ESXi 8.0. Sur les versions précédentes jusqu’à ESXi 7.0.3, les descriptions sont bien présentes. Elles sont aussi présentes sous ESXi 8.0 en ligne de commande.
Mise à jour du 23/10/2022 : La version 2.4.0 du client NUT apporte une nouvelle fonctionnalité : quand l’onduleur passe sur batterie vous pouvez désormais choisir de stopper l’hôte ESXi après un temps configurable indépendamment de l’évènement de batterie faible. Utilisez le paramètre NutOnBatteryDelay pour définir ce temps en secondes. La valeur 0 signifie attente infinie (on attend l’évènement batterie faible pour stopper le système, comme dans les versions précédentes). Si la valeur est différente de 0, le système sera stoppé au premier des deux qui arrivera : batterie faible ou fin du délai en secondes. Si l’onduleur retourne sous tension avant la fin du délai, le système ne sera pas stoppé, le délai sera réinitialisé.
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.0 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 succint à 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 ne pouvez pas configurer 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.0-2.4.1.x86_64.tar.gz – 901,66 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 » . 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.0-2.4.1-offline_bundle.zip – 903,87 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 (sera mis à jour prochainement pour CentOS 7 et Rocky 8).
Téléchargez ici les sources
Télécharger “NutClient-ESXi (sources)” NutClient-ESXi-2.8.0-2.4.1-src.tar.gz – 119,45 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.0-2.4.0.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.0-2.4.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.0-2.4.1.x86_64.tar.gz 100% 902KB 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.4.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.0-2.4.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 fichier 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
- 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.
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 (ne faites pas ça si vous n’aviez pas prévu d’arrêter votre machine).
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 out2022-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
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.
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.
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 !
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 😉
Merci pour le feed-back. Je suis content de voir que ce module, créé à l’origine pour un besoin personnel, puisse être utile à d’autres.
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.
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.
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.
Désolé mais je ne possède pas de NAS synology. Je ne peux pas vous aider. Vous devriez contacter le support ou alors les forums dédiés.
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.
Answer is no. Only the server side of NUT can talk to the UPS. Nut server can’t run on ESXi hypervisor, it has no access to USB/serial ports.