Team Leader - Nutanix Technology Champion - Nutanix NTC Storyteller

Julien DUMUR
Infrastructure in a Nutshell

ahv

Nutanix AOS 7.6, AHV 11.2 et PC 7.6 : retour de mise à jour

Published: 18 septembre 2026
Written by Julien D.
No comments
Categories: Nutanix, Nutanix AHV FR
Nutanix AOS 7.6, AHV 11.2 et PC 7.6 : image d'en-tête de l'article

La nouveauté qui m’a fait le plus plaisir en passant nos clusters de production et mon homelab sur Nutanix AOS 7.6 tient en deux touches de clavier : le copier-coller fonctionne enfin dans la console des machines virtuelles. Elle est pourtant loin d’être la plus structurante de cette version, qui touche surtout à l’accès SSH aux CVM et fait de Prism Central 7.6 une version nettement plus stable que ne l’étaient 7.3 et 7.5 à leur sortie.

Nous sommes partis d’AOS 7.5.1.8 et AHV 11.0.1.8 pour arriver en AOS 7.6.0.6, AHV 11.2.0.2 et Prism Central pc.7.6.0.6, sur plusieurs clusters de production hébergés chez OVHcloud et sur le nœud Supermicro 5019D-FN8TP de mon homelab (8 cœurs, 128 Go de RAM, 2 To bruts).

Pour ce nœud, pas de Foundation sur du matériel non supporté comme je l’avais fait l’an dernier : je suis passé par Nutanix CE. La version précédente, je l’avais présentée dans mon article sur AOS 7.5 et AHV 11.0.

Mise à jour vers AOS 7.6.0.6 : ordre et déroulé

J’ai suivi l’ordre recommandé par Nutanix, que je détaille dans mon article sur LCM : Prism Central d’abord, puis AOS, puis AHV. Sur les clusters de production, tout est passé par LCM avec les versions qu’il proposait ce jour-là, et je n’ai rien chronométré : je lance, et je laisse vivre sa vie.

Sur le homelab, j’ai dû télécharger les fichiers puis les téléverser sur le cluster pour pouvoir lancer la mise à jour, sur le même principe que pour Prism Central 2024.2.

Après la mise à jour, l’inventaire LCM affiche les versions suivantes :

Inventaire LCM affichant AOS 7.6.0.6, AHV 11.2.0.2 et NCC 6.0.0.1 après la mise à jour

Prendre la 7.6.0.6 proposée par LCM plutôt que la 7.6 initiale n’est pas anodin. Ce correctif règle deux blocages connus de la 7.6 : une mise à jour d’AOS qui reste figée sans progresser (KB-22340), et un hôte coincé en « EnteringMaintenance » pendant le passage à AHV 11.2, à cause du service Narsil qui redémarre en boucle. Côté Prism Central, pc.7.6.0.6 corrige aussi l’impossibilité de se connecter à l’interface pendant une mise à jour depuis pc.7.3 ou une version plus récente.

L’alerte « Inconsistent Virtual Switch » après la mise à jour

Seul vrai accroc de l’opération : sur deux ou trois de nos clusters, Prism a remonté une alerte « Inconsistent Virtual Switch » une fois la mise à jour terminée. Nutanix la documente comme un problème connu d’AOS 7.6, toujours présent en 7.6.0.6 : le VLAN configuré sur le port du bridge de l’hôte AHV ne correspond plus à celui qu’AOS a enregistré pour le virtual switch (KB-22397).

Le virtual switch vs0 signalé en erreur après la mise à jour vers AOS 7.6.0.6

La même alerte figure aussi dans la liste des problèmes corrigés par la 7.6, pour une autre cause, un écart de MTU entre le bridge br0 des hôtes et le virtual switch. Une variante disparaît, une autre arrive. Nous les avons corrigées.

Prism Central 7.6, enfin stable

Chez nous, en production comme sur le homelab, pc.7.6.0.6 est bien moins buggé que ne l’étaient les premières versions de 7.3 et 7.5. Deux points méritent tout de même d’être vérifiés avant de lancer la mise à jour.

Le premier : pc.7.6 range automatiquement toutes les entités existantes qui n’ont pas de projet dans un projet système, le « Default Project », et cette migration ne permet aucun retour arrière. Le second : Nutanix Kubernetes Engine n’est pas compatible avec pc.7.6, il faut avoir migré ses charges vers NKP avant de mettre à jour. Bonne nouvelle en revanche : le verrouillage du compte admin local toutes les dix minutes signalé en pc.7.6 (KB-22348) n’apparaît plus dans les problèmes connus de pc.7.6.0.6.

Le copier-coller dans la console des VM

C’est clairement ma nouveauté préférée ! Coller un mot de passe complexe ou une clé de licence dans la console d’une machine virtuelle, au lieu de le retaper caractère par caractère, fonctionne maintenant depuis la console lancée par Prism Central :

Bouton "Paste to Console" dans la console d'une VM AHV 11.2

Il faut AHV 11.2 et pc.7.6 : un cluster resté en AHV 11.0 derrière un Prism Central à jour n’en profite pas. Au passage, l’onglet « Console » des VM est déprécié dans Prism Central, on passe par l’action « Launch Console ».

Secure Access et la fin du SSH direct

Avec Secure Access, l’utilisateur admin qui se connecte en SSH à une CVM n’arrive plus sur un bash : il atterrit dans le NuService Menu, un shell restreint qui permet de lancer des commandes autorisées sur la CVM ou l’hôte AHV, de consulter les logs du cluster, d’ouvrir une session bash (admin shell) et de gérer l’authentification LDAP locale. Ça surprend au premier abord, et je n’ai pas encore eu besoin d’y passer la moindre commande.

NuService Menu affiché lors d'une connexion SSH en admin sur une CVM AOS 7.6

L’utilisateur nutanix garde, lui, une session bash classique. Pour les interventions du support, le « Support-only Login » exige un échange de jeton avec Nutanix et ouvre l’accès bash pour une fenêtre de 72 heures. L’accès SSH externe s’active ou se désactive cluster par cluster depuis Prism Central, via le « NuService Mode », avec confirmation à chaque bascule :

Boîte de dialogue de désactivation du NuService Mode dans Prism Central

Côté hôtes, AHV 11.2 ferme par défaut l’accès SSH externe sur le port 22 : on passe par la CVM pour atteindre l’hôte, et le réglage d’accès SSH externe ne concerne plus que les CVM. Ce que je décrivais dans La fin du SSH sur Nutanix se confirme version après version.

Dernier changement sous le capot : la CVM et la VM Prism Central reposent maintenant sur RHEL 9, alignées sur le guide de durcissement STIG de RHEL 9. Au quotidien, ça ne change pas grand-chose.

Ce que je n’ai pas encore testé

Plusieurs nouveautés importantes de cette version attendent que je les essaie, je me contente donc de les lister :

  • Tolérance aux pannes : nouveau mode 1N/2D (un nœud ou deux disques), et 1N&1D possible au-delà de trois nœuds, avec conversion depuis Prism Central.
  • Extension de cluster : passage d’un cluster AHV de deux à trois nœuds.
  • Migration à chaud entre clusters : d’une version d’AHV plus ancienne vers une plus récente, avec choix du stockage de destination.
  • BIOS UUID : conservé au failover et à la restauration, pour que les logiciels de sauvegarde tiers ne cassent pas leur chaîne.
  • Métriques mémoire : la mémoire récupérée par le ballooning est désormais séparée de la consommation réelle des VM.
  • Capacité par nœud : 307 To en all-flash NVMe contre 185 To auparavant, uniquement pour les nouveaux déploiements démarrés en 7.6. Un cluster mis à jour garde ses limites.

À anticiper : la fin des API legacy

Les API v0.8, v1, v2 et v3 ne seront plus supportées à partir de la version d’AOS et de Prism Central prévue au deuxième trimestre 2027. Le premier effet se voit dès pc.7.6 : les actions sur les Nutanix Guest Tools passent aux permissions v4, et les rôles personnalisés qui s’appuyaient sur les permissions v3 sont à mettre à jour. Si vos scripts parlent encore aux API v2 ou v3, il reste moins d’un an pour les migrer vers les API v4…

Vous savez tout, il ne vous reste plus qu’à lancer vos LCM !

Read More

State of the Lab : mon homelab Nutanix avant la refonte

Published: 16 septembre 2026
Written by Julien D.
No comments
Categories: Community Edition FR, State of the Lab FR, Tech et Lab
State of the Lab : mon homelab Nutanix avant la refonte

En septembre 2024, je publiais un article sur la création d’un homelab sous Nutanix CE dans lequel j’écrivais que la première question à se poser était celle de l’usage : des machines virtuelles éphémères pour monter en compétence, ou des services pour soi et pour sa famille ? J’avais répondu « des tests », et j’ai construit toute mon infrastructure autour de cette réponse.

Deux ans plus tard, la réponse a changé et l’infrastructure, elle, n’a pas bougé. Avant d’entamer le chantier, voici à quoi ressemblait mon homelab Nutanix au 1er juillet 2026.

