HP on Zwindler's Reflection

Configurer l’ILO depuis ESXi (et sans reboot !)

Thu, 15 Jun 2017 12:00:02 +0000

Un KVM sur IP pour les contrôler tous

Une des fonctionnalités vitales pour l’administrateur de serveurs (physiques) est la capacité de pouvoir réaliser des modifications sur un serveur comme si on était physiquement devant la machine, vissé devant le kit clavier-souri-écran. Non, ce n’est pas (que) de la flemme. On ne peut pas toujours aller en salle serveur dès qu’un serveur a besoin d’une maintenance !

Ça c’est ce qu’on voit dans les séries TV, des techies qui tirent des KVM intégrés dans les racks pour intervenir. Ça arrive parfois, mais en vrai, mais 95% du temps on ne va pas jusqu’au datacenter, on utilise l’ILO ;-)

Ces technologies sont particulièrement utiles lorsque les systèmes d’exploitation sont crashés et que la seule solution pour reprendre la main sur le serveur est de le rebooter en appuyant virtuellement sur le bouton Power.

Dans les technos du marché, on peut citer ILO (pour Integrated Lights-Out) chez HP, iDRAC chez Dell-EMC, mais il existe bien d’autres solutions plus ou moins avancées.
Pour la route je citerai les technos que j’ai envisagé pour mon serveur perso, à savoir BMC sur certaines cartes mère Asrock, le protocole IPMI, ou alors la solution d’Intel AMT disponible sur les i5 et plus pour peu que vous ayez la bonne carte mère compatible « vPRO ».

Aparté : vous avez peut être entendu parler d’AMT récemment à cause de plusieurs failles qui ont rendu nombre de systèmes vulnérables (ici et plus récemment ici).

ILO : un 2ème OS en parallèle

Alors évidemment pour que ça marche, ça nécessite nécessairement que l’ILO (ou équivalent) fonctionne en parallèle de l’OS principal du serveur. C’est ce qui différencie l’ILO et l’iDRAC de Remote Desktop Protocol de Micro$oft ou VNC, qui ne vous servent plus à rien en cas de plantage ou d’extinction du serveur.

Mais qui dit système parallèle dit potentiellement que l’un ne puisse pas communiquer avec l’autre ! Pour revenir à mon exemple de l’ILO d’un serveur ESXi, généralement la première configuration (adresse IP, etc) se fait en interrompant la séquence de boot du serveur. En théorie, si on voulait faire une modification a posteriori de la même manière, il serait donc nécessaire de rebooter le serveur ESXi et donc de couper toutes les VMs qui sont hébergées dessus.

Heureusement, pour éviter de devoir faire ça, HP a mis à disposition des outils ! Et en plus, ces binaires sont directement intégrés dans la version modifiée de l’ISO ESXi d’HP.

Pour ceux qui ne savent pas de quoi je parle, il s’agit d’images dites « custom HP » et qui contiennent notamment des outils HP dédiés à l’administration et à l’intégration dans l’écosystème HP, mais surtout les pilotes compatibles avec le matériel HP. Cette version custom est donc celle qui est conseillée si vous avez un serveur HP, même si elle n’est pas exempte de bugs parfois !!! Vous pouvez les retrouver en recherchant dans Google « ESXi HP custom » ou sur le site d’HPe.

C’est d’ailleurs ces modifications qui permettent de remonter des informations sur l’état de santé du serveur physique dans les données de vSphere.

Piloter l’ILO depuis l’OS de l’ESXi

Rentrons dans le vif du sujet. Ça dépend des versions de vSphere (5.5, 6.0, 6.5), mais en version 6.0, sur les images ESXi custom HP, les binaires spécifiques sont déposés dans le dossier /opt/hp/tools. Le binaire qui nous intéresse est hponcfg.

~ # cd /opt/hp/tools
/opt/hp/tools # ls
conrep hpbootcfg hponcfg hptestevent_esxcli
conrep.xml hpbootcfg_esxcli hptestevent

Pour modifier la configuration, le plus simple est d’exporter la configuration actuelle, de la modifier, puis de la réimporter. On peut l’exporter avec la commande suivante :

/opt/hp/tools # ./hponcfg -w /tmp/current_ilo.cfg
HP Lights-Out Online Configuration utility
Version 4.4-0 (c) Hewlett-Packard Company, 2014
Firmware Revision = 1.81 Device type = iLO 2 Driver name = hpilo
iLO IP Address: x.x.x.x
Management Processor configuration is successfully written to file "/tmp/current_ilo.cfg"

