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. Qu’appelez-vous un refresh des services car là mon problème c’est au redémarrage.
    Y -a-t-il une commande que je puisse lancer directement sur l’esxi pour voir l’état de ce service ?
    Merci pour votre aide.
    Bon week end

    • Dans l’interface client vCenter, les services apparaissent arrêtés alors que ce n’est pas vrai. Il faut, dans cette interface, forcer vCenter à relire l’état des services. C’est un vieux bug de l’interface d’admin toujours pas corrigé.
      Sinon pour lever le doute. Sur ESXi, lancer la commande ps et vérifier que le processus upsmon est bien présent.

  2. Pour le coup j’ai fait un /etc/init.d/upsmon statuts depuis Putty et le serveur me renvoie bien « NUT client is running ». Donc il y a bien un problème de rafraîchissement dans l’interface sphere.

    Y a-t-il des réglages à effectuer dans /etc/ups/upsmon.conf ou bien le fait de suivre votre tuto suffit ?

    Merci encore pour votre aide précieuse.

    • Le fichier /etc/ups/upsmon.conf est généré automatiquement au lancement du service en fonction de ce qui a été rentré dans les UserVar. Toute modification du fichier sera perdue a la prochaine relance du service (au prochain boot).

  3. I am getting an error when I try to install

    [root@esxi6-1:/tmp] sh upsmon-install.sh
    [InstallationError]
    Failed to remediate the host: (None, "Failed to save Bootcfg to file /altbootbank/boot.cfg: [Errno 5] Input/output error: '/altbootbank/boot.cfg.tmp'")
    vibs = set(['VMware_bootbank_ima-qla4xxx_2.02.18-1vmw.600.0.0.2494585', 'VMware_bootbank_sata-sata-sil_2.3-4vmw.600.0.0.2494585', 'VMware_bootbank_lpfc_10.2.309.8-2vmw.600.0.0.2494585', 'VMware_bootbank_lsi-mr3_6.605.08.00-7vmw.600.1.17.3029758', 'VMware_bootbank_net-tg3_3.131d.v60.4-2vmw.600.1.26.3380124', 'VMware_bootbank_vsan_6.0.0-2.34.3563498', 'VMware_bootbank_ata-pata-via_0.3.3-2vmw.600.0.0.2494585', 'VMware_bootbank_scsi-megaraid-sas_6.603.55.00-2vmw.600.0.0.2494585', 'VMware_bootbank_net-igb_5.0.5.1.1-5vmw.600.0.0.2494585', 'VMware_bootbank_sata-ahci_3.0-22vmw.600.2.34.3620759', 'VMware_bootbank_lsu-lsi-mpt2sas-plugin_1.0.0-4vmw.600.1.17.3029758', 'VMware_bootbank_lsu-hp-hpsa-plugin_1.0.0-1vmw.600.0.0.2494585', 'VMware_bootbank_scsi-aacraid_1.1.5.1-9vmw.600.0.0.2494585', 'VMware_bootbank_esx-tboot_6.0.0-2.34.3620759', 'VMware_bootbank_rste_2.0.2.0088-4vmw.600.0.0.2494585', 'VMware_bootbank_net-ixgbe_3.7.13.7.14iov-20vmw.600.0.0.2494585', 'VMware_bootbank_block-cciss_3.6.14-10vmw.600.0.0.2494585', 'VMware_bootbank_net-e1000e_3.2.2.1-1vmw.600.1.26.3380124', 'VMware_bootbank_scsi-mptspi_4.23.01.00-9vmw.600.0.0.2494585', 'VMware_bootbank_ipmi-ipmi-devintf_39.1-4vmw.600.0.0.2494585', 'VMware_bootbank_ata-pata-atiixp_0.4.6-4vmw.600.0.0.2494585', 'VMware_bootbank_lsu-lsi-lsi-mr3-plugin_1.0.0-2vmw.600.0.11.2809209', 'VMware_bootbank_esx-xserver_6.0.0-0.0.2494585', 'VMware_bootbank_sata-sata-promise_2.12-3vmw.600.0.0.2494585', 'VMware_bootbank_qlnativefc_2.0.12.0-5vmw.600.0.0.2494585', 'VMware_bootbank_net-cnic_1.78.76.v60.13-2vmw.600.0.0.2494585', 'VMware_bootbank_net-bnx2x_1.78.80.v60.12-1vmw.600.0.0.2494585', 'VMware_bootbank_lsu-lsi-mptsas-plugin_1.0.0-1vmw.600.0.0.2494585', 'VMware_bootbank_ohci-usb-ohci_1.0-3vmw.600.0.0.2494585', 'VMware_bootbank_sata-sata-nv_3.5-4vmw.600.0.0.2494585', 'VMware_bootbank_lsu-lsi-lsi-msgpt3-plugin_1.0.0-1vmw.600.0.0.2494585', 'VMware_bootbank_net-vmxnet3_1.1.3.0-3vmw.600.2.34.3620759', 'VMware_bootbank_misc-cnic-register_1.78.75.v60.7-1vmw.600.0.0.2494585', 'VMware_bootbank_esx-dvfilter-generic-fastpath_6.0.0-0.0.2494585', 'VMware_bootbank_ata-pata-sil680_0.4.8-3vmw.600.0.0.2494585', 'VMware_bootbank_ata-pata-serverworks_0.4.3-3vmw.600.0.0.2494585', 'VMware_bootbank_nmlx4-en_3.0.0.0-1vmw.600.0.0.2494585', 'VMware_bootbank_net-nx-nic_5.0.621-5vmw.600.0.0.2494585', 'VMware_bootbank_ata-pata-hpt3x2n_0.3.4-3vmw.600.0.0.2494585', 'VMware_bootbank_scsi-mpt2sas_19.00.00.00-1vmw.600.0.0.2494585', 'VMware_bootbank_sata-sata-sil24_1.1-1vmw.600.0.0.2494585', 'VMware_bootbank_sata-sata-svw_2.3-3vmw.600.0.0.2494585', 'VMware_bootbank_elxnet_10.2.309.6v-1vmw.600.0.0.2494585', 'VMware_bootbank_xhci-xhci_1.0-3vmw.600.2.34.3620759', 'VMware_bootbank_vsanhealth_6.0.0-3000000.3.0.2.34.3544323', 'VMware_bootbank_nvme_1.0e.0.35-1vmw.600.2.34.3620759', 'VMware_bootbank_net-bnx2_2.2.4f.v60.10-1vmw.600.0.0.2494585', 'VMware_bootbank_scsi-hpsa_6.0.0.44-4vmw.600.0.0.2494585', 'VMware_bootbank_scsi-megaraid2_2.00.4-9vmw.600.0.0.2494585', 'VMware_bootbank_emulex-esx-elxnetcli_10.2.309.6v-0.0.2494585', 'VMware_bootbank_scsi-mptsas_4.23.01.00-9vmw.600.0.0.2494585', 'VMware_bootbank_ata-pata-amd_0.3.10-3vmw.600.0.0.2494585', 'VMware_bootbank_nmlx4-core_3.0.0.0-1vmw.600.0.0.2494585', 'VMware_bootbank_scsi-adp94xx_1.0.8.12-6vmw.600.0.0.2494585', 'VMware_bootbank_scsi-bnx2i_2.78.76.v60.8-1vmw.600.0.11.2809209', 'VMware_bootbank_ata-pata-pdc2027x_1.0-3vmw.600.0.0.2494585', 'VMware_bootbank_lsi-msgpt3_06.255.12.00-8vmw.600.1.17.3029758', 'VMware_bootbank_uhci-usb-uhci_1.0-3vmw.600.0.0.2494585', 'VMware_bootbank_sata-ata-piix_2.12-10vmw.600.0.0.2494585', 'VMware_bootbank_net-mlx4-core_1.9.7.0-1vmw.600.0.0.2494585', 'VMware_bootbank_esx-base_6.0.0-2.34.3620759', 'VMware_bootbank_esx-ui_1.0.0-3617585', 'VMware_bootbank_scsi-ips_7.12.05-4vmw.600.0.0.2494585', 'VMware_bootbank_net-forcedeth_0.61-2vmw.600.0.0.2494585', 'VMware_bootbank_cpu-microcode_6.0.0-0.0.2494585', 'VMWARE_bootbank_mtip32xx-native_3.8.5-1vmw.600.0.0.2494585', 'VMware_bootbank_net-enic_2.1.2.38-2vmw.600.0.0.2494585', 'VMware_bootbank_ehci-ehci-hcd_1.0-3vmw.600.2.34.3620759', 'VMware_bootbank_scsi-fnic_1.5.0.45-3vmw.600.0.0.2494585', 'VMware_bootbank_misc-drivers_6.0.0-2.34.3620759', 'VMware_bootbank_net-mlx4-en_1.9.7.0-1vmw.600.0.0.2494585', 'VMware_bootbank_scsi-qla4xxx_5.01.03.2-7vmw.600.0.0.2494585', 'VMware_bootbank_nmlx4-rdma_3.0.0.0-1vmw.600.0.0.2494585', 'VMware_bootbank_scsi-megaraid-mbox_2.20.5.1-6vmw.600.0.0.2494585', 'VMware_bootbank_lsu-lsi-megaraid-sas-plugin_1.0.0-2vmw.600.0.11.2809209', 'VMware_bootbank_scsi-aic79xx_3.1-5vmw.600.0.0.2494585', 'VMware_bootbank_scsi-bnx2fc_1.78.78.v60.8-1vmw.600.0.0.2494585', 'VMware_bootbank_ipmi-ipmi-msghandler_39.1-4vmw.600.0.0.2494585', 'VMware_bootbank_ata-pata-cmd64x_0.2.5-3vmw.600.0.0.2494585', 'VMware_bootbank_net-e1000_8.0.3.1-5vmw.600.0.0.2494585', 'VMware_bootbank_ipmi-ipmi-si-drv_39.1-4vmw.600.0.0.2494585'])
    Please refer to the log file for more details.

    • Read the error message : input/output error. The install process cannot write to your boot device. What kind of device is it? Maybe it’s experiencing an hardware failure. The system log located in /var/log should give you details

  4. Hello René , thank for your guide, very usefull. I have installed nut with esxi 6 and work perfectly. 1 question.. what I have to do to have the killpower of my ups? I’m not expert of scripts or other. I would like the ups to kill down when system is shutdown, so my microserver gen8 can wake up when power return and restore last power state.

    thank you very much.

  5. Bonjour,

    Merci pour votre tuto, je l’ai suivi et j’ai bien le message de l’installation terminée avec le même résultat après l’exécution à partir de /tmp # sh upsmon-install.sh
    Installation Result
    Message: Operation finished successfully.
    Reboot Required: false
    VIBs Installed: Margar_bootbank_upsmon_2.7.4-1.4.0vmw.500
    VIBs Removed:
    VIBs Skipped:

    En revanche quand je me rends dans UsersVars des paramètres avancées
    je n’ai pas les variables correspondant à NUT que vous citées. J’ai essayé de démarrer le service UPS mais ça ne change rien. Auriez vous une idée svp. Je suis en version ESXi 6.0.

    Merci.

    • Effectivement il arrive que les variables ne soient pas immédiatement visibles. Si on est pressé et qu’une indisponibilité est admissible : rebooter l’hyperviseur ESXi.

      • Bonsoir René,

        Merci ça a marché après un reboot effectivement.

        J’ai une question à laquelle vous pourrez peut être répondre : j’ai bien compris le but de la variable UserVars.NutFinalDelay, mais serait-il possible de définir une variable pour définir une durée avant l’arrêt de l’esx à partir du moment où il est rentre en mode batterie, et non seulement en batterie faible. Je demande ça car mon onduleur est relié en USB à mon serveur NUT physique, et mon serveur NUT s’éteignant au bout d’une minute après qu’il soit rentré en mode batterie, la communication réseau ne se fera plus entre lui et mon esx.

        • Hélas non c’est toujours le serveur NUT qui donne l’ordre aux clients de s’éteindre que ce soit sur batterie faible ou sur tout autre événement qui a été configuré sur le serveur. Le serveur NUT ne devrait pas s’éteindre avant d’avoir envoyé l’ordre de s’éteindre aux clients. Je pense qu’il faut revoir la configuration du serveur. L’événement batterie faible doit se produire quand il reste juste assez d’autonomie pour tout éteindre en correctement.

    • Even lowering the acceptance level to minimal is not enough. I still need to use -f option to install the Vib because some files are written in directories that are not open for community add-ons. I would need a vmware signature on Vib for that. I don’t think they would agree…;)

  6. Hi,

    fantastic app.
    I have a small challenge:

    Is it possible to implement a option to extend the shutdown procedure to shutdown all virtual machines first and at the end the esxi?

    If your nut client shutdown my esxi 6.0U2 it’s so fast, not all of my virtual machines make a clean shutdown. There is not enough time to shutdown all virtual machines 🙁
    My esxi has enough time to make a shutdown of all VMs because I make a « upsdrvctl shutdown » 10 minutes after the ups runs on battery.

    Other point:
    I found the following vmware document:

    https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1013193

    *************************
    When virtual machines are running, ESXi/ESX might not clear the RAID controller’s cache if you shut down or reboot the ESXi/ESX host using these commands on the service console:

    reboot -f
    halt
    shutdown
    *************************

    • The command issued to shutdown ESXi is « poweroff ». This will shutdown all virtual machines before ESXi host only if wirtual machines have once been configured in the startup/shutdown sequence list (vmware bug ?). If you want to shutdown a VM, vmware tools need to be installed in it. If you can’t install vmware tools you can suspend VM instead of shutdown.

      So remember : if VM was never configured in the startup sequence it will be powerred off brutally. You must configure it in startup/shutdown sequence once, then you can remove it from the list and it will allways shutdown gracefully (if vmware tools installed).

      • And this is the show stopper:

        « if VM was never configured in the startup sequence it will be powerred off brutally »

        Because you can’t ensure that _all_ VMs are configured at the startup/shutdown sequence.
        What about VMs you need not often? Or only for testing?
        If a esxi shutdowns it should shutdown all VMs on a clean way (vmware tool installed).

        • I agree. According to startup/shutdown setup ESXi should apply the default behaviour for all VM not explicitely configured in this list. Unfortunately, it doesn’t, it just powers off the VM! IMO this is a vmware bug. I can’t correct it in a nut-client powerdown script.

  7. Hello René,
    Voilà j’ai un souchi 😉
    Pour mettre à jour mes esxi 5.5 à partir de vSphere, je dois désinstaller le client nut sinon les maj ne passent pas vers les esx.
    Or je me demande comment désinstaller nut dans la mesure où la paquet de base n’est plus dans /tmp (sans ôté).
    Donc ma question, s’il te plaît : je fais comment pour ma désinstall ? Je pousse le paquet 1.2 qui est la version que j’ai vraisemblablement installée, puis après décompactage je lance la commande de désinstall, ou bien il faut faire autre chose ?
    Merci beaucoup.
    Laurent

    • La commande pour désinstaller le client nut est :
      esxcli software vib remove -f -n upsmon
      Cela ne supprime pas les paramètres utilisateur tels que le serveur, compte, mot de passe,… donc si on réinstalle le client il retrouve sa configuration. En revanche il faudra peut-être le reconfigurer pour qu’il démarre automatiquement.

      Personnellement je fais les mises à jour de ESXi en ligne de commande où il est possible de passer le paramètre -f pour forcer les installations et ignorer l’avertissement de sécurité provoqué par le client nut.

      • Merci !
        La ligne de commande m’intéresse du coup…
        Tu as fait une doc sur ton blog, où je puisse trouver l’info ?
        BTW, j’espère que le « f » ne passe pas outre la demande de reboot, sinon il vaut mieux que je le sache avant :-/

        Laurent

  8. Heu… et le téléversement tu le fais comment ? Parce que j’ai vu qu’il faut le faire depuis vSphere, or la manip du « stage » me renvoie une erreur, comme quoi elle ne peut pas téléverser les patchs vers l’esx concerné….

    • Non, je n’update pas depuis vSphere. Je télécharge le correctif depuis le site de vmware, c’est un fichier zip et je le dépose sur un de datastores. Ensuite je lance la commande suivante sur ESXi :
      esxcli software vib update -f -d /vmfs/volumes/mondatastore/bundle-de-mise-a-jour.zip
      Ca ne reboote pas l’hyperviseur après l’installation du patch. Il inversera le bootbank et altbootbank pour revenir facilement a la version précédente en cas de soucis au reboot après le patch.

Laisser un commentaire

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