L’état des lieux de mon homelab Nutanix au 1er juillet 2026

À cette date, tout ce qui tourne chez moi tient sur trois machines. Le réseau d’abord, monté il y a quatre ans à la construction de la maison et entièrement basé sur du Ubiquiti : une Dream Machine Pro, un switch USW Pro 24 PoE et quelques Flex répartis dans les pièces, le tout raccordé à une Freebox Delta en fibre 10 Gb/s.

Topologie du réseau domestique : Freebox Delta, Dream Machine Pro et USW Pro 24 PoE, avec le cluster Nutanix CE et Mainsail derrière le switch du garage, Home Assistant sur l'USW 24 et AdGuard dans une VM de la Freebox

Le cluster ensuite, un châssis Intel S2600WTTR installé dans le garage parce qu’il n’a pas droit de séjour dans la maison, sur des rails coulissants vissés dans les solives faute de baie, un nœud unique sous Nutanix CE 2.1, avec deux ou trois machines virtuelles de test dessus. J’en ai détaillé la configuration matérielle à l’époque, je vous invite à consulter mon article à ce sujet.

Le châssis Intel S2600WTTR de mon cluster Nutanix CE, monté sur rails sous la structure bois du garage

Ce serveur de 2016, je l’ai récupéré dans une précédente expérience professionnelle. Il était tombé en panne matérielle et l’administration ne souhaitait pas engager la réparation, compte tenu de son âge et du remplacement de l’infrastructure déjà lancé vers des clusters Nutanix neufs. Je l’ai donc sorti et remis en état à mes frais.

Tout le reste des décisions matérielles découle de ce point de départ. Une seule alimentation raccordée sur les deux, volontairement, parce que rien de critique ne tourne dessus et qu’une panne se traduit au pire par un cluster arrêté le temps d’un week-end, puis une redondance disque partielle que j’assumais déjà à l’époque comme un compromis. Sur le dimensionnement en revanche, je n’ai jamais rencontré la moindre limite : 384 Go de RAM, quatre SSD SAS de 800 Go et six disques 10k pour deux ou trois machines virtuelles de test, de la marge qui ne servait à rien.

Et c’est tout, ou presque. Deux services vivent en dehors du cluster : Home Assistant sur un Raspberry Pi, qui collecte déjà la consommation de la prise Meross branchée sur le serveur et la production photovoltaïque de mon installation, et AdGuard sur une machine virtuelle hébergée par la Freebox. La résolution DNS de toute la maison reposait donc sur la box de mon opérateur : un redémarrage un peu long, un changement d’offre, et plus rien ne résout.

Ce que l’audit du réseau a montré

Avant de toucher au cluster, j’ai passé la configuration UniFi au crible, sur une version antérieure à UniFi OS 5.1.33. Le résultat est moins flatteur que le matériel.

Le réseau natif est en 192.168.2.0/24 et porte l’identifiant de VLAN 1 dans le contrôleur, un écart entre le nommage et la réalité qui pique dès qu’on relit une configuration six mois plus tard. Quatre SSID ensuite, tous en 2,4 GHz et tous en WPA2, dont un masqué pour la vidéoprotection, ce qui n’a jamais protégé personne et complique surtout la vie des équipements qui doivent s’y raccrocher. Les caméras Tapo, justement, sont en Wi-Fi sur ce même réseau natif : les appareils sur lesquels j’ai le moins de garanties partagent le segment de tout le reste.

Liste des réseaux dans le contrôleur UniFi : le LAN en 192.168.2.0/24 porte l'identifiant de VLAN 1, et trois des quatre autres VLAN n'ont distribué aucun bail DHCP

L’inventaire a sorti le reste. Quatre VLAN déclarés à côté du natif, ALARM en 192.168.90.0/29, VIDEO en 192.168.100.0/24, NTNX en 192.168.84.0/24 et IOT en 192.168.99.0/24, dont trois n’ont jamais distribué le moindre bail DHCP. Pendant ce temps, vingt-cinq équipements se partagent le LAN, les caméras comprises, alors que le VLAN VIDEO qui leur est destiné existe depuis le premier jour et reste vide.

C’est ce qui arrive quand on dessine une segmentation le jour de l’installation et qu’on ne la relit plus jamais ensuite.

Il n’y a donc pas de segmentation, juste des VLAN déclarés. Et la raison est la même que pour le cluster : le temps est passé ailleurs.

Ce que coûte un homelab Nutanix qu’on n’allume qu’au besoin

En 2024, j’avais branché une prise connectée Meross sur le cluster et je l’avais remontée dans Home Assistant pour savoir précisément ce que cette machine me coûtait. Environ 5 850 Wh par jour cluster allumé, ce qui projette 2 138,9 kWh sur une année pleine et près de 535 euros au tarif réglementé, en supposant le serveur allumé tous les jours de l’année.

Consommation quotidienne du cluster mesurée dans Home Assistant du 18 août au 17 septembre 2024 : un palier bas serveur éteint, puis des journées à près de 5 850 Wh à partir du 10 septembre

Le chiffre que je n’attendais pas est l’autre : le serveur éteint consomme encore entre 300 et 400 Wh par jour, uniquement pour maintenir l’IPMI et les alimentations sous tension. Rapporté à l’année, cela fait de 110 à 146 kWh et une trentaine d’euros pour une machine qui ne fait rien. Le détail de la mesure est dans l’article que j’ai consacré au sujet.

La règle s’est donc imposée d’elle-même : le cluster ne s’allume que pour les tests et pour la rédaction des articles. Et c’est exactement ce qui bloque tout le reste, puisqu’une infrastructure qu’on démarre le soir où on en a besoin ne peut héberger aucun service qui doit répondre en permanence, ce qui exclut à peu près tout ce qu’une maison attend d’un serveur.

J’ai laissé la situation en l’état pendant deux ans car j’avais d’autres chantiers sur le feu.

Ce qui n’existait pas

Au 1er juillet 2026, je n’avais ni DNS interne, ni reverse proxy, ni supervision, ni gestion des secrets, et aucun système de sauvegarde.

Chacun de ces manques est indolore tant que les machines virtuelles sont jetables. On accède à une VM par son adresse IP parce qu’on en a trois, on ne surveille rien parce qu’un arrêt ne dérange personne, et on ne sauvegarde pas ce qu’on a prévu de détruire à la fin du test.

Avec le temps, les besoins ont évolué et je veux aujourd’hui faire tourner des applications en local qui seront utilisées par toute la famille. Les cinq manques apparaissent alors d’un seul coup, parce qu’aucun d’eux ne se voit tant que rien n’a besoin de survivre à un redémarrage.

Le seul ajout en deux ans : Mainsail

Entre mon article de 2024 et aujourd’hui, une seule chose a bougé. En décembre 2025, j’ai installé Klipper et Mainsail pour piloter mon imprimante 3D, sur un Raspberry Pi posé à côté.

Je n’ai même pas envisagé d’autre option. AHV ne sait pas faire de passthrough USB, la KB Nutanix est claire là-dessus, et de toute façon le cluster passe l’essentiel de son temps éteint. Il reste une piste que je garde pour la refonte, VirtualHere, qui expose un périphérique USB sur le réseau et le présente à une machine virtuelle sans passthrough matériel. Je ne l’ai pas encore testée.

La facture d’électricité a fini par dicter l’architecture, et pendant deux ans elle a produit la même décision à chaque nouveau besoin.

Voilà l’état des lieux. Un cluster de test presque tout le temps éteint, deux Raspberry Pi qui hébergent des applications et une box opérateur qui fait office de serveur DNS. Ça fonctionne, et ça ne peut rien porter de plus.

Le chantier commence là. Il me faut un socle allumé en permanence et sobre, un DNS et un reverse proxy qui m’appartiennent, des sauvegardes vérifiées, de la supervision, de quoi gérer les secrets… et un cluster Nutanix qui redevient ce pour quoi il est bon : casser des choses. C’est ce que je vais raconter dans les articles qui suivent.

Read More

Nutanix Community Edition : problème de réinstallation

Published: 31 août 2026
Written by Julien D.
No comments
Categories: Community Edition FR, Nutanix
Problème de réinstallation de Nutanix Community Edition

Réinstallation d’un nœud Nutanix Community Edition sur du matériel qui portait déjà un AHV. L’installeur Phoenix démarre, détecte le matériel, puis s’arrête sur une traceback Python :

FATAL An exception was raised: Traceback (most recent call last):
  File "/root/phoenix/./phoenix", line 155, in <module>
    main()
  ...
  File "/root/phoenix/sysUtil.py", line 2086, in mount_ahv_lvm_volumes
    shell_cmd(['mount', '-t ext4', dev, target + mntpnt])
Exception: Failed command: [mount -t ext4 /dev/mapper/ahv-varlog /mnt/stage/var/log]
with error: [mount: /mnt/stage/var/log: special device /dev/mapper/ahv-varlog does not exist.]