Et si vous regardez le contenu de ce fichier, vous aurez un retour similaire :

/opt/hp/tools # cat /tmp/current_ilo.cfg
<!-- HPONCFG VERSION = "4.4-0.0" -->
<!-- Generated 5/9/2017 9:56:44 -->
<RIBCL VERSION="2.1">
<LOGIN USER_LOGIN="Administrator" PASSWORD="XXXXXXXX">
[...]
<RIB_INFO MODE="write">
<MOD_NETWORK_SETTINGS>
<SPEED_AUTOSELECT VALUE = "Y"/>
<NIC_SPEED VALUE = "10"/>
<FULL_DUPLEX VALUE = "N"/>
<IP_ADDRESS VALUE = "x.x.x.x"/>
<SUBNET_MASK VALUE = "255.255.255.0"/>
<GATEWAY_IP_ADDRESS VALUE = "x.x.x.y"/>
<DNS_NAME VALUE = "ILO-XXXX"/>
[...]

Il ne vous reste plus qu’à modifier ces valeurs pour refléter vos nouveaux besoins et de l’appliquer avec la commande suivante :

./hponcfg -f /tmp/current_ilo.cfg

Source

Le tutoriel sur VMwarearena (EN)

Mise à jour HP VSA StoreVirtual : site FTP HP.COM hors service

Tue, 21 Feb 2017 13:00:36 +0000

Ma CMC pour HP StoreVirtual ou VSA ne parvient plus à accéder aux mises à jours !

Aaaah, ça faisait longtemps que je n’avais pas dis tout le bien que je pensais d’HPe et notamment d’HP VSA. Mais l’actualité m’a poussé, entre autres choses, à relancer des projets en stand-by.

Note : pour ceux qui ne sauraient pas de quoi je parle, je pense au rachat Simplivity par HPE pour 650 M$ le mois dernier. Racheter le n°2 lorsqu’on a un produit maison envoie un signal clair à tous ceux qui ont investit dans HP VSA => dommage pour vous !

Aujourd’hui, nous avons un cluster HP VSA qui nécessite un petit upgrade avec l’ajout de 2 nœuds supplémentaires. Histoire de faire les choses bien, j’ai voulu m’assurer que les nœuds étaient correctement à jour et quelle n’a pas été ma surprise quand j’ai découvert que la console n’arrivait même plus à contacter le serveur contenant les mises à jour !

Où sont ces mises à jours ?

Pour simplifier le processus de mise à jour des nœuds StoreVirtual, on utilise la console centralisée CMC -qui peut être installée sur un Linux ou un Windows-. Cette console a l’avantage de servir de pivot pour télécharger les patchs depuis un seul et même endroit (dans mon cas, un serveur Windows).

Dans ce cas-là, c’est bien le client (CMC) qui réalise le téléchargement, pas les serveurs VSA.

Et depuis quelques semaines (mois?), visiblement ça ne marche plus, avec un message qui laisse penser (à tort!) à un souci de connectivité Internet entre mon serveur Windows et les serveurs d’HP.

Une partie de la réponse se trouve dans ce post du forum de la communauté HPE.

Check your upgrades.xml file in the download folder. One of the updates from HP added an incorrect FTP address to the top of the section.

En allant fouiller dans le dossier d’installation de la console CMC, j’ai vite compris le problème. Les URLs contenues dans le fichier upgrades.xml pointent vers un FTP hébergé par hp.com.

J’insiste sur HP car il faut bien faire la distinction entre HP et HPe, la société HP ayant effectué sa scission entre Hewlett Packard et HPe l’an dernier. Le client CMC avait d’ailleurs été mis à jour entre la 12.5 et la 12.6 pour retirer toutes les références et les images HP pour les remplacer par la charte graphique HPe !

C:\Program Files (x86)\HP\StoreVirtual\UI\downloads\upgrades.xml
[...]
<DownloadURLs>
<URL>ftp://ftp:cmcdnlds@ftp.hp.com/pub/hp_LeftHandOS/</URL>
[...]

Pour vérifier mon intuition, je suis allé directement parcourir le FTP et effectivement, il n’y a plus de dossier hp_LeftHandOS sur ce FTP.

HPe a donc migré tout simplement son FTP vers le site d’HPe et le client ne peut juste pas se mettre à jour…

… Mais ils n’ont pas mis à jour le client pour qu’il pointe sur HPe au moment de la mise à jour 12.5 vers 12.6 quand ils ont changé la charte graphique.

