Dans un précédent article je vous présentait une solution pour éteindre automatiquement un serveur VMWare ESXi sur une alerte onduleur. Cette solution utilisait une machine virtuelle intermédiaire qui envoyait l’ordre d’arrêt par ssh au host ESXi. Ça marche mais ce n’est pas très élégant : une machine virtuelle de plus à maintenir et beaucoup de ressources sont utilisées juste pour attendre un évènement onduleur. Voici dont la méthode pour intégrer à l’hyperviseur ESXi 4.0 un client nut natif.
Mise à jour : Le module présenté dans cet article a été testé avec succès sous ESXi 4.1
Mise à jour 2: Pour ESXi 5.0 consultez plutôt l’article Client NUT pour ESXi 5
Principe
La procédure consiste à installer dans l’hyperviseur les binaires et scripts nécessaires à la réception des alertes onduleur. Là encore, le schéma des connexions ne change pas.
La principale différence c’est que c’est directement l’hyperviseur qui fait tourner le client nut et non une machine virtuelle. L’onduleur est surveillé par un serveur NUT. Cette fonction ne peut pas être assurée par l’hôte ESXi car les interfaces USB et RS232 ne sont pas utilisables (drivers et bibliothèques nécessaires non fournis).
Module
Vous pouvez télécharger le module que j’ai préparé ici : Télécharger “oem.tgz” oem.tgz – 39,91 Ko . Il a été compilé sous CentOS 5.4 32 bits, cet environnement utilise des versions de librairies identiques à ESXi 4.0 (glibc, libresolv)
Le module est installé grâce au fichier oem.tgz qui permet d’ajouter des fichiers à l’arborescence de l’hyperviseur. Dans le fichier que je vous ai préparé vous trouverez les fichiers suivants :
- /bin/upsc : client nut interactif (pour tester la liaison avec le serveur nut)
- /bin/smtpblast : utilitaire pour envoyer des mails d’alerte sur évènement onduleur important. Cet utilitaire fait partie des smtptools 0.2.3 (ne trouvant pas les sources sur le site officiel je les ai récupérées à partir des srpm d’une distribution Mandriva libre).
- /etc/ups/notify.sh : script qui envoie un mail à l’administrateur de domaine root@votredomaine en cas d’évènement onduleur important.
- /etc/ups/upsmon.conf : fichier de configuration du client nut. Vous devrez le modifier pour lui indiquer quel est votre serveur nut.
- /etc/rc.local.d/S70upsmon.sh : script de lancement du client nut au boot de ESXi
- /oem.txt : description du module (uniquement utilisé sous ESXi 3.5)
- /sbin/upsmon : client nut (version 2.4.3)
- /usr/lib/libupsclient.so.1.0.0 : librairie nécessaire aux clients nut avec ses liens symboliques
Configuration
Vous devez impérativement configurer le client nut avant de l’installer. Vous devez extraire le contenu du fichier oem.tgz pour modifier le fichier etc/ups/upsmon.conf
Une fois le fichier à votre goût vous devrez recréer l’archive oem.tgz
Personnellement j’utilise une machine linux pour réaliser ces opération. La suite de commandes est décrite ici bas mais je pense que vous savez déjà comment faire. Je suppose que vous gardez une copie du fichier oem.tgz dans le répertoire initial.
mkdir oem cd oem tar -xvf ../oem.tgz vi etc/ups/upsmon.conf (... vous éditez le fichier de configuration ...) tar -cvf - * | gzip -9 > ../oem.tgz cd ..
Le paramètre que vous devez configurer selon le nom de votre serveur NUT et le compte client à utiliser est le suivant :
MONITOR onduleur@upsserver 1 upsuser upspass slave
Vous pouvez également éditer le fichier /etc/ups/notify.sh pour forcer l’envoi de mail à une adresse de votre choix. Par défaut le script envoie tout à root@votredomaine
La liste des évènements pour lesquels un mail est envoyé est dans le fichier upsmon.conf . A chaque ligne NOTIFYFLAG correspond un évènement possible et l’action associée (IGNORE pour ne rien faire, EXEC pour envoyer un mail). Reportez-vous à la documentation de NUT pour connaitre la signification des évènements.
Installation
Activez l’accès ssh à votre host ESXi si ce n’est pas déjà fait. Vous pouvez consulter cet autre article pour savoir comment procéder.
Copiez le fichier oem.tgz dans le répertoire /bootbank du host ESXi (remplacez 10.0.0.8 par l’adresse IP du host ESXi ou son nom FQDN).
[root@hostname ~]# scp oem.tgz root@10.0.0.8:/bootbank/oem.tgz
The authenticity of host '10.0.0.8 (10.0.0.8)' can't be established.
RSA key fingerprint is c7:46:3c:a8:f4:..:..:..:..:..:..:12:62:59:ff:fc.
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.
root@10.0.0.8's password: (saisir le mot de passe administrateur ESXi)
oem.tgz 100% 735 0.0KB/s 00:00
Rebootez le host ESXi et vérifiez que le client démarre correctement et se connecte à votre serveur NUT (voir dans les logs du serveur).
Astuces
Si votre fichier oem.tgz pose problème et qu’il empêche le host ESXi de démarrer (écran rose par exemple) : Tapez shift+o lors du lancement de ESXi et saisissez l’option de boot « noOem » . Le fichier oem.tgz ne sera pas déployé (cette fois seulement).
Si vous utilisez déjà un fichier oem.tgz non vide vous devrez certainement les fusionner pour continuer à bénéficier des apports de l’ancien oem.tgz. Vérifiez son contenu sur le host ESXi avec la commande « tar -tzvf /bootbank/oem.tgz«
Utilisez l’onglet de configuration du host ESXi dans vSphere Client 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.
Pour estimer le temps nécessaire au serveur pour s’éteindre sur alerte onduleur tapez la commande « upsmon -c fsd » sur le host ESXi (par ssh ou sur la console). La procédure d’arrêt est immédiatement lancée.
Les exécutables fournis sont compilés en 32 bits. Dans un premier temps je les avais compilés en 64 bits pensant que sous VMWare ESXi 4.0 le noyau était 64 bits uniquement. Je me trompais, en 64 bits rien ne fonctionne. Du coup, la procédure fonctionne peut-être sous VMWare ESXi 3.5 (je n’ai pas cette configuration, je n’ai donc pas testé). Vos retours sont les bienvenus.
Bonsoir,
J’ai voulu suivre la procédure mais pas de bol, il y’a eut une coupure électrique et bing, le fichier oem est en place mais pas configuré comme il faut.
Donc petit problème au redémarrage, j’ai ce message :
PANIC : cannot open oem.tgz (tout sa en rouge).
J’ai donc tenté d’entrer : noOem dans le boot mais sans succès.
(Esxi 4.1).
Une solution ?
Merci par avance.
Oh, dommage ! Bon, dans le doute je viens de refaire le test. C’est bien l’option noOem (ou nooem, la casse importe peu) qui permet d’ignorer le chargement du fichier oem.tgz. Pour saisir l’option : tout au début du boot presser shift+o, un message s’affiche alors :
Press Enter to Boot
Enter advanced options
->
Il est possible que des options soient déjà présentes en fonction de votre configuration. Ajouter alors nooem (attention clavier qwerty) et taper « enter » 2 fois pour lancer le boot.
Sinon, il est possible de booter sur le firmware alternatif en tapant shift+r au boot. La machine va alors booter avec la version de ESXi précédent la dernière mise à jour. On peut alors se loguer sur la machine, faire le ménage ou terminer l’installation (attention cette fois c’est dans /altbootbank) puis rebooter la machine et refaire shift+r pour revenir au firmware initial. Ceci ne fonctionne que si le système a déjà été mis à jour au moins une fois sinon le firmware alternatif sera vide.
Sinon, il est possible alors de monter le disque boot sur un autre système et l’éditer. Le filesystem est du vfat, donc éditable depuis un windows. C’est la partition qui contient les fichiers tgz (dont le oem.tgz). Il y a deux partitions comme ça, une pour le firmware nominal et l’autre pour le firmware alternatif. On passe de l’un à l’autre à chaque mise à jour du firmware ESXi.
Bonsoir,
Encore merci pour l’aide, cela ne c’est pas vraiment passé comme expliqué.
J’ai donc du avoir recours au shift + r, l’esxi à bien démarré comme il fallait (en 4.0). Je me suis connecté en ssh, je suis allé dans le /altbootbank malheureusement aucune trace du oem.tgz ou du paramètre oem dans le boot.
Je suis donc repartis vers le /bootbank et la il y avait bien un oem.tgz (donc hop supprimé) puis j’ai édité le boot.cfg et la aussi il y avait le —oem.tgz donc hop supprimé.
Redémarrage je fais de nouveau un shift +r et la : c’est la « catastrophe » il me dit :
WARNING :
No valid fallback hypervisor found
Press Enter to continue
Donc je vais démarrer sur cette version et tenter de nouveau l’update. on verra bien.
Et encore merci.
Il ne jamais supprimer oem.tgz, il fait partie du firmware. Et dans les paramètres non plus, il faut le conserver. Ce fichier est un tgz vide mais sa présence est obligatoire. Si tu as modifié le bootbank alors tu viens de corrompre le firmware 4.0, c’était sur le altbootbank (4.1) qu’il fallait rétablit le oem.tgz (en le recopiant du bootbak par exemple).
Je n’ai pas fait le test en 4.x mais en 3.5 j’avais essayé de modifier la liste des tgz dans le boot.cfg et le système n’avait pas voulu, il vérifie la présence de 7 paramètres tgz pas un de plus ni un de moins.
Si tu peux encore booter il faudra rétablir cette situation. Sinon tu dois monter le disque sur un autre système pour éditer le contenu (les partitions bootbank et altbootbank font 256Mo chacune et le filesystem est du vfat).
Merci pour ces précisions, donc je ne prends pas le risque de tourner sur un système bancale, je réinstalle toute de suite.
Merci pour tout.
Si tu réinstalles ESXi à partir du CD (téléchargeable depuis le site de vmware) tu perdras les paramètres de ta configuration (réseau, vswitchs, groupes de VM, etc…) En revanche les datastores resteront intacts, il faudra alors réimporter les VM avec le client vSphere.
Me revoila après qq mois !
Le NFS en user-space fonctionne plutôt bien sur un ESXi 4.0 mais a toujours le défaut de ne pas supporter la procédure READDIRPLUS. Il est ainsi impossible de l’utiliser pour faire des backups de VMs hébergées sur un Esxi 4.1 (OK en 4.0). De même, impossible d’utiliser des vmdk sur le NFS (pour par exemple, sécuriser une VM ou faire un transfert d’une VM via 2 disques en raid 1 soft).
Une possibilité : compiler et ajouter le module NFS au kernel d’ESXi car celui-ci gére READDIRPLUS. Il semble possible de compiler des modules dans CentOS pour les utiliser ensuite dans ESXi : http://www.bytedynamix.com/?p=77
Et ce doit d’ailleurs être le principe de constitution des modules réseau supplémentaires disponibles sur vm-help !
A voir…
Nota : visiblement, les anciennes versions d’ESX avaient originellement la possibilité d’héberger un serveur NFS mais ce n’est plus le cas…
Effectivement le service NFS en user-mode a ses limites. Je vais regarder de plus près comment ça se passe pour compiler un module dans le noyau. J’avais déjà fait une tentative par le passé mais sans succès. C’est bien un noyau linux mais il a été grandement nettoyé pour ESXi et sa compilation est inhabituelle. Le code source étant disponible chez VMWare je vais tenter de m’y remettre.
Je suis en train de m’installer une CentOS 5.4 pour voir si la méthode indiquée plus haut est OK.
Mais pendant ce temps, je vais essayer de voir ce que donne le chargement direct dans /usr/lib/vmware/vmkmod/ d’un nfsd.o issue de CentOS !
J’ai regardé comment faire : chargement par esxcfg-module -e en auto, ou manuellement par vmkload_mod
A suivre…
A+
Excellent cet article, je vais tester tout ça …
En revanche, petite question tout même, vu que l’esxi s’arrête proprement, la coupure de courant puis le retour de la « lumière » vont-ils bien le faire redémarrer (j’ai activé l’option dans le bios qui va bien) ?
Merci !
Lors d’une panne électrique 3 scénarios sont possibles :
1 – La coupure est courte : nut annonce que l’alimentation est sur batterie mais le courant revient avant que le seuil critique de charge batterie soit atteint. Aucune procédure d’arrêt n’est enclenchée. La coupure de courant est ‘transparente’
2 – La coupure est longue : nut annonce que l’alimentation est sur batterie, puis une fois le seuil crique atteint ordonne à tous ses « esclaves » d’entamer une procédure d’arrêt. Le serveur nut s’éteint lui-même et transmet un ordre de type ‘/usr/bin/upsdrvctl -u nut shutdown‘ à l’onduleur pour couper réellement le courant en sortie d’onduleur. Quand le courant est de retour, l’ensemble est remis sous tension et si les BIOS le permettent, on peut configurer les machines pour redémarrer. Un serveur ESXi va relancer les machines virtuelles qui sont en démarrage automatique une fois que l’hyperviseur est chargé.
3 – La coupure est ‘moyenne‘ : nut annonce que l’alimentation est sur batterie, puis une fois le seuil crique atteint ordonne à tous ses « esclaves » d’entamer une procédure d’arrêt mais le courant revient alors que les machines sont en train de stopper. Là tout dépendra de l’onduleur et de son « intelligence ». L’onduleur que j’utilise (un APC SmartUPS-3000) sait s’éteindre, attendre 1 minute puis se rallumer pour provoquer un arrêt réel d’alimentation. Les serveurs qui ont l’option BIOS de relance après coupure secteur vont donc repartir. Certaines de mes machines n’ont pas cette option mais ont la capacité WakeOnLan sur leur interface réseau. Le serveur nut est donc programmé pour envoyer sur le réseau une trame WOL a destination de ces machines.
Une autre fonction « intelligente » d’un onduleur est d’attendre que le courant soit effectivement revenu après 1 ou 2 minutes pour ne pas relancer tout le parc si le courant n’est revenu que brièvement car les batteries sont à plat et ne pourront pas tenir un nouveau cycle d’arrêt/relance.
Merci pour les explications !
Je viens d’installer le client NUT et tout semble fonctionner correctement (cf. upsmon).
Je vais simuler des coupures de courant pour voir comment l’ESXi se comporte !
Merci encore 😉
Re,
Comment ça se passe lorqu’on passe de ESXi 4.1 à ESXi 5.0 ?
Je n’en sais rien. Je ne suis pas passé sous ESXi 5.0 car les CPU de mon serveur ne sont pas compatibles. Si quelqu’un a essayé, je veux bien qu’il réponde à cette question : le paquetage est-il compatible ESXi 5.0 ?
J’ai testé sur ESXi 5.0, mais le oem.tgz n’est pas chargé.
Avez-vous des méthodes pour compiler les binaires? Je vais l’essayer sur CentOS 6.2 x64.
Je ne peux pas faire le test sous ESXi 5.0. Sous ESXi 4.x il fallait compiler en 32 bits, les binaires 64 bits n’étaient pas utilisables. Toutefois je compte remplacer mon serveur dans quelques temps et je pourrai faire le test.
Je viens de lire que sous ESxi 5.0 il est nécessaire de présenter le package sous un nouveau format pour qu’il soit reconnu. Il existe un outil sous licence GPLv3 qui permet d’automatiser la création d’un tel package. Je vous invite à regarder le site http://v-front.blogspot.com/p/esxi5-community-packaging-tools.html
J’ai fait un test rapide avec les binaires de Ubuntu x64 10.01, et ils semblent fonctionner.
Comme je l’ai besoin d’une solution rapide pour ESXi 5.0, et je n’avais aucune chance de redémarrer le ESXi hôte physique, j’ai écrit un script Perl qui utilise le protocole SSH pour se connecter dans la boîte ESXi, fonctionne des ‘powerOffVms’ puis à un arrêt obligé de courir VM (il attend pour eux d’arrêter), suivie de ‘poweroff’ (ce qui fait réellement la même chose que ‘powerOffVms’, mais aussi s’arrête la boîte ESXi).
Ce script est utilisé comme SHUTDOWNCMD dans ma configuration NUT central.
J’ai désormais un serveur ESXi en version 5.0 et j’ai réussi à porter le client NUT natif. Toutefois l’installation est différente et il y a deux systèmes de sécurité à contourner : le firewall, nouveau dans ESXi 5 et une sorte de SELinux qui restreint les droits des exécutables. Je posterai un nouvel article qui explique comment faire.
La solution pour ESXi5 est stable. Nouvel article mis à jour avec une intégration directe dans ESXi pour une configuration et un contrôle du service depuis le client vSphere : Client NUT pour ESXi 5.0
Ping : Installing NUT on ESXi 4.1 – Darkglade
Bonjour,
Après avoir configurer mon client NUT sous esxi 7.0.3
le fichier syslog.log m’indique ceci :
UPS [ups@l’ip_de_mon_esxi]: connect failed: Connection failure: Connection refused
Dans le champ UserVars.NutUpsName, j’ai renseigner : usp@l’ip_de_mon_esxi
Il s’agit d’un eaton elipse eco 800 en usb.
Ce qui m’embête c’est la partie UserVars.NutPassword et UserVars.NutUser je ne voit pas quoi mettre dedans car l’onduleur ne demande pas de MDP pour sa connexion sur un port usb classique sous windows par exemple.
Merci pour les informations de configuration.
A priori vous n’avez pas compris comment fonctionne NUT. Il vous faut un serveur NUT, sur lequel est physiquement rattaché l’onduleur en USB par exemple. Ce billet ne trite que de la partie cliente installée sur l’ESXi. L’onduleur n’est pas raccordé à l’ESXi. Certaines personnes utilisent un NAS synology pour tenir le rôle de serveur NUT car ce service est inclus dans le firmware.