Le message semble parfaitement exact, et c’est ce qui le rend trompeur : le périphérique n’existe pas. La vraie question est de savoir pourquoi Phoenix le cherche.

Comprendre pourquoi l’installeur Nutanix plante

La pile d’appels raconte toute l’histoire, à condition de la lire de bas en haut :

  • get_params → determine_actions → get_hyp_state
  • get_hyp_state → customize_kvm.get_state → __mount_kvm_partition → mount_ahv_lvm_volumes

Phoenix ne plante pas pendant l’installation. Il plante avant, pendant la phase de détection, quand il essaie de déterminer quelles actions proposer. Il a trouvé un hyperviseur existant sur le disque, il a donc basculé sur son chemin customize (celui qui met à jour un AHV en place plutôt que d’en installer un neuf) et ce chemin exige de monter les volumes de l’installation existante.

Les lignes de log qui précèdent confirment le raisonnement :

INFO Calling dmsetup remove /dev/mapper/ahvstorage-varlogaudit
INFO Calling dmsetup remove /dev/mapper/ahvstorage-varlog
INFO LVM volume group ahv detected
INFO Found block device entry /dev/mapper/ahv-root, calling vgchange -an ahv

Deux groupes de volumes distincts apparaissent : ahv et ahvstorage. Un lvs depuis le shell de secours confirme la répartition :

LVVGTaille
homeahv200 Mo
rootahv6,84 Go
tmpahv1,95 Go
varahv2,93 Go
varlogahvstorage39,06 Go
varlogauditahvstorage1000 Mo

Voilà le décalage. Sur le disque, varlog vit dans le VG ahvstorage. L’ISO Phoenix, lui, cherche /dev/mapper/ahv-varlog, c’est-à-dire varlog dans le VG ahv. Il applique un schéma LVM qui n’est pas celui présent sur la machine.

L’explication la plus probable est un écart de génération : le layout AHV a évolué vers un VG de stockage séparé, et le média utilisé pour la réinstallation attend la disposition antérieure. Résultat, Phoenix reconnaît assez bien l’installation existante pour vouloir la réutiliser, mais pas assez pour savoir la monter.

La Solution : Faire table rase du disque système

Puisque le blocage tient entièrement à la détection d’une installation préexistante, la solution est de faire en sorte qu’il n’y ait plus rien à détecter.

Phoenix laisse un shell root accessible après l’échec. On commence par cartographier avant de détruire :

lsblk
pvs
vgs
lvs

Dans mon cas, deux PV sur un seul disque : /dev/sda3 pour ahv, /dev/sda5 pour ahvstorage.

Puis on démonte les VG et on les supprime :

vgchange -an ahvstorage
vgremove -f ahvstorage

ahvstorage disparaît sans résistance. ahv, lui, s’obstine :

Logical volume ahv/root contains a filesystem in use.
Can't deactivate volume group "ahv" with 2 open logical volume(s)

Le second problème : les volumes restés montés

Ce message est le vrai point de bascule de la procédure, et la sortie de lvs en donne la clé :

root  ahv  -wi-ao----
var   ahv  -wi-ao----

L’attribut o signifie open. Ces deux volumes logiques sont montés. Ce sont les « 2 open logical volume(s) » du message d’erreur, et c’est ce qui fait ensuite échouer toute la chaîne :

pvremove -ff -y /dev/sda3
  Can't open /dev/sda3 exclusively. Mounted filesystem?
  Cannot use /dev/sda3: device has a signature

wipefs -a /dev/sda
  wipefs: error: /dev/sda: probing initialization failed: Device or resource busy

La cause est simple : Phoenix avait monté root et var sous /mnt/stage avant de planter sur varlog, et il n’a rien démonté en sortant. L’échec a laissé le disque dans un état intermédiaire.

Il faut donc démonter avant tout le reste :

findmnt -R /mnt/stage
umount -R /mnt/stage

Si un processus tient encore la partition :

fuser -vm /mnt/stage
fuser -km /mnt/stage

On vérifie que les LV sont bien fermés, l’attribut doit être -wi-a-----, sans le o :

lvs

Et seulement ensuite, l’effacement complet :

vgchange -an ahv
vgremove -f ahv
pvremove -ff -y /dev/sda3
wipefs -a /dev/sda
sgdisk --zap-all /dev/sda
dd if=/dev/zero of=/dev/sda bs=1M count=100 conv=fsync

Le sgdisk --zap-all n’est pas décoratif. Une table GPT possède une copie de secours en fin de disque, que le dd sur les 100 premiers mégaoctets laisse parfaitement intacte. C’est la raison pour laquelle des groupes de volumes « reviennent » après un effacement qu’on croyait complet.

Si les disques de données CVM portent eux aussi des résidus, on leur applique le même traitement : wipefs -a puis sgdisk --zap-all sur chacun.

Reboot, relance de l’installeur, et Phoenix ne détecte plus rien : il propose une installation neuve.

Ce que je retiens de cette réinstallation

Un message d’erreur exact peut désigner le mauvais problème :

« ahv-varlog n’existe pas » est littéralement vrai et complètement hors sujet. Le problème n’est pas l’absence du volume, c’est que l’installeur applique un schéma qui n’est pas celui du disque. Sans lire la pile d’appels, on part chercher un volume manquant au lieu de comprendre qu’on est dans la mauvaise branche du programme.

Un échec d’installeur laisse un état :

Phoenix a planté après avoir monté deux volumes, et ces montages ont survécu à son arrêt. Tous les échecs de la séquence suivante (pvremove, wipefs) en découlaient directement. Avant de lutter contre un « Device or resource busy », il faut chercher ce qui tient le périphérique.

Un cluster explicitement destructible change la nature du problème :

Cette procédure est brutale : elle efface tout. Elle n’est acceptable que parce que ce nœud appartient à un environnement désigné comme sacrifiable, dont aucune donnée irremplaçable ne dépend. Décider à l’avance quel cluster est jetable ne change rien à la panne, mais change entièrement le temps qu’on passe à la résoudre.

Read More

Mot de passe IPMI perdu sur un nœud Nutanix ou Supermicro : Le guide de récupération

Published: 10 août 2026
Written by Julien D.
1 Comment
Categories: Nutanix, Nutanix AHV FR, Tech et Lab
Récupérer un mot de passe IPMI perdu sur un nœud Nutanix ou Supermicro

Il m’est arrivé une petite mésaventure récemment. Après un changement de mot de passe IPMI sur mon 1-node, impossible de me reconnecter à l’interface de management de mon nœud. Oubli dans la seconde ? Faute de frappe ? Copier coller foireux ? Qu’importe la raison, le verrouillage de l’accès, lui, était bien réel.

Perdre son mot de passe IPMI (ou BMC) fait souvent transpirer. Mais rassurez-vous, l’expérience m’a appris une règle d’or : tant que vous avez encore un accès au système d’exploitation de l’hôte (que ce soit AHV, un Linux standard ou même ESXi), vous pouvez récupérer la main sans avoir besoin de faire un reset matériel.

Toutefois, la situation peut être plus critique qu’il n’y paraît. Pour les experts qui me lisent, vous savez qu’en environnement Nutanix Single-Node, l’IPMI n’est pas juste un confort d’administration : c’est votre seul et unique fail-safe. Sans lui, impossible de monter une ISO Phoenix en Remote Media lors d’un crash AOS majeur ou pour forcer un redémarrage. Perdre l’accès BMC sur un tel nœud devient donc très vite un point de blocage impactant pour votre production et l’accès à la console distante.

Dans ce guide, je vous partage les différentes méthodes pour reprendre le contrôle sur votre noeud en quelques minutes, de la plus douce à celle de la dernière chance.

Méthode 1 : Réinitialisation in-band via ipmitool

Si vous êtes sous Nutanix AHV ou une distribution Linux classique, vous avez de la chance : l’utilitaire ipmitool est généralement présent nativement. L’astuce de cette méthode repose sur le canal matériel KCS (Keyboard Controller Style). En clair, cela permet à l’OS de l’hôte de communiquer directement avec la puce BMC via le bus de la carte mère (LPC/PCIe), sans passer par le réseau de management.

Identifier et écraser le compte Admin

Connectez-vous en root sur votre hôte. Par précaution, on s’assure d’abord que les modules noyaux gérant l’IPMI sont bien chargés :

modprobe ipmi_si
modprobe ipmi_devintf

Ensuite, on va lister les utilisateurs configurés (généralement sur le channel 1) pour repérer l’ID de notre compte administrateur. Dans 99% des cas, le compte par défaut (ADMIN) correspond à l’ID 2.

ipmitool user list 1

Dans mon cas, l’ID correspond bien à 2 :

Résultat de ipmitool user list 1 avec le compte ADMIN en ID 2

Une fois l’ID confirmé, la commande pour forcer un nouveau mot de passe est enfantine :

ipmitool user set password 2 'MonNouveauMdp123!'

