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.

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 :

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.