Arrêt d’un VMWare ESXi sur alerte onduleur

J’utilise un serveur VMWare ESXi 4.0 avec une licence gratuite. Cette licence, si elle permet de profiter de la virtualisation sur serveur, ne permet d’utiliser les API perl que pour interroger l’état du host et des machines virtuelles, elle ne permet pas de les éteindre. Mon installation dispose d’un onduleur géré par une machine physique grâce à un démon NUT (Network UPS Tools). Voici donc le moyen que j’ai trouvé pour stopper correctement mon serveur ESXi sur une alerte onduleur envoyée par un serveur NUT. Ceci fonctionne à l’identique avec les versions ESXi 3.5 et 4.0 .

Mise à jour : Un nouvel article décrit une méthode plus élégante qui permet d’installer le client nut directement dans l’hyperviseur ESXi 4 : Client NUT natif pour VMWare ESXi

Mise à jour 2 : Pour le client NUT natif sdous ESXi 5 voici un article dédié : Client NUT pour ESXi 5

Câblage

Un petit schéma pour vous aider à comprendre mon installation. Elles est très classique, rien d’extraordinaire : L’onduleur fourni la tension pour tous les équipements, il est relié via le port RS232 à une machine sous Linux sur laquelle tourne le service NUT maitre. Je ne traiterai pas de cette machine dans cet article.

Câblage Onduleur

Câblage Onduleur

Je supposerai que vous disposez déjà de votre serveur maitre NUT opérationnel. NUT est très facile à installer et à configurer, de plus un nombre important d’onduleurs sont supportés. Certaines distributions Linux (comme par exemple fedora) disposent déjà d’un package NUT installable qu’il faudra ensuite configurer.

Le principe

L’idée est de créer une machine virtuelle minimaliste sous Linux sur laquelle tourne un client NUT qui donnera l’ordre au host de s’éteindre en cas d’alerte critique de l’onduleur. Pour y arriver on procédera par étape :

  • Activer le service ssh sur le serveur ESXi
  • Créer la machine virtuelle Linux qui hébergera le client NUT
  • Autoriser les connexions ssh de cette machine virtuelle sur le serveur ESXi identifiées par une clé privée (pour éviter de saisir un mot de passe et permettre de lancer des commandes à distance) .
  • Choisir pour chaque machine virtuelle quelle action entreprendre lors de l’arrêt du host.

Description

Activer le service ssh sur le serveur ESXi

Sur la console physique du serveur appuyez sur les touches CTRL+F1, vous basculez sur un écran avec des messages d’information mais vous ne disposez pas de prompt de login. Tappez en aveugle le mot suivant : « unsupported » , un message d’avertissement et un prompt de login apparaissent. Logez-vous en saisissant le mot de passe d’administration, vous êtes logué root :

You have activated Tech Support Mode.
The time and date of this activation have been sent to the system logs.

Tech Support Mode is not supported unless used in consultation with VMware Tech Support. 
VMware offers supported, powerful system administration tools.  Please
see www.vmware.com/go/sysadmintools for details.

Tech Support Mode may be disabled by an administrative user.
Disabling requires a reboot of the system.  Please consult the ESXi
Configuration Guide for additional important information.

Editez le fichier « /etc/inetd.conf » (vi /etc/inetd.conf) et retirez le caractère # en début de ligne ssh (sous ESXi 4.0 vous pouvez également activer ssh sous IPv6 si vous utilisez ce protocole) :

...
# Remote shell access
#
ssh        stream        tcp        nowait        root        /sbin/dropbearmulti        dropbear  ++min=0,swap,group=shell -i -K60
ssh        stream        tcp6        nowait        root        /sbin/dropbearmulti        dropbear  ++min=0,swap,group=shell -i -K60
#telnet        stream        tcp        nowait        root        /bin/busybox        telnetd ++min=0,swap,group=shell
#telnet        stream        tcp6        nowait        root        /bin/busybox        telnetd ++min=0,swap,group=shell
...

Rebootez votre serveur ESXi et vous devriez désormais être capable de vous connecter via ssh directement sur le host. Connectez-vous root et utilisez le mot de passe d’administration.

Créer une machine virtuelle Linux avec un client NUT

Cette opération n’est pas obligatoire, une machine externe ou une machine virtuelle existante peut servir de client NUT. Il est toutefois indispensable que cette machine soit toujours activée pendant le fonctionnement du host ESXi.

Je vais traiter cette partie très rapidement. Juste pour information voici ce que j’utilise, il existe des tas d’autres configurations possible dont certaines sont certainement plus judicieuses. L’important pour moi était d’utiliser le mois de resources possibles sur le host :

  • Machine virtuelle mono processeur, 128 Mo de RAM, 1 disque dur virtuel SCSI de 3Go, 1 interface réseau
  • Distribution Linux Fedora 9 sans bureau graphique
  • Installation du client nut (yum install nut-client)

Autorisation des connexions ssh identifiées par une clé privée