Lors de la saisie de la commande précédente, il se peut que le terminal vous renvoie un vilain Invalid data field in request.

Pas de panique, c’est simplement le parseur de politique de sécurité de certains firmwares qui rejette votre demande. Il exige non seulement une complexité minimale (8 caractères, majuscule, minuscule, chiffre), mais peut aussi être capricieux sur le format de la requête.

Pour contourner (ou plutôt satisfaire) ce mécanisme, forcez la longueur d’encodage sur 20 octets en ajoutant simplement 20 à la fin de votre commande :

ipmitool user set password 2 'MonNouveauMdp123!' 20

Votre mot de passe est maintenant écrasé. Vous pouvez tester la connexion à l’interface web.

Méthode 2 : L’utilitaire IPMICFG (La solution pour VMware ESXi)

Si vous êtes sous VMware ESXi, la première méthode risque de vous laisser sur le carreau. Pourquoi ? Parce qu’ipmitool n’y est pas packagé nativement et résoudre les dépendances pour le compiler sur un hyperviseur est une perte de temps que je ne vous recommande pas.

La parade s’appelle IPMICFG. C’est l’outil officiel fourni par Supermicro (téléchargeable sur leur portail avec un compte gratuit). L’immense avantage est qu’il est fourni sous forme de binaires statiques, prêts à l’emploi pour Linux ou Windows.

Une fois l’archive transférée sur votre hôte et décompressée, son utilisation est très simple :

./IPMICFG-Linux.x86_64 -user list
./IPMICFG-Linux.x86_64 -user setpwd 2 MonNouveauMdp123!

Note : adaptez le nom du binaire si vous utilisez la version Windows ou Linux.

Vous pouvez récupérer l’utilitaire ici : https://www.supermicro.com/wdl/utility/IPMICFG/

Cas extrême : Le nœud n’a plus d’OS bootable

Que faire si l’OS ne démarre plus du tout ? C’est souvent là qu’on transpire, pensant que sans accès réseau à l’IPMI ni système d’exploitation fonctionnel, la seule méthode restante est le reset usine.

Rappelez-vous : l’interface KCS est exposée au niveau matériel dès la fin du POST BIOS. Elle est totalement indépendante de l’état de votre stockage.

Il suffit donc de booter le serveur sur une clé USB contenant un Live CD Linux (Ubuntu, Rocky Linux). Une fois sur le bureau éphémère, ouvrez un terminal, installez l’utilitaire s’il n’est pas déjà présent (apt install ipmitool par exemple), et reprenez exactement les commandes de la Méthode 1.

Méthode de dernier recours : Le Factory Reset du BMC

Si pour une raison obscure les méthodes précédentes échouent, il reste l’ultime recours : le reset aux paramètres d’usine.

Avec l’outil de Supermicro, la commande est directe :

./IPMICFG-Linux.x86_64 -fd

Et si vous préférez la méthode ipmitool pure, il faut passer une commande RAW :

ipmitool raw 0x3c 0x40

⚠️ Attention, les conséquences sont lourdes : Toute votre configuration BMC est remise à zéro. Vous perdez l’IP statique (le port repasse en DHCP), la configuration des VLANs, et vos comptes utilisateurs. Le BMC va ensuite redémarrer (comptez bien 2 à 3 minutes). Gros point de vigilance sur les générations récentes de serveurs : il se peut que le mot de passe ne redevienne pas ADMIN/ADMIN. Il bascule sur le mot de passe unique imprimé sur l’étiquette OCP (souvent collée sur le châssis ou la carte mère). Pensez-y si votre serveur est physiquement à l’autre bout du monde !

Mes recommandations

Une fois l’accès récupéré via la méthode 1 ou 2, voici ce que je fais systématiquement pour sécuriser mes arrières :

  1. Le gestionnaire de mots de passe : C’est basique, mais renseignez vos creds immédiatement au lieu de le garder dans le cache du copié-collé.
  2. Le compte de secours : Créez un second compte administrateur.
  3. L’astuce du Slot ID : Ne mettez pas votre compte de secours sur le Slot ID 3. Forcez sa création sur un Slot plus éloigné (comme le 5 ou le 6). Pourquoi ? Parce que certains scripts d’automatisation d’infrastructure ont parfois la fâcheuse tendance à écraser ou modifier en force les premiers Slots (2 et 3) lors du provisionning. En le mettant plus loin, vous le sanctuarisez.

Et vous, ça vous est déjà arrivé de vous enfermer dehors sur l’un de vos nœuds ? Partagez votre pire galère dans les commentaires ci-dessous !

Read More

Nutanix AHV : Maîtriser les VM Startup Policies

Published: 23 juillet 2026
Written by Julien D.
No comments
Categories: Nutanix, Nutanix AHV FR, Tutoriels, Tutoriels-AHV
VM Startup Policies sur Nutanix AHV

Il y a quelques années, suite à une panne de courant sur l’un de nos 2 sites, j’ai dû faire face à certaines problématiques applicatives après le redémarrage du cluster Nutanix. Sur le papier, tout aurait dû bien se passer : l’onduleur avait repris le relais, aucun impact sur la production mais c’était sans compter sur une mauvaise manipulation du technicien qui a coupé l’onduleur. Le cluster s’est brutalement arrêté.

Une fois le courant revenu, le cluster a redémarré automatiquement et l’ensemble des VMs a redémarré dans la foulée. Le problème, c’est que certains serveurs de bases de données ont pris leur temps… Trop de temps pour certaines applications métiers…

C’est exactement pour vous éviter ces sueurs froides nocturnes que nous allons explorer aujourd’hui les VM Startup Policies sur Nutanix AHV.

Si le concept d’ordonnancer le démarrage de ses serveurs peut paraître simple, la mécanique sous-jacente mérite qu’on s’y attarde.

Que sont les “VM Startup Policies” ?

Les VM Startup Policies sont une fonctionnalité native de l’hyperviseur AHV qui agit comme un ordonnanceur lors de l’allumage de vos machines virtuelles. Cette fonctionnalité a été ajoutée avec la version 7.5 dont je vous avais parlé il y a quelques temps sur le blog.

Écran d'accueil des VM Startup Policies dans Prism Central

Au lieu de subir l’ordre de démarrage et de laisser la main au cluster, vous définissez précisément des groupes de VMs et des règles de dépendances strictes. Ainsi, vous garantissez que vos services d’infrastructure (comme un Active Directory par exemple) et vos bases de données soient pleinement opérationnels avant d’autoriser le démarrage des serveurs applicatifs.

Pour bien comprendre l’importance de ces règles, un petit rappel du comportement par défaut d’Acropolis HA s’impose. En l’absence de Startup Policy, lors d’un crash de nœud ou d’un redémarrage de cluster, le redémarrage des VMs s’effectue en mode best-effort. Le cluster Prism Element se concentre sur l’allocation rapide des ressources (CPU/RAM) et déclenche l’allumage des VMs de manière totalement asynchrone et concurrente et n’a nativement aucune conscience de vos dépendances applicatives.

Dans quels cas ces règles s’activent-elles vraiment ?

Il est important de préciser que ces stratégies ne s’appliquent pas si vous décidez de redémarrer une VM manuellement depuis l’interface de Prism Central en pleine journée. L’orchestration AHV se réveille et applique vos Startup Policies dans deux cas de figure :

  1. Un événement de Haute Disponibilité (HA) : Un ou plusieurs nœuds physiques de votre cluster tombent en panne. L’hyperviseur AHV va rapatrier et redémarrer les VMs affectées sur les nœuds survivants, en respectant scrupuleusement l’ordre que vous avez défini.
  2. Un redémarrage complet du cluster (Full Cluster Restart) : Exactement le cas de mon anecdote ! Suite à une coupure électrique totale par exemple.

Décryptage de la mécanique : Les 3 piliers fondamentaux

L’approche de Nutanix a le mérite d’être extrêmement visuelle et très simple à prendre en main depuis Prism Central. Elle repose sur trois concepts fondamentaux.

1. Les Catégories

La mécanique de Nutanix s’appuie exclusivement sur les Catégories de Prism Central. Vous ne liez pas « Serveur-SQL-01 » à « Serveur-Web-01 », mais vous liez la catégorie AppMetier:Database par exemple aux VMs hébergeant des bases des données et vos VMs applicatives à la catégorie AppMetier:Applicatif.

C’est ici que réside la vraie puissance de cette architecture. Si demain vous déployez trois nouveaux serveurs applicatifs en scale-out pour absorber une charge imprévue, il vous suffit de leur assigner la bonne catégorie. Ils seront automatiquement intégrés dans le bon ordre de votre Startup Policy sans que vous n’ayez à ouvrir ou modifier la moindre règle.

2. Les niveaux de dépendances

C’est grâce à ça que vous dessinez votre chaîne logique : la catégorie B ne peut démarrer que si la catégorie A a terminé. Il y a tout de même une petite subtilité à garder en tête : Nutanix autorise un maximum de 6 niveaux de dépendance consécutifs par policy. Dans 99 % des cas, c’est largement suffisant pour une application classique (ex: Infra > BDD > Web), mais cela demande de bien regrouper ses services sans faire de micro-management.

