Client NUT natif pour VMWare ESXi 4

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.

Câblage Onduleur

Câblage Onduleur

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 – 40 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.

39 réflexions sur « Client NUT natif pour VMWare ESXi 4 »

  1. Salut René,
    Dans le même style que ton client natif, je suis intéressé par l’utilisation d’un serveur NFS natif en user space, ceci afin qu’un ESXi puisse directement se sauvegarder dans un autre ESXi et que la bascule d’une VM soit la plus simple et rapide possible.
    Je vais regarder ce qu’il existe sous CentOS 5.4 32 bits. Si ca peut intéressé qqu’un…

    A+

    • On trouve bien nfs-utils-1.0.9 dans les sources GNU de ESX-4.0 avec tous les patchs utilisés par l’équipe de VMWare pour sa compilation. Je ne sais pas si ça peut être utile.

  2. C’est pour la partie client, j’imagine.
    Les binaires RHEL 5 doivent aussi fonctionner sur ESXi4, vu que CentOS est basée dessus. Donc je vais voir du côté de RPMFind, si je trouve mon bonheur.
    Sinon ta compilation avait nécessité les sources GNU de ESX ?

    • Non, pas besoin des sources GNU de ESX pour compiler. J’ai juste respecté les répertoires de destination dans les paramètres des scripts configure pour que chaque outil sache retrouver ses fichiers de configuration. Les binaires RHEL5 ou CentOS5 devaient fonctionner, le seul soucis ce sont les arborescences et les dépendance. Tu peux utiliser la commande ldd sous CentOS ou RHEL pour connaitre les librairies qui sont utilisées par les binaires.

  3. Merci de l’info. Je pensais plutôt partir vers :
    http://unfs3.sourceforge.net/ qui est beaucoup plus répandu…

    La mise en place d’un serveur NFS serait, je pense, une petite révolution pour un usage facile et free de ce super soft qu’est ESXi : sauvegarde croisée sur 2 ESXi, quick migration sans NAS/SAN, … !

    A+

    • Il faut dire que je n’ai pas cherché longtemps, j’ai juste essayé le premier projet NFS user-space que google m’a rapporté. Je vais jeter un oeil à celui là. A priori il me semble plus aboutit que NFS-Ganesha.
      Le problème va être de configurer les répertoires à exporter. Il faudra éditer le fichier exports avant de le placer dans le oem.tgz et il sera donc dépendant le la machine. A moins que l’on exporte systématiquement tous les datastores locaux en les trouvant dans le script de lancement du serveur NFS. J’avais jéjà ce problème avec le client nut, son fichier de configuration doit être édité. Si seulement il était possible d’ajouter une interface (onglet?) au client vSphere… VMWare le fait c’est donc qu’il y a un moyen d(y arriver. Est-ce documenté ? Je vais creuser.

  4. Pas besoin de configuration pour moi, je pense exporter /vmfs/volumes/ donc tous les disques seront là. Et si besoin de modif, un petit « echo xxx > /etc/exports » placé dans rc.local pourrait faire l’affaire plus simplement, non ???

    J’imagine que faire une interface dans le client Vsphere, ca doit être un peu coton, et pas juste un petit fichier xml !!! 😉

    • Voici les premiers résultats de mes tests :
      – J’ai réussi à compiler et à faire fonctionner UNFS3 nativement sous ESXi. J’ai été très étonné, l’exécutable est tout petit, à peine 78ko, c’est parfait pour un service embarqué.
      – Il n’y a pas de service portmap/rpcbind sous ESXi. J’ai lancé le serveur unfsd avec l’option -p pour ne pas s’enregistrer au portmapper.
      – Il n’y a pas de service syslog sous ESXi. IL faut lancer le serveur unfsd avec l’option -d (mode debug). Au final pour lancer le service il faut lancer unfsd -p -d >/dev/null 2>&1 &
      – Le fichier /etc/exports que j’ai utilisé pour mes tests ne contient qu’une ligne d’export (en read-only pour commencer) : /vmfs/volumes (ro)
      – Les tests montrent que le service ne fonctionne qu’en IPv4 (pas de support IPv6 dans UNFS3)
      – Pour monter le répertoire exporté sur un linux client il faut utiliser la ligne de commande suivante : mount -o ro,udp,port=2049,mountport=2049,nolock esxiserver:/vmfs/volumes /mnt
      – Explication : ports en dur car pas de portmapper. préciser tcp ou udp pour prendre en compte les paramètres port. nolock car UNFS3 ne sait pas gérer les locks nfs.
      – L’export de /vmfs/volume fonctionne mais c’est pas terrible car les sous répertoires sont des filesystems différents, la navigation dans les sous répertoires ne fonctionne donc pas bien. Ca fait planter la commande df sur le client. En revanche quand on monte directement /vmfs/volumes/12345678-18273645-abcd-1234567890ab alors tout fonctionne correctement sur le client même la commande df.

      Je n’ai pas fait de tests en écriture, ni de tests entre deux ESXi (je n’en ai qu’un !). Le service est facile à encapsuler dans un oem.tgz, trois fichiers suffiront je pense : l’exécutable, le fichier exports et un script de lancement au boot.

  5. Ca ne traine pas avec toi, et en plus, cela fonctionne!
    Excellent !

    Par contre, pour un usage d’ESXi vers ESXi, j’imagine que le portmapper est obligatoire, ESXi ne pouvant définir d’option particulière…
    Pour les noms de volumes dans /vmfs/volumes, on doit pouvoir utiliser Disk1…DiskX, il suffit alors de nommer les disques de la bonne facon dans le client VSphere pour pouvoir y accéder directement via l’export NFS.
    Tu pourrais me mettre à dispo ton résultat STP ?

    • Moi j’avais juste essayé d’installer rpcbind qui est le successeur de portmap et qui ajoute le support de IPv6. Il compile bien, se lance sous ESXi, le serveur unfs3 s’enregistre mais le client ne parvient pas à se conencter. J’ai un message d’avertissement au lancement de rpcbind que je n’arrive pas à comprendre.

  6. Sans portmap sur le serveur (unfsd -d -p), l’ESXi essayant de se connecter au serveur NFS me donne :
    Create NAS datastore esxi-2
    Error during the configuration of the host: NFS Error: Unable to Mount filesystem: Unable to connect to NFS server

    Avec :
    Create NAS datastore esxi-2
    Error during the configuration of the host: Unable to get Console
    path for Mount

    Il faut que j’essaye avec un autre client NFS…

  7. Finalement, c’est bien fonctionnel avec le portmap de CentOs, si je précise bien le sous-répertoire comme par ex : /vmfs/volumes/Disk1.
    Cool !

    Par contre, le soucis est que l’on ne peut pas voir le contenu du répertoire NFS via le serveur unfs (procédure READDIRPLUS manquante), même si tout le reste est ok …
    Cf ici :
    http://communities.vmware.com/message/1149377#1149377
    Mais ce n’est pas forcément bloquant, le fonctionnement parait ok. A voir sur la durée !

    Attention, c’est assez étrange, si unfs n’est pas lancé, la conso CPU de portmap est énorme : un coeur complet !

    • Tu as pas mal testé, bravo. Pour ma part je ne peux pas faire de tests entre deux ESXi car… je n’en ai qu’un ! De plus ce qui me gêne avec cette solution est la non compatibilité avec IPv6.

  8. Ping : 為ESXi新增NUT服務 | 不專業網管筆記

Laisser un commentaire

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