C’est la partie la plus importante de l’opération. Vous devez générer une clé de type DSA sans mot de passe pour ssh sur le client. Dans la suite j’utilise le compte root pour lancer les commandes car c’est le compte utilisé par défaut par NUT pour lancer les commandes d’action.

[root@client ~]# ssh-keygen -q -d
Enter file in which to save the key (/root/.ssh/id_dsa):
Enter passphrase (empty for no passphrase): (ne rien saisir, taper sur entrée)
Enter same passphrase again: (ne rien saisir, taper sur entrée)

Utilisez le compte root Vous devrez créer un répertoire de travail pour y stocker les fichiers à transférer sur le host ESXi. Pour l’exemple ce répertoire sera « /tmp/vmesxi » et lancez ces commandes :

mkdir /tmp/vmesxi
cd /tmp/vmesxi
echo "My Customized ESXi 1.0 (01-01-2010)" > oem.txt   (texte libre, utilisé sous ESXi 3.5, s'affichera sur la console)
mkdir .ssh
chmod 700 .ssh
cp /root/.ssh/id_dsa.pub .ssh/authorized_keys
chmod 600 .ssh/authorized_keys
tar -czvf oem.tgz oem.txt .ssh

Le fichier oem.tgz est un des fichiers du firmware de ESXi qui permet aux constructeurs de serveurs de customiser le firmware. Si vous utilisez la version installable de ESXi vous pouvez écraser celui qui est présent sous ESXi par celui que vous venez de créer. En fait celui qui est livré initialement est un fichier tar.gz vide (pas de taille nulle, mais ne contenant aucun fichier).

Copie du fichier sur le host ESXi (remplacez 10.0.0.8 par l’adresse IP du host ESXi ou son nom FQDN) :

[root@client ~]# 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

Vous pouvez rebooter le host ESXi, une fois relancé vous retrouverez le répertoire .ssh à la racine du host avec votre fichier known_hosts à l’intérieur. Il est désormais pris en compte, faites donc un essai de connexion ssh depuis le client. Si tout est correctement installé il ne demandera pas de mot de passe.

ssh root@10.0.0.8

Script d’arrêt du host ESXi

Voici le script shell « esxi_suspend.sh » qui lancera l’arrêt du host sur incident électrique prolongé. Sauvegardez-le dans un fichier auquel vous donnerez les droits en exécution (chmod +x esxi_suspend.sh) :

#!/bin/sh
#
#  Script d'arret du serveur ESXi appelé lors d'une coupure électrique
#
#  Les machines virtuelles sont suspendues ou stoppées
#  Le serveur ESXi est stoppé

# Constantes configurables
ESXIHOST=esxi.mondomaine.net
ESXIUSER=root

ssh ${ESXIUSER}@${ESXIHOST} "vim-cmd hostsvc/autostartmanager/autostop ; poweroff"

# Relance du service de monitoring de l'onduleur
service ups restart

Dans le fichier de configuration du client NUT vous devez préciser le nom du script à lancer en cas l’arrêt imminent de l’onduleur. Sous fedora 9, l’emplacement de ce fichier est « /etc/ups/upsmon.conf » :

...
MONITOR onduleur@upsserver 1 upsuser upspass slave   # A corriger selon le nom de votre serveur NUT et du compte client
...
SHUTDOWNCMD "/chemin/complet/vers/esxi_suspend.sh"
...

N’oubliez pas de préciser au système qu’il faudra lancer le service client NUT au démarrage :

chkconfig ups on

Choix des actions d’arrêt pour chaque machine virtuelle hébergée sur le host ESXi

J’ai l’impression qu’il y a ici un bug avec les serveur VMWare ESXi 3.5 et 4.0 : tant qu’une machine virtuelle n’a pas été explicitement configurée pour démarrer automatiquement, aucune action n’est prise à l’arrêt du host, la machine virtuelle est brutalement éteinte. Vous devrez donc configurer temporairement chaque machine pour qu’elle se lance automatiquement au démarrage du host. Ensuite, une fois le choix validé, vous pouvez les reconfigurer pour revenir à la situation initiale pour les machines qui ne doivent pas démarrer avec le host :

Virtual Machine Startup and Shutdown Editor

Virtual Machine Startup and Shutdown Editor

Activez la prise en charge des arrêts/relances des machines virtuelles dans les préférences de ESXi. Choisissez un mode d’arrêt par défaut. Servez-vous des boutons Move Up/Move Down pour les placer au moins une fois dans la liste Any Order si elles sont dans l’état Manual Startup. Validez puis remettez-les à l’état Manual Startup. Si vous ne faites pas ça l’arrêt sera brutal pour ces machines. Vous pouvez éditer individuellement l’arrêt pour chaque machine :

  • Power off : Arrêt de type bouton OFF, l’os n’est pas arrêté correctement mais la machine virtuelle est correctement éteinte.
  • Suspend : Enregistrement de l’état de la machine, elle pourra reprendre son activité quand elle sera relancée. C’est la solution que je préfère.
  • Guest Shutdown : Arrêt propre de l’OS, uniquement possible si les vmware tools sont installés sur cette machine virtuelle

Vous pouvez tester votre procédure d’arrêt en lançant manuellement le script esxi_suspend.sh sur le client NUT. Il vous restera ensuite à vérifier que le client NUT reçoit bien l’ordre d’arrêt provenant du serveur NUT en cas de défaillance électrique prolongée.

13 réflexions sur « Arrêt d’un VMWare ESXi sur alerte onduleur »

  1. Bonjour, j’ai suivis votre tuto mais un problème survient lors de la création du script.
    J’ai créer mon script dans un répertoire à la racine de mon ESXi, mais après je ne sais pas quelle intitulé mettre exactement dans le ESXIHOST et dans le chemin du SHUTDOWNCMD … Si vous pouviez m’éclairer 🙂

    • Si vous devez utiliser un client NUT pour éteindre convenablement votre serveur ESXi utilisez plutôt la méthode décrite dans l’article Client NUT natif pour VMware ESXi qui est beaucoup plus propre.
      Sinon, dans cet article, vous n’avez aucun fichier à créer directement dans la racine de ESXi. Tout fichier ainsi créé est perdu au reboot. ESXIHOST est ne nom ou l’adresse IP du serveur ESXi. SHUTDOWNCMD est le chemin d’accès complet au script d’arrêt dans la machine virtuelle (pas dans le host ESXi).

      • Oui je voulais aussi utiliser l’autre méthode mais lorsque je télécharge le module que vous avez préparé, celui ci m’indique que l’archive est corrompue donc je me suis rabattue sur la votre première méthode.

        • Oh ! Grace à vous je vient de m’apercevoir qu’il y a effectivement un problème potentiel avec le fichier oem.tgz de l’autre post. J’ai modifié la configuration du serveur web il y a quelques temps pour autoriser la compression au vol. Du coup le fichier oem.tgz est compressé 2 fois ! En attendant que je corrige la paramétrie (ce soir probablement) voici ce qu’il faut faire :
          Télécharger le fichier oem.tgz et
          Décompresser le fichier avec gzip -d oem.tgz
          Vous obtenez un fichier oem.tar
          tapez : file oem.tar
          Si la commande file vous répond que c’est du « gzip compressed data » alors renommez-le en oem.tgz, cette fois il sera bon.

          La taille devrait être de 40871 octets
          En le soumettant à la commande md5sum vous devez obtenir la signature MD5 ef72e2a3665f78ff2943b29fe1762ff0

          Désolé, je serai plus prudent à l’avenir.

          • Il me met toujours que l’archive est corrompue xs j’ai dû louper quelque chose …

          • Je vient de faire un test en téléchargeant oem.tgz avec firefox et je ne vois aucun problème. En revanche avec IE le fichié est renommé oem.gz par le navigateur. Il suffit alors de lui rendre son extension tgz d’origine. Ensuite, pour extraire l’archive sous un linux il faut utiliser la commande : tar -xzvf oem.tgz

            Sinon, au cas où il aurait été décompressé par le navigateur, utiliser la commande tar -xvf oem.tgz

            Puis suivre le reste de la gamme (personnalisation de la configuration, regénération de l’archive et livraison sur le serveur).

          • Vous avez raison, aucun soucis avec Mozilla, voilà la 1ère fois que mon google chrome loupe quelque chose ^^. Je vais donc essayer votre 2ème méthodes. En tout cas merci beaucoup pour votre aide.

  2. Merci beaucoup pour votre aide. Maintenant le script fonctionne si je le lance manuellement mais je n’arrive pas à éteindre mes machines « proprement » lors d’une coupure de courant … J’ai installé l’Ups management mais sans réel succès …

    • Il y a un problème dans ESXi déjà présent dans les anciennes versions et qui n’a toujours pas été corrigé en 4.1 : Les machines virtuelles en mode « Manual Startup » ne suivent pas l’action par défaut lors d’une coupure. Je m’explique : dans les préférences de l’hôte il est possible de définir l’ordre de démarrage et d’arrêt des VM quand l’hôte démarre ou reboote, les machines qui ne sont pas soumises à un ordre sont stoppées salement. Pour contourner ce problème, il suffit de passer chaque VM dans la liste « any order », puis valider. Sortir la VM de cette liste pour la faire revenir dans la liste « Manual Startup » et cette fois ESXi se souviendra qu’il faut correctement éteindre cette VM.

  3. Bonjour,

    Merci pour votre procédure.
    Par contre, j’ai un souci après l’installation, je ne trouve pas les paramètres dans UserVars. (ESXi 5.1)

    Installation :

    /tmp # sh upsmon-install.sh
    Installation Result
    Message: Operation finished successfully.
    Reboot Required: false
    VIBs Installed: Margar_bootbank_upsmon_2.6.4-1.0.2vmw.500
    VIBs Removed:
    VIBs Skipped:

    Merci d’avance.

Laisser un commentaire

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