Message Cannot add more than six groups to a policy

3. Les conditions de démarrage

C’est la question à un million : comment l’hyperviseur AHV sait-il que la base de données est réellement prête pour autoriser la suite ? L’outil vous propose 2 options :

  • VM Power On : Dès que la VM est sous tension au niveau matériel, on lance l’étape suivante. L’OS Windows ou Linux n’est même pas encore chargé. À éviter pour des dépendances fortes.
  • Guest Boot up : Le top du top ! Nutanix attend patiemment que l’OS soit complètement chargé et que la couche réseau réponde.

Pour que la condition « Guest Boot up » fonctionne, les Nutanix Guest Tools (NGT) doivent impérativement être installés et à jour sur la VM. Mon conseil (et la recommandation éditeur) : ne faites pas l’impasse sur le déploiement des NGT !

Il y a également une option qui complète l’une ou l’autre :

  • Delay (Délai en secondes) : On attend « bêtement » un temps donné (ex: 60 secondes) avant de passer à la suite.

Tutoriel : créer une startup policy

Je vous propose de modéliser l’exemple le plus courant : nous voulons démarrer nos contrôleurs de domaine, attendre qu’ils soient prêts, démarrer nos bases de données, puis enfin nos serveurs applicatifs.

Pour l’occasion, j’ai créé 3 catégories : AppType:ActiveDirectory, AppMetier:Database et enfin AppMetier:Applicatif

  1. Connectez-vous à Prism Central.
  2. Allez dans le menu Infrastructure > Compute > VMs > Policies > VM Startup Policies.
  3. Cliquez sur Create VM Startup Policy.
  4. Donnez-lui un nom explicite (ex: Policy-Tiering-Metier).
  5. Dans l’interface visuelle, ajoutez votre première catégorie (ex: AppType:ActiveDirectory).
  6. Ajoutez un second bloc pour AppMetier:Database et un troisième pour AppMetier:Applicatif.
  7. Cliquez sur + Configure Start Conditions pour définir les conditions de démarrage. Choisissez Guest Boot up et ajoutez éventuellement un délai de sécurité de 30 secondes pour laisser le temps aux services internes de l’OS de bien s’initialiser.

Cliquez sur “Create”, et le tour est joué !

Création d'une VM Startup Policy avec trois groupes de dépendance

Il ne vous restera plus qu’à ajouter vos VMs aux bonnes catégories.

Les pièges à éviter

L’outil est formidable, mais voici 3 retours terrains pour vous éviter de tomber dans certains pièges :

1. Gérer la limite des 6 niveaux intelligemment

Ne tombez pas dans le piège du micro-management ! Si vous essayez de faire une policy pour chaque micro-application, vous allez vite saturer l’interface, atteindre la fameuse limite des 6 niveaux et vous retrouver avec une usine à gaz impossible à maintenir dans le temps. Groupez intelligemment vos ressources et faites simple !

2. Attention à l’interaction avec les mécanismes de PRA

Les Startup Policies gèrent la résilience locale d’un cluster (HA ou reboot). Mais attention, si vous utilisez Nutanix Disaster Recovery pour basculer vers un site distant, ce système a son propre mécanisme de plans de reprise. Lors d’un failover inter-sites, c’est le Recovery Plan de Prism Central qui prend la main sur l’ordre de démarrage, et non plus votre Startup Policy locale. Veillez donc à maintenir une cohérence logique entre les deux outils.

3. Cela ne concerne que les VMs invitées

Inutile d’essayer de séquencer les VMs “Nutanix” (Prism Central, CVM, ou autres…), cela ne fonctionnera pas. Le mécanisme n’est applicable que sur vos machines virtuelles, pas celles du système.

Conclusion

Les VM Startup Policies sur Nutanix AHV sont le genre de fonctionnalité que l’on configure une fois, que l’on oublie, et qui peuvent faire gagner un temps et une sérénité précieux le jour où l’impensable se produit. Grâce à une interface visuelle intuitive basée sur des catégories, Nutanix a rendu la résilience applicative accessible à tous.

Si ce n’est pas déjà fait, je vous invite vivement à vérifier l’état de vos NGT (état de déploiement et versions) et à catégoriser vos VMs les plus critiques dès aujourd’hui. Votre futur « vous », réveillé à 3h du matin lors du prochain incident de prod, vous remerciera !

Read More

OpenClaw sur Nutanix AHV : Le guide complet des prérequis

Published: 9 juillet 2026
Written by Julien D.
No comments
Categories: IA, Nutanix, Nutanix AHV FR, Tech et Lab
openclaw on nutanix ahv

Dans un précédent article, nous avons vu comment déployer OpenClaw sur Nutanix AHV. Cependant, avant de pouvoir profiter pleinement de cet agent IA autonome, il est crucial de préparer le terrain. OpenClaw n’est pas qu’un simple script : c’est un écosystème qui s’appuie sur plusieurs briques technologiques pour « penser » (LLM local), « exécuter » (Node.js) et « chercher » (SearXNG).

Schéma des prérequis OpenClaw : Ollama, SearXNG, Docker, Homebrew et GPU

Dans cet article, nous allons détailler l’installation pas-à-pas de tous les prérequis nécessaires sur votre machine virtuelle (sous Ubuntu), en expliquant pour chacun pourquoi il est indispensable au bon fonctionnement d’OpenClaw.

1. Pilotes NVIDIA : Libérer la puissance du GPU

OpenClaw peut s’appuyer sur des modèles de langage (LLM) exécutés localement. Bien qu’il soit techniquement possible de faire tourner ces modèles sur un processeur (CPU), les performances seraient extrêmement lentes. L’installation des pilotes NVIDIA permet au système d’exploiter la carte graphique (GPU) allouée à votre VM via Nutanix AHV (vGPU ou Passthrough), garantissant ainsi une inférence rapide et fluide de l’IA.

Voici comment mettre à jour votre système et installer les pilotes adéquats :

# Mise à jour du système
sudo apt update && sudo apt upgrade -y

# Installation du pilote serveur NVIDIA
sudo apt install nvidia-driver-535-server -y

# Redémarrage nécessaire pour la prise en compte
sudo reboot

Après le redémarrage, vérifiez que votre GPU est bien reconnu avec la commande suivante :

nvidia-smi

2. Node.js (v24) : Le moteur d’exécution d’OpenClaw

Le cœur de la logique d’OpenClaw est développé en JavaScript/TypeScript. Node.js est l’environnement d’exécution qui permet de faire tourner le code de l’agent, de gérer ses dépendances et d’orchestrer les appels entre l’interface, le modèle d’IA et les différents outils. Nous ciblons ici la version 24.x pour assurer une compatibilité optimale.