Non non. Ils ont migré leur FTP après.

Résolution

Le problème est fort heureusement simple à résoudre. Il suffit d’aller chercher la dernière version de la CMC sur le site d’HPe.

Fermez la CMC, allez chercher la dernière version (lien mort, pas disponible sur Internet Archive) et installez la.

Bon à date l’URL de téléchargement que je vous donne est bonne mais avec HPe on est jamais trop sûr que ça dure donc vous m’excuserez si le lien est cassé à l’avenir ;-).

Une fois installée, la nouvelle version devrait maintenant se connecter sur le bon site.

Pour information, la connexion se fait même maintenant en HTTPS et non plus en FTP, comme on peut le constater dans le fichier upgrades.xml.

[...]
<DownloadURLs>
<URL>https://downloads.hpe.com/pub/StoreVirtual/CMC/</URL>
[...]

Comme quoi, il n’y avait vraiment aucune chance que ça fonctionne avant mise à jour…

Erreur hpssaduesxi et esxcli depuis vSphere 6

Sat, 30 Jan 2016 14:00:16 +0000

Contexte

J’ai eu une petite mésaventure avec mes amis d’HP lors d’un incident sur une plateforme HP VSA storeVirtual et j’ai perdu pas mal de temps avec l’utilitaire hpssaduesxi qui ne fonctionnait pas.

Rapidement pour ceux qui ne savent pas de quoi il s’agit, c’est le pendant virtuel de la solution de virtualisation du stockage HP LeftHand (appliances physiques).

Vos nœuds de compute (hyperviseurs) ESXi ou Hyper-V distribuent la totalité du stockage interne ou DAS (ou autre) à une machine virtuelle (HP VSA, 1 pour chaque serveur). Elles se coordonnent ensuite en cluster pour vous fournir un espace de stockage réparti sur tous vos serveurs. Cela permet entre autre d’obtenir à moindre cout du stockage hautement disponible et scalable.

Je reviendrais peut être là dessus dans un autre article.

hpssaduesxi, esxcli et vSphere 6

Comme je le dis en introduction, j’ai eu incident lié au stockage après l’intégration de ma plateforme HP VSA et j’ai donc du ouvrir un ticket auprès de mon support HP.

Sans surprise, la première chose qu’on m’a demandé de faire pour pouvoir traiter ma demande était de collecter les logs de la carte RAID des serveurs ESXi concernés (rapport ADU de son petit nom). Si vous êtes familier des serveurs HP, vous savez qu’un des moyens de récupérer ces informations est de lancer l’utilitaire hpssadu, présent sur les différents OS lorsque vous installez les pilotes HP Smart Storage.

Dans mon cas, on m’a demandé de réaliser cet extrait de configuration et de logs à partir d’un serveur Microsoft ayant accès aux serveurs et la CLI VMware d’installée.

Ok, pas de soucis, le technicien me donne la procédure. J’installe la dernière version de la CLI trouvée sur le site de VMware (lien mort, comme tout chez VMware), j’installe le « HP Smart Storage Administrator Diagnostic Utility (HP SSADU) CLI« .

Anecdote amusante : le technicien HP me donne le lien pour la CLI VMware, mais pas le lien pour le logiciel de sa propre entreprise… Et quand on connait un peu les méandres du site d’HP (surtout en pleine scission Hewlett Parkard vs HPe) c’est très drôle. Peut être que lui non plus ne sait pas où il est ? Pour vous éviter des sueurs froides et des accès de rage, il est ici.

L’étape d’après consiste à installer la CLI, PUIS de copier le binaire hpssaduesxi.exe dans le dossier C:\Program Files (x86)\VMware\VMware vSphere CLI\bin (installation par défaut de la CLI vSphere). A quoi bon l’installer alors, si c’est pour le copier à la main ? Mais bon, passons ces détails insignifiants ;-). **
**

Et c’est bon, le technicien est formel, ça devrait marcher maintenant : vous pouvez extraire votre rapport ADU en tapant la commande suivante dans un prompt (cmd ou PowerShell) dans le bon dossier.

C:\Program Files (x86)\VMware\VMware vSphere CLI\bin> hpssaduesxi.exe --server=[ip_serveur] --user=root --password=[password] report.zip

Coup de théâtre : ça ne fonctionne pas.

Retrieving report...
HPSSADUESXI requires the use of the vSphere CLI (esxcli) client
application. Make certain that this client has been installed
and is available from this directory. If vSphere CLI has been
installed, check the correctness of the inputted parameters.

Mieux, aucun des techniciens que j’ai eu chez HP ne savait pourquoi. Le niveau 1 je peux comprendre. Mais le plateau entier de niveau 2 ?

A force de perdre du temps, j’ai essayé de générer le rapport ADU directement sur les ESXi.

Mais bien sûr, ça ne fonctionne pas. C’est la raison pour laquelle le rapport ADU doit être généré sur un serveur Windows depuis hpssaduesxi.exe.

Solution

En fait, sans trop de surprises, hpssaduesxi n’est qu’une surcouche à esxcli. Et du coup l’erreur est tout de suite apparue lorsque j’ai essayé simplement de me connecter en esxcli aux serveurs VMware.

C:\Program Files (x86)\VMware\VMware vSphere CLI\bin> esxcli.exe --server=[ip_serveur] --user=root --password=[password]
Connect to [ip_serveur] failed. Server SHA-1 thumbprint: BD:F9:D9:40:35:77:E9:AA:8F:BC:04:42:97:AA:A7:4E:AA:E5:BB:4D (not trusted).

Le problème vient du fait que depuis la version 6, VMware a renforcé la sécurité et qu’on ne peut plus « ignorer » les certificats qui ne sont pas acceptés. Tout est expliqué ici (lien mort, comme tout chez VMware).

Le site de VMware donne plusieurs solutions, notamment celle d’ajouter le certificat du vCenter comme autorité de certification dans le serveur Windows. Je n’ai malheureusement pas réussi à faire fonctionner cette solution, qui est pourtant selon moi la meilleure.

En revanche, j’ai réussi à faire fonctionner esxcli et par conséquent hpssaducli en ajoutant l’empreinte SHA-1 de mes serveurs ESXi dans le « credstore », à l’aide de la commande suivante sur le serveur Windows :

C:\Program Files (x86)\VMware\VMware vSphere CLI\Perl\apps\general> credstore_admin.pl add --server [ip_serveur] --thumbprint BD:F9:D9:40:35:77:E9:AA:8F:BC:04:42:97:AA:A7:4E:AA:E5:BB:4D
PS C:\Program Files (x86)\VMware\VMware vSphere CLI\bin> .\hpssaduesxi.exe --server=[ip_serveur] --user=root --password=[mdp] report_esxi.zip
Retrieving report... Decoding... report_esxi.zip saved.

Mot de la fin

Je suis vraiment dépité que personne chez HP ne se soit posé la question de l’impact que ça avait sur leur binaire et que personne n’ait mis à jour la documentation fournie au support pour indiquer la marche à suivre en cas d’erreur !

J’espère être mal tombé et que ce problème est connu chez HP, car le fait que ça ait été à moi de leur trouver la réponse me dépasse…

Configurer DataProtector pour l’envoi de rapports via SMTP

Sat, 11 Jul 2015 12:00:07 +0000

Une des fonctionnalités vitales d’un système de sauvegarde est sa capacité à présenter de manière claire et concise des informations sur l’état des sauvegardes et de l’utilisation de l’outil en général. Même si c’est peut être un peu « old school », j’ai croisé de nombreux contextes professionnels dans lesquels le « team leader » reçoit quotidiennement les alertes de la veille sur les sauvegardes, sous forme d’indicateurs simples (ce que DataProtector sait bien entendu faire).

Le reporting chez DataProtector

DataProtector propose cette fonctionnalité depuis des années via le menu sobrement nommé « rapports » du Manager. De la même manière que les spécifications de sauvegarde, les groupes de rapports peuvent être ordonnancés pour s’exécuter à horaire fixé ou bien lancés à la main.

Il existe un certain nombre de rapports fournissant ce que je qualifierai du minimum syndical en terme de reporting pour un outil de sauvegarde, et leur nombre et leurs fonctionnalités n’a guère évolué depuis la v6.x.

Ces rapports ainsi que les autres outils de reporting qu’a rajouté HP en périphérie pour enrichir la relative pauvreté des indicateurs existant feront peut être l’objet d’articles futurs.

Le vif du sujet, configurer un SMTP dans DP

Ici, je vous présenterai simplement comment configurer DP pour que les mails des rapports puissent arriver à bon port.

Depuis la v8 (il me semble), il est possible d’éditer les paramètres Globaux de DP directement depuis la GUI, au lieu de passer par le fichier « global » comme auparavant.

Cependant pour y arriver, le cheminement n’est pas forcément intuitif ;-). En effet, il faut ouvrir le menu « Base de données interne », puis aller dans « Option Globale ».