# Ajout du dépôt NodeSource et installation
curl -fsSL [https://deb.nodesource.com/setup_24.x](https://deb.nodesource.com/setup_24.x) | sudo -E bash -
sudo apt install -y nodejs

# Vérification de la version installée
node --version  # doit afficher v24.x

3. Ollama & Qwen 2.5 : Le cerveau local de l’opération

Ollama est l’outil qui va nous permettre de télécharger et de faire tourner facilement notre modèle d’IA en local. Pour OpenClaw, nous allons utiliser le modèle Qwen2.5 (7B). Pourquoi ce choix ? C’est un modèle léger (adapté pour les GPU avec environ 8 Go de VRAM) et, surtout, il est excellent en « Tool Calling » (l’appel d’outils). C’est cette capacité qui permet à OpenClaw de comprendre qu’il doit exécuter une recherche web ou lancer un script plutôt que de simplement générer du texte.

# Installation d'Ollama
curl -fsSL [https://ollama.ai/install.sh](https://ollama.ai/install.sh) | sh

# Démarrer le service Ollama (en arrière-plan)
ollama serve &

# Dans un autre terminal, vérifiez qu'Ollama détecte bien le GPU :
nvidia-smi  # Vous devriez voir ollama dans la liste des processus GPU

# Puller (télécharger) le modèle recommandé
ollama pull qwen2.5:7b

# Tester le modèle et vérifier son exécution sur le GPU
ollama run qwen2.5:7b "dis bonjour"

# Pendant que le modèle génère une réponse, vérifiez l'utilisation de la VRAM
nvidia-smi

4. Docker : L’infrastructure de conteneurisation

Afin d’étendre les capacités d’OpenClaw (notamment pour la recherche web que nous verrons juste après), nous avons besoin de services tiers. Docker permet de déployer ces services de manière isolée, standardisée et rapide, sans polluer notre système hôte avec de multiples dépendances complexes.

# Installation des dépendances initiales
sudo apt update
sudo apt install -y ca-certificates curl gnupg

# Ajout de la clé GPG officielle de Docker
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL [https://download.docker.com/linux/ubuntu/gpg](https://download.docker.com/linux/ubuntu/gpg) | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

# Configuration du dépôt Docker
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  [https://download.docker.com/linux/ubuntu](https://download.docker.com/linux/ubuntu) \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# Installation des paquets Docker
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Ajout de votre utilisateur au groupe docker pour éviter d'utiliser 'sudo' à chaque fois
sudo usermod -aG docker $USER
newgrp docker

# Vérification de l'installation
docker --version

5. SearXNG : Donner un accès au Web à l’IA

Pour qu’OpenClaw soit un véritable agent de recherche performant, il ne peut pas se contenter des données contenues dans le modèle Qwen (qui s’arrêtent à sa date d’entraînement). SearXNG est un métamoteur de recherche respectueux de la vie privée. En l’installant via Docker, nous offrons à OpenClaw une API (sur le port 8080) qu’il va pouvoir utiliser pour aller chercher en temps réel des informations sur le web et sourcer ses réponses.

# Créer un répertoire dédié pour la configuration
mkdir -p ~/searxng && cd ~/searxng

# Lancer le conteneur SearXNG
docker run -d \
  --name searxng \
  --restart unless-stopped \
  -p 8080:8080 \
  searxng/searxng

# Vérifier que le conteneur tourne correctement
docker ps

# Tester que l'API de SearXNG répond bien
curl http://localhost:8080

6. Homebrew & GCC : Les outils de compilation

L’écosystème Node.js d’OpenClaw fait parfois appel à des bibliothèques bas niveau ou à des packages natifs qui nécessitent d’être compilés directement sur votre machine lors de leur installation. Homebrew (le gestionnaire de paquets bien connu sur macOS, très pratique aussi sur Linux) et le compilateur GCC sont indispensables pour éviter les erreurs lors de la phase d’installation finale des dépendances (les fameux npm install).

# Installer le package de compilation de base Ubuntu
sudo apt-get install build-essential

# Installer Homebrew
/bin/bash -c "$(curl -fsSL [https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh](https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh))"

# Les instructions de fin d'installation d'Homebrew vous demanderont
# d'ajouter Homebrew à votre PATH. Généralement cela ressemble à ceci :
# (Assurez-vous d'adapter le chemin si nécessaire)
echo 'eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"' >> /home/$USER/.bashrc
eval "$(/home/linuxbrew/.linuxbrew/bin/brew shellenv)"

# Installation de GCC via Homebrew
brew install gcc

Conclusion

Votre machine virtuelle sous Nutanix AHV est désormais un environnement riche et complet, équipé de pilotes GPU performants, d’un moteur d’exécution (Node.js), d’un LLM prêt à répondre (Ollama), d’un accès au Web (SearXNG) et des bons outils de compilation.

Le terrain est parfaitement préparé. Il ne vous reste plus qu’à finaliser l’installation de l’application elle-même en suivant la suite de notre guide sur OpenClaw.

Read More

Nutanix AHV : déployer les Nutanix Guest Tools sur Rocky Linux 10

Published: 7 juillet 2026
Written by Julien D.
No comments
Categories: Nutanix, Nutanix AHV FR
header nutanix

Il y a quelques mois, j’avais rédigé un article concernant l’installation des NGT en CLI sur Linux.

Ayant récemment basculé vers Rocky Linux 10 pour les VM de mon lab, je me suis heurté à une problématique : la procédure utilisée jusqu’à présent ne fonctionne pas !

Sortie de la commande d'installation des NGT sur Rocky Linux 10

Voici comment contourner le problème…

Montage des Nutanix Guest Tools

Connectez vous à votre cluster Nutanix sur Prism Central, allez dans la liste des machines virtuelles, faites un clic droit sur la machine virtuelle sur laquelle vous souhaitez installer les NGT et cliquez sur « Install NGT » :

Menu Install NGT dans Prism Central

Sur l’écran suivant, dans mon cas pas besoin de changer quoi que ce soit, cliquez sur « Confirm and Enter Password » :

Options d'installation des NGT

On ne touche à rien sur cet écran, cliquez simplement sur « Skip and Mount » en bas à gauche :

Bouton Skip and Mount de l'installation des NGT

L’ISO est monté, on passe maintenant aux lignes de commande !

Installation des Nutanix Guest Tools (ex : Rocky Linux)

Voici les commandes à passer sur la machine virtuelle pour installer les Nutanix Guest Tools :

  • Mise à jour du système :
sudo dnf update -y && sudo dnf upgrade -y
  • Installation de python (si non présent sur la machine) :
sudo dnf install python3
  • Vérification de l’identifiant du lecteur :
blkid -L NUTANIX_TOOLS
  • Retour de commande:
/dev/sr0
  • Montage de l’ISO :
sudo mount /dev/sr0 /mnt
  • Passage en mode root

sudo su

  • Installation des NGT :
dnf install /mnt/installer/linux/ngt_rpm_installer/ngt_repo/nutanix-guest-agent-4.5.1-1.x86_64.rpm
Installation du paquet NGT avec dnf

  • Vérification de l’installation en ligne de commande :
yum list installed | grep 'nutanix-guest-agent'
Paquet nutanix-guest-agent 4.5.1 installé

Et coté Prism Central :

VM Rocky Linux 10.1 dans Prism Central
Read More

La fin du SSH sur Nutanix : Un passage inévitable aux API

Published: 17 mars 2026
Written by Julien D.
No comments
Categories: Nutanix, Nutanix AHV FR
Du CLI Nutanix aux API

Ceux qui suivent le blog depuis un moment se souviennent sûrement de ma série « Maxi Best-Of Nutanix CLI« . J’adorais l’écrire, et visiblement, elle a été utile plus d’une fois à certains d’entre vous. Mais avec la fin annoncée de la connexion SSH sur les clusters Nutanix, fini de lancer PuTTY pour se connecter en SSH sur une CVM (Controller VM) et taper nos commandes ncli ou du acli comme bon nous semble. Aujourd’hui, avec l’avènement des architectures Zero Trust et les exigences de conformité STIGs (Security Technical Implementation Guides du DoD américain), le verrouillage des accès bas niveau n’est plus une option de paranoïaque : c’est le standard de production.

Pourquoi l’API devient le seul maître à bord ?

Soyons très clairs : l’API REST c’est le nouveau couteau suisse indispensable de l’admin.

Cela avait commencé avec le durcissement progressif de nos infrastructures et notamment le cluster lockdown, mais la sentence est officiellement tombée fin janvier 2026 : Nutanix acte la fin de vie (EOSL) du « Bash Shell Access ». La raison est évidente. Laisser un accès Bash direct et sans restriction à l’OS sous-jacent (que ce soit sur AOS, AHV ou encore Prism Central) est devenu un non-sens absolu pour garantir la sécurité, l’auditabilité et la pérennité du support.

Voici la chronologie présentée dans le document :

  • Sous AOS 7.0 à 7.5, on a commencé à voir des avertissements à la connexion, l’apparition d’une alerte d’info prévenant de la désactivation de l’authentification SSH par mot de passe et des options pour désactiver SSH manuellement.
  • Dès la prochaine release majeure NCI, le Bash sera désactivé par défaut. À la place : un « SSH Service Menu » ultra-bridé permettant de lancer quelques commandes acli/ncli afin de pouvoir faire du troubleshooting de base.
  • Et pour fin 2026 ? Le « SSH Service Menu » est en place, le bash shell est désactivé, mais peut être réactivé en mode « Support-Only » via un jeton temporaire fourni lors du traitement d’un ticket avec le support Nutanix.

Le seul point d’entrée officiel, tracé et complet pour interagir avec l’infrastructure en ligne de commande devient l’API.

Que ce soit l’API Prism Element (v2.0) sur un cluster isolé, ou l’API Prism Central (v3/v4) pour le management multi-cluster, il n’y a plus d’échappatoire : il faut s’y mettre.

La boîte à outils des API

Avant de pouvoir effectuer des requêtes API vers nos clusters, il faut s’équiper.

Au quotidien, j’oscille entre deux outils de prédilection : Curl quand j’ai un terminal Linux/WSL sous la main (rapide, brut, scriptable), et Postman quand j’ai besoin d’explorer visuellement les APIs Nutanix.

Si votre poste de travail n’est pas encore prêt, je vous renvoie directement vers l’article dédié que j’ai déjà rédigé à ce sujet : Configurer son PC Windows pour interroger les APIs Nutanix (WSL & Postman).

Cependant, même bien outillé, je vois régulièrement des admins s’arracher les cheveux sur leurs premières requêtes Prism Element à cause de deux détails cruciaux.

Le certificat SSL : Par défaut, un cluster Prism Element utilise un certificat auto-signé. Si vous lancez une requête standard, elle sera violemment rejetée. Le réflexe terrain ? Toujours rajouter le flag -k (ou --insecure) dans vos commandes curl, et penser à désactiver l’option SSL certificate verification dans les settings de Postman.

L’authentification : L’API Prism Element v2.0 repose sur du Basic Auth. Evitez de passer vos identifiants en clair dans l’URL de votre requête (du style https://admin:MonSuperPass@IP...). Ça finit inévitablement en clair dans l’historique ou les logs. Sous Postman, utilisez les variables d’environnement !

Requête Get cluster details dans Postman

Explorer l’API avec le REST API Explorer intégré

Combien de fois vous êtes vous pris la tête en cherchant la bonne syntaxe dans un PDF de documentation de 500 pages ? Avec Nutanix, oubliez ça. La meilleure documentation n’est pas sur le portail de support, elle est directement embarquée dans votre cluster.

Prism Element intègre nativement une interface appelée REST API Explorer. Pour y accéder, c’est très facile : connectez-vous à l’interface web de votre cluster, cliquez sur votre nom d’utilisateur en haut à droite, puis sélectionnez REST API Explorer. Vous pouvez aussi taper directement l’URL : https://<CVM_IP>:9440/api/nutanix/v2/api_explorer/index.html.

La vraie puissance de ce Swagger, ce n’est pas juste de lister les endpoints (GET /cluster, POST /vms…). C’est sa capacité à coder pour vous ! Remplissez les champs requis dans l’interface et cliquez sur le bouton « Try it out! ». Non seulement l’interface exécute la requête et vous affiche le JSON de réponse brut, mais surtout, elle génère la commande curl complète et parfaitement formatée. C’est le hack absolu pour gagner du temps et éviter les erreurs de syntaxe.

Liste des API du REST API Explorer v2

Conclusion

Je ne vous le cache pas, passer du CLI à l’API REST m’a demandé un petit effort d’adaptation. Au début, j’ai tâtonné, j’ai râlé contre un header mal formaté ou un JSON capricieux. Mais une fois le cap franchi, cela devient presque naturel. L’API vous ouvre les portes de l’automatisation à grande échelle et de l’intégration continue. En revanche, vous ne pourrez malheureusement pas retrouver des équivalents à toutes les commandes CLI…

Dans le prochain article de cette série, on va rentrer dans le vif du sujet. Fini la théorie, on va attaquer la pratique avec notre premier cas d’usage concret : La vérification complète de l’état de santé d’un cluster.

Read More

OpenClaw sur Nutanix AHV : Guide d’installation de base

Published: 16 mars 2026
Written by Julien D.
1 Comment
Categories: IA, Nutanix, Nutanix AHV FR, Tech et Lab
openclaw on nutanix ahv

Si vous avez lu mon précédent article détaillant l’architecture et la stack technique que j’ai retenu pour déployer OpenClaw, vous savez déjà pourquoi j’ai choisi de faire tourner cette solution sur mon cluster Nutanix AHV. Aujourd’hui, on passe à la pratique ! Je vais vous montrer, étape par étape, comment déployer votre propre instance sur une machine virtuelle Ubuntu fraîchement installée.

Avant de lancer les hostilités, petit rappel de ma configuration. J’ai provisionné une VM sous Nutanix AHV avec :

  • 8 vCPU
  • 32 Go de RAM
  • 250 Go de stockage
  • une carte NVIDIA Tesla P4 en PCI Passthrough

💡 Pourquoi avoir privilégié le Passthrough complet plutôt que du vGPU (virtual GPU) ? Tout simplement pour garantir des performances d’inférence quasi « bare-metal ». En donnant un accès direct et exclusif au matériel physique à notre VM, on élimine totalement l’overhead (la latence) lié à la couche de virtualisation.

C’est parti pour le déploiement.

Préparation de la VM Ubuntu : Système et Pilotes NVIDIA

La toute première étape consiste à préparer le terrain pour déployer notre IA.

Ubuntu 24.04 : Mise à jour du système d’exploitation

C’est une règle que j’applique à chaque fois que je déploie un nouveau système d’exploitation. Dès que je me connecte en SSH, je m’assure que tous les paquets sont à jour pour éviter de futures failles de sécurité ou des conflits de dépendances.

sudo apt update && sudo apt upgrade -y

GPU : Installation des drivers NVIDIA

Pour qu’OpenClaw puisse exploiter la puissance de calcul de ma Tesla P4, le système d’exploitation doit être en mesure lui parler correctement. Voici les commandes à passer pour installer le drivers (vous pouvez accéder à un guide plus détaillé sur le blog) :

sudo apt install nvidia-driver-535-server -y
sudo reboot

Une fois la machine redémarrée, on se reconnecte et on tape la commande pour vérifier que notre GPU est bien détecté et prêt à travailler :

nvidia-smi
Résultat de nvidia-smi avec la Tesla P4 sur la VM OpenClaw

Node.js et OpenClaw

Installation de Node.js 22

OpenClaw est bâti sur Node.js. Pour s’assurer de disposer d’un environnement d’exécution récent et performant (ici la version 22), on ajoute le dépôt officiel de NodeSource avant de lancer l’installation :

curl -fsSL [https://deb.nodesource.com/setup_22.x](https://deb.nodesource.com/setup_22.x) | sudo -E bash -
sudo apt install -y nodejs

Déploiement de base d’OpenClaw

Maintenant que NodeJS est en place, on passe à l’installation d’OpenClaw. Un simple script curl fourni par les développeurs s’occupe du gros du travail :

curl -fsSL [https://openclaw.ai/install.sh](https://openclaw.ai/install.sh) | bash

Une fois l’installation terminée, le système lance automatiquement l’assistant de configuration de votre instance. Je détaillerai cette étape ainsi que les créations de clés API (Discord, Telegram, etc…) dans un futur article.

Avertissement de sécurité de l'assistant de configuration OpenClaw

Une petite manipulation est requise juste après l’installation d’OpenClaw si on veut pouvoir utiliser les commandes “openclaw” sans contrainte. Il faut ajouter le répertoire d’installation local à notre variable d’environnement PATH (pensez à adapter le nom d’utilisateur si vous n’utilisez pas administrateur) :

export PATH="/home/administrateur/.npm-global/bin:$PATH"

💡 Pourquoi cette manipulation ? C’est une excellente pratique de sécurité que je vous recommande. En exportant le PATH vers ~/.npm-global/bin, on évite d’installer des paquets globaux NPM avec les privilèges root (sudo). Cela réduit considérablement les surfaces d’attaque et vous épargne les éternels conflits de permissions sous Linux !

Exposer proprement OpenClaw avec Caddy

Par défaut, l’interface web d’OpenClaw écoute sur le port 18789. Au lieu d’attaquer ce port de manière brute, je préfère toujours placer un reverse proxy devant mes applications. Pour ce lab, mon choix s’est porté sur Caddy.

sudo apt install -y caddy

💡 Pourquoi Caddy plutôt qu’Apache ou Nginx ? Parce que Caddy est redoutablement efficace. Là où Nginx réclame parfois de longs blocs de configuration pour du proxying simple, Caddy accomplit le même travail en littéralement trois lignes de code, le tout de manière ultra légère.

On édite son fichier de configuration :

sudo vi /etc/caddy/Caddyfile

Et on remplace l’intégralité du contenu par les instructions suivantes (remplacez l’IP par celle de votre VM, dans mon cas 192.168.84.134) :

192.168.84.134 {
    reverse_proxy 127.0.0.1:18789
}

Il ne reste plus qu’à redémarrer le service pour que le proxy prenne le relais :

sudo systemctl restart caddy

Sécurité réseau : Verrouiller l’instance OpenClaw

Avoir une instance fonctionnelle c’est bien, la sécuriser c’est indispensable. Même si vous êtes sur votre réseau local (LAN), il ne faut jamais laisser l’accès libre à votre interface de contrôle. Nous allons appliquer une configuration stricte via les commandes CLI d’OpenClaw.

On commence par restreindre l’écoute de la Gateway à la boucle locale pour empêcher tout accès direct :

openclaw config set gateway.bind loopback

On force ensuite le mode de fonctionnement en local, et on active l’authentification par token (le minimum syndical) :

openclaw config set gateway.mode local
openclaw config set gateway.auth.mode token

Enfin, comme nous passons par Caddy, il faut autoriser les requêtes Cross-Origin (CORS) provenant de notre adresse IP, sans quoi le navigateur bloquera la page (n’oubliez pas d’adapter l’IP) :

openclaw config set gateway.controlUi.allowedOrigins '["[https://192.168.84.134](https://192.168.84.134)"]'

On redémarre le service pour appliquer notre blindage :

openclaw gateway restart

💡 Le pattern de sécurité appliqué ici s’apparente à du « Zero Trust » local. En forçant OpenClaw sur le loopback (127.0.0.1), on s’assure qu’absolument tout le trafic est obligé de passer par notre proxy Caddy. Couplé au filtrage CORS et à l’authentification, on protège un minimum notre instance contre d’éventuels scans ou scripts malveillants sur le réseau.

Premier contact et validation de la configuration

Récupération du Token d’accès

Maintenant que les portes sont fermées, il nous faut la clé. Le token d’authentification a été généré automatiquement lors de l’installation. On va aller le pêcher directement dans le fichier JSON de configuration :

grep -i token ~/.openclaw/openclaw.json

Copiez précieusement cette chaîne de caractères. Ouvrez ensuite votre navigateur et accédez à votre interface Web (ex: https://192.168.84.134).

Page de connexion du Gateway Dashboard OpenClaw

Entrez le token dans l’encart « Gateway Token ».

Approbation du périphérique

Une fois connecté, vous remarquerez qu’il manque quelque chose : le système attend que l’on approuve le « périphérique » (le PC ou la tablette depuis laquelle on souhaite utiliser OpenClaw) pour lui accorder le droit de traiter des requêtes.

Retournez dans votre terminal pour lister les périphériques en attente :

openclaw devices list

Repérez l’ID de votre périphérique dans la liste (une chaîne de type UUID) et approuvez-le :

openclaw devices approve b7beb7fa-fa4e-46e9-aec1-282bcce881f6

💡 L’approbation d’un périphérique (devices approve) est bien plus qu’une simple formalité d’interface. C’est une sorte de handshake cryptographique. Ce mécanisme garantit qu’aucune machine non sollicitée ne puisse se greffer à votre instance cluster OpenClaw à votre insu !

Tests d’interaction

L’instance OpenClaw est à présent 100% opérationnelle ! Pour valider l’ensemble de notre stack, rien de tel qu’un test grandeur nature. Vous pouvez envoyer un premier prompt sur le chat intégré de l’interface web, ou configurer un pont pour envoyer un message côté Discord.

Interface de chat d'OpenClaw

Conclusion

Nous sommes passés d’une simple VM Ubuntu à un véritable serveur d’inférence sécurisé, propulsé par Node.js et accéléré par un GPU NVIDIA Tesla P4 dédié via Nutanix AHV. L’architecture est propre, sécurisée derrière un proxy Caddy, et prête à encaisser nos requêtes.

Mais ce n’est que le début. Dans les prochains articles, nous irons encore plus loin : je vous montrerai comment configurer OpenClaw via l’assistant de départ, déployer des modèles locaux via Ollama, créer un bot Discord interactif, et même injecter des clés API Google pour doter notre IA de capacités de recherche. Restez connectés !

Read More

OpenClaw sur Nutanix AHV : Architecture et Stack Technique

Published: 13 mars 2026
Written by Julien D.
No comments
Categories: IA, Nutanix, Nutanix AHV FR, Tech et Lab
OpenClaw sur Nutanix AHV

Si vous suivez un peu mes pérégrinations sur le blog, vous savez que j’adore triturer mes clusters et tester des trucs un peu out-of-the-box (cf. mes articles avec le Steamdeck par exemple). Récemment, je me suis fait une réflexion : Gemini ou Claude dans le cloud public, c’est super pour coder un script Python ou rédiger des mails. Mais quand il s’agit de lui demander d’interagir avec notre infrastructure locale, c’est là que ça coince.

Je me suis donc demandé comment je pourrais connecter l’intelligence artificielle au plus près de mes VMs. C’est dans cette optique que j’ai mis les mains sur OpenClaw. Honnêtement, ça a un peu été le parcours du combattant au démarrage. Fini le simple gadget conversationnel, on parle ici de déployer une véritable IA Privée sur un cluster Nutanix AHV capable d’agir sur notre infrastructure. Laissez-moi vous présenter la stack technique que j’ai retenue pour cette expérience.

OpenClaw : qu’est-ce que c’est ?

Pour ceux qui vivaient dans une grotte ces derniers mois, OpenClaw c’est un projet GitHub qui a dépassé les 300k étoiles en seulement quelques mois. Imaginez un traducteur de pensée ultra-intelligent couplé à un majordome. Au lieu de cliquer sur des dizaines de menus dans une interface complexe, vous demandez simplement à votre infrastructure de travailler pour vous en langage naturel (via une interface web universelle ou même des messageries comme WhatsApp et Telegram). Il est même capable de bosser tout seul pendant que vous dormez !

Mais là où ça devient passionnant pour nous, les ingénieurs, c’est sous le capot. OpenClaw n’est pas un énième modèle de langage (LLM) « stateless » qui oublie tout à chaque nouvelle requête. C’est une véritable Agentic Gateway. Concrètement, cela signifie qu’elle orchestre des agents autonomes équipés d’outils. Ces agents peuvent être configurés pour taper directement dans les API privées de notre cluster (comme les API REST de Prism Element ou Prism Central), coder, parcourir le web et en synthétiser certaines informations. Bref, on ne pose plus simplement des questions à l’IA, on lui délègue des tâches.

Tableau de bord d'OpenClaw

Pourquoi l’héberger en Self-hosted ?

Sur le terrain, la question de la gouvernance des données se pose à la seconde où l’on prononce le mot « IA ». Hors de question d’envoyer des informations sensibles sur des serveurs dont je n’ai pas la maîtrise !

Faire le choix du Self-hosted (auto-hébergement) avec OpenClaw, c’est reprendre le contrôle absolu. Les flux de données, les logs d’exécution et les identifiants d’API restent cloisonnés bien au chaud sur mon réseau, isolés d’internet si on le souhaite.

Architecture et Stack Technique

Pour ce projet, hors de question de faire un simple « Next, Next, Finish » sur un coin de table. Voici l’architecture technique robuste que j’ai fini par valider pour mon déploiement.

Infographie de la stack technique de déploiement d'OpenClaw

Le socle : Nutanix AHV & Ubuntu 24.04 LTS

Pour faire tourner la bête, il faut des fondations solides. J’ai provisionné une machine virtuelle sous Ubuntu 24.04 LTS hébergée directement sur mon cluster Nutanix AHV.

Côté dimensionnement, je suis parti sur 8 vCPU, 32 Go de RAM et 250 Go de stockage dédié. Vous allez peut-être me dire : « 32 Go pour une gateway, c’est pas un peu too much ? » La gateway va devoir ingérer des flux de données conséquents, maintenir le cache des différents agents actifs, et potentiellement gérer du requêtage d’API lourd en parallèle. Et puis, je peux affecter ces ressources sur mon lab, alors pourquoi s’en priver ?

Le moteur applicatif : NodeJS 22

Au cœur d’OpenClaw, la magie opère grâce à NodeJS 22. C’est le moteur d’exécution qui fait tourner la gateway et ses intégrations d’agents IA.

Pourquoi Node 22 est un excellent choix architectural ici ? Pour sa gestion de l’asynchrone (Event Loop). Quand vous demandez à OpenClaw de faire un rapport d’état sur 50 VMs, la gateway va initier de multiples appels d’API vers Prism Central tout en maintenant votre flux WebSocket ouvert pour vous répondre en temps réel dans l’interface de chat. NodeJS excelle dans cette gestion de la concurrence non-bloquante.

Le routage réseau : Caddy

Le mode de fonctionnement habituel d’OpenClaw, c’est de le déployer en local sur la machine depuis laquelle on va s’y connecter, ou bien de monter un tunnel pour pouvoir accéder à l’instance distante. On ne va pas se mentir, j’avais envie de taper l’IP dans mon navigateur et de pouvoir accéder à mon instance, que je sois sur mon PC ou sur ma tablette.

Pour rendre ceci possible, j’utilise un reverse proxy sous Caddy. Caddy gère le routage du trafic et le chiffrement HTTPS de manière totalement automatisée.

Je vous entends déjà me dire : “Oui mais si un mec se connecte sur ton réseau local, il aura accès à ton instance !”. Eh bien non ! Parce qu’OpenClaw intègre nativement un système de Device Whitelisting (liste blanche de périphériques). Si votre PC n’a jamais été connecté à l’instance, vous devrez fournir le “Gateway Token”. Ensuite, vous devrez accepter cette nouvelle connexion du côté de l’instance OpenClaw. Vous l’aurez compris, seuls les périphériques préalablement autorisés peuvent profiter de votre instance locale.

Le point d’entrée : Discord

Le choix du point d’entrée, ce qui vous permettra d’interagir avec OpenClaw, c’est souvent une question de goûts et de couleurs.

OpenClaw intègre directement un système de chat pour que vous puissiez discuter avec lui. C’est bien, c’est natif, mais inaccessible si je ne suis pas chez moi. Le système propose également de configurer des points d’entrée externes comme Telegram, WhatsApp, Discord ou encore Teams et Slack. Et ça, c’est clairement un gros plus car cela donne des possibilités quasi illimitées !

Agent OpenClaw qui répond sur un serveur Discord

Et ensuite ?

L’objectif de cet article était de vous présenter l’architecture envisagée pour mon assistant OpenClaw, de comprendre ce que l’on déploie et pourquoi. Nous avons donc une stack technique cohérente, performante grâce à Nutanix AHV, et hébergée en local.

Dans un prochain article, je vous expliquerai comment installer OpenClaw étape par étape jusqu’à avoir une instance fonctionnelle.

Read More

Abonnez-vous