Sincèrement, je n’aurai pas cherché ce dossier dans « Base de données interne », sachant que c’est là où toutes les informations des sessions ainsi que le contenu des médias sont stockés (dans un base de données, justement).

Au contraire, les options globales sont définies « de tout temps » dans un fichier de configuration, à part. Mais bon …

Il faut quand même louer les efforts d’HP sur ce coup là. L’interface, bien que mal rangée, est assez intuitive. Les différents paramètres sont clairement classés par type, avec une description et une valeur par défaut annoncée.

Les valeurs à modifier sont donc Cell Manager : SMTPServer et Cell Manager : SMTPSenderAddress

A chaque modification, il faut cliquer sur « Save » qui passe la ligne en rouge pour indiquer qu’une modification est en cours.

Attention elle n’est cependant pas totalement prise en compte :-/ Il faut remonter tout en haut pour valider la sauvegarde une fois pour toute. Dommage HP ! Bel effort… mais ce n’est pas encore ça comme UI intuitive.

Un bandeau vert s’affiche pour nous demander de redémarrer les services de DP pour prise en compte (lesquels?).

Une fois que c’est fait, l’ensemble des rapports utilisera ces valeurs pour envoyer les rapports sous forme d’email.

Bug ESXi custom HP : globalCartel-1, VMK_NO_MEMORY, can’t fork

Sat, 30 May 2015 10:00:04 +0000

Deux de nos serveurs de productions ESXi 5.5 se sont récemment comportés de manière erratique. Pour une raison inconnue, les machines virtuelles se sont mises à ne plus répondre correctement, et l’import d’un nouveau OVA a planté en fin de processus. Voilà quelques erreurs que j’ai pu rencontrer dans le client ou via la console :

Heap globalCartel-1 a déjà la taille maximale XXXXXXX. Impossible de l’augmenter.
Heap globalCartel-1 already at its maximum size. Cannot expand.
msg.vmk.status.VMK_NO_MEMORY
can’t fork

Plus aucune action d’administration n’était possible sur le serveur (démarrage/extinction de VM, modification des paramètres du serveur, …). En fait, à partir du moment où les messages d’erreur apparaissent il est déjà trop tard. La seule solution est de rebooter le serveur dans un premier temps.

Il s’agit d’un bug de la surcouche HP des images ESXi modifiées par HP, qui a une fuite de mémoire. Quand les messages d’erreurs apparaissent, c’est que la mémoire est pleine, et le serveur n’arrive plus à forker.

This is a known issue affecting ESXi 5.x. To resolve this issue, upgrade to AMS version 10.0.1.

Ce qui est à peine croyable, c’est que ce bug touche les versions modifiées par HP d’ESXi 5.0, 5.1 et 5.5 ! Rien que ça ! Moi qui pensais bien faire en prenant la peine d’installer la version customisé HP sur les serveurs HP avec ESXi, me voilà guéri de cet effort…

Pour plus de détails, voici le KB de chez VMware, qui liste les versions concernées, les symptômes et la marche à suivre pour contourner ou résoudre le problème (lien mort, comme tous les KBs VMware)

La seule « solution » est de mettre à jour la fameuse surcouche, via un patch offline à passer sur tous les serveurs qui dispose du build custom d’HP. Le contournement consiste simplement à couper le service incriminer, et à empêcher qu’il ne redémarre en le désinstallant.

Pour vérifier quelle version du composant incriminé est sur votre serveur

~ # esxcli software vib list | grep ams
hp-ams 550.10.0.0-18.1198610 Hewlett-Packard  PartnerSupported  2014-08-05

Pour supprimer le package AMS si la mise à jour n’est pas envisageable, il faut se connecter en SSH, couper le service, puis supprimer le « package » (VIB) et rebooter le serveur.

/etc/init.d/hp-ams.sh stop
esxcli software vib remove -n hp-ams

Pour mettre à jour votre 5.5 custom HP, voici le lien pour télécharger le bundle hp.com (lien mort, j’utilise Internet Archive)

Quelques liens supplémentaires :

communities.vmware.com/message/2436136 (lien mort, comme tout ce que fait VMware)
blog.vmpros.nl/2015/03/29/vmware-could-not-start-vmx-msg-vmk-status-vmk_no_memory/ (lien mort, j’utilise Internet Archive)
www.educationalcentre.co.uk/posts/could-not-start-vmx-msg-vmk-status-vmk_no_memory/