Team Leader - Nutanix Technology Champion - Nutanix NTC Storyteller

Julien DUMUR
Infrastructure in a Nutshell

Nutanix

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.
No comments
Categories: Nutanix, Nutanix AHV FR, Tech et Lab

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 :

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

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.

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.

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é !

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).

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 !

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 » :

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

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

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

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

Et coté 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

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 !

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.

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

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.

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).

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.

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

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.

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.

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 !

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

Configurer son PC Windows pour interroger les APIs Nutanix (WSL & Postman)

Published: 6 mars 2026
Written by Julien D.
No comments
Categories: Nutanix, Nutanix AHV FR
nutanix ahv api

Je vais être honnête : il y a quelques temps, le développement et les API, ce n’était pas vraiment ma tasse de thé. Mon terrain de jeu, c’était la console, le SSH, les commandes tapées à la volée.

Mais avec le blocage futur (et inéluctable) de l’accès SSH sur Prism Element et Prism Central, je n’ai pas eu le choix : il a fallu s’y mettre sérieusement.

Et quitte à plonger dans le monde des API Nutanix depuis mon PC Windows, autant le faire avec les bons outils pour ne pas s’arracher les cheveux. Dans cet article, je vous montre comment je me suis doté des outils parfaits pour interroger les API Nutanix.

Pourquoi optimiser son environnement Windows pour les API ?

Pendant des années, mon réflexe d’administrateur système face à une tâche complexe ou répétitive sur Nutanix a été le même : ouvrir PuTTY, me connecter en SSH à une Controller VM (CVM), et lancer des commandes ncli ou acli à la volée. C’était rapide, c’était efficace.

Mais je vais être direct : cette époque est révolue. Nutanix opère un virage sécuritaire majeur. L’accès SSH aux clusters sera désactivé dans l’une des prochaines versions, relégué au simple rang d’accès d’urgence pour le support. La seule méthode pérenne, supportée et évolutive pour interagir avec votre infrastructure, c’est l’API. Qu’il s’agisse de l’API v2 pour piloter un cluster local via Prism Element, ou des API v3 sur Prism Central, l’automatisation par API est devenue la norme.

Le problème ? Windows n’est historiquement pas le meilleur élève pour manipuler des requêtes web complexes en ligne de commande. PowerShell a fait d’énormes progrès avec Invoke-RestMethod, mais quand il s’agit de tester, débugger et formater du JSON imbriqué, rien ne remplace un socle Linux solide couplé à un client API graphique.

C’est là qu’entrent en jeu nos deux meilleurs alliés : WSL (Windows Subsystem for Linux) pour la puissance de la ligne de commande native, et Postman pour l’exploration visuelle des API Nutanix. Voyons comment mettre tout cela en musique.

Le socle système avec WSL (Windows Subsystem for Linux)

Comment éviter de s’arracher les cheveux avec les guillemets d’une commande curl sous l’invite de commande Windows (cmd) ou se battre avec l’échappement des caractères sous PowerShell ? La solution la plus élégante et robuste aujourd’hui est d’utiliser le sous-système Windows pour Linux (WSL).

Déployer WSL et Ubuntu en quelques minutes

L’installation est ultra simple sur les versions récentes de Windows 10 et 11. Ouvrez une console PowerShell en tant qu’administrateur et tapez simplement cette commande magique :

wsl --install ubuntu

Puis redémarrez votre PC. Vous avez maintenant une distribution Ubuntu fonctionnelle, totalement intégrée à votre Windows, sans la lourdeur d’une machine virtuelle classique. C’est l’environnement parfait pour faire tourner vos futurs scripts Bash ou Python ciblant l’infrastructure Nutanix.

Cherchez l’icone “Ubuntu” dans le menu démarrer de Windows pour lancer l’invite de commande sur le sous système.

Les paquets indispensables : curl et jq

Une fois dans votre nouveau terminal Ubuntu, il vous manque deux outils vitaux pour dialoguer avec les API REST : curl (le standard pour forger les requêtes web) et jq (le couteau suisse absolu pour manipuler, filtrer et formater les réponses JSON). Installez-les avec ces lignes de commande :

sudo apt update && sudo apt upgrade
sudo apt install curl jq -y

Pourquoi jq est-il si critique dans notre métier ? Laissez-moi vous partager une situation concrète du terrain. Les réponses JSON renvoyées par Prism Element ou Prism Central sont souvent extrêmement verbeuses. Si je veux simplement récupérer l’identifiant unique (UUID) de mon cluster via l’API v2 pour l’utiliser dans un script, sans me noyer dans des centaines de lignes de configuration, voici la commande exacte que j’utilise :

curl -k -u admin:MonMotDePasse -X GET https://<VOTRE_IP_PRISM_ELEMENT>:9440/api/nutanix/v2.0/cluster | jq '.cluster_uuid'

Le paramètre -k est crucial ici : il ignore l’avertissement de certificat SSL (qui est auto-signé par défaut sur Nutanix), et le | jq '.cluster_uuid' filtre instantanément la réponse brute pour ne me retourner que l’information ciblée (dans l’exemple ci dessous : "00064a67-579d-c757-5883-002590b8ef5a"). C’est propre, net, et parfaitement intégrable dans une variable pour automatiser un workflow de déploiement par exemple.

Le client API graphique incontournable : Postman

La ligne de commande, c’est génial pour exécuter des scripts de production. Mais quand il faut explorer une nouvelle API, tester les paramètres d’une requête complexe ou analyser la structure d’un payload JSON de 500 lignes, je préfère une interface graphique. Et dans ce domaine, Postman est parfaitement indiqué. Vous pouvez le télécharger et l’installer en quelques secondes depuis leur site officiel.

Configurer son premier environnement de travail

La première erreur que j’ai commise en débutant avec l’API Nutanix (et avec Postman en général), c’est de coder en dur mes adresses IP, mes usernames et mes mots de passe dans chaque requête. Ne faites jamais ça ! Non seulement c’est fastidieux si vous changez de cluster, mais c’est surtout un risque majeur de fuite d’informations si vous partagez votre écran ou vos collections.

Postman propose une fonctionnalité vitale : les Environnements. Créez un nouvel environnement (par exemple « Cluster de Prod ») et définissez-y trois variables :

  • cluster_ip : L’adresse IP de votre Prism Element ou Prism Central.
  • username : Votre compte de service (évitez d’utiliser le compte admin par défaut si possible).
  • password : Le mot de passe associé (à configurer en type « Secret » pour le masquer).

Désormais, dans vos requêtes, vous n’utiliserez plus l’URL brute, mais l’appel aux variables entre doubles accolades : https://{{cluster_ip}}:9440/api/nutanix/v2.0/...

L’astuce de l’expert : Importer le Swagger de Prism Central

Voici ma véritable astuce » pour vous faire gagner des heures. Les API Nutanix, particulièrement les API v3 sur Prism Central, sont extrêmement vastes. Plutôt que de créer vos requêtes GET, POST ou PUT une par une en lisant laborieusement la documentation sur le portail Nutanix.dev, saviez-vous que vous pouviez aspirer toute la configuration directement depuis votre propre cluster ?

L’API de Prism Central expose sa spécification OpenAPI (Swagger). Dans Postman, cliquez sur le bouton « File > Import » dans le menu en haut à gauche, choisissez « Link », et collez simplement cette URL (en remplaçant l’IP par celle de votre Prism Central) : https://<PRISM_CENTRAL_IP>:9440/static/v3/swagger.json

Laissez la magie opérer : Postman va interroger votre cluster et générer automatiquement une Collection complète contenant absolument toutes les requêtes API v3 possibles, préformatées avec les bons headers et les payloads d’exemple. C’est un gain de temps monstrueux pour l’exploration !

Test : Le premier Call API depuis Postman

Maintenant que l’outillage est prêt et que mes variables sont configurées. Il est temps de faire la première requête graphique vers le cluster pour récupérer ses informations globales.

Gérer l’authentification et contourner le piège du SSL

Créez une nouvelle requête dans Postman (bouton + ou New > HTTP Request). Sélectionnez la méthode GET et entrez l’URL suivante en utilisant notre variable : https://{{cluster_ip}}:9440/api/nutanix/v3.0/cluster

Avant de cliquer sur « Send », il nous reste deux réglages à réaliser :

  1. L’authentification : Allez dans l’onglet Authorization, choisissez le type Basic Auth. Dans les champs Username et Password, tapez respectivement {{username}} et {{password}}. Postman remplacera ces valeurs à la volée.
  2. Le certificat SSL : Par défaut, Nutanix utilise des certificats auto-signés. Si vous lancez la requête maintenant, Postman va bloquer l’appel avec une erreur de sécurité. Allez dans File > Settings (ou l’icône engrenage), onglet General, et désactivez l’option « SSL certificate verification ». C’est l’équivalent graphique de notre paramètre -k dans curl.

Cliquez sur Send. Si tout est vert (Status 200 OK), vous devriez voir apparaître en bas un magnifique JSON formaté, contenant l’UUID de votre cluster, son nom, sa version d’AOS et ses adresses virtuelles. Bravo, votre poste de travail communique avec Nutanix !

Basic Auth vs JSESSIONID

Si vous débutez, la méthode Basic Auth (qui envoie vos identifiants à chaque requête) est parfaite. Mais attention : cette méthode a un impact.

Pourquoi ? Parce qu’à chaque fois que vous faites un appel API en Basic Auth, le service Acropolis de la CVM doit valider vos identifiants auprès du module d’authentification (et souvent, ces identifiants seront lié à un Active Directory via LDAP). Si vous lancez un script qui fait 500 requêtes d’affilée pour inventorier des VMs, vous allez déclencher 500 validations d’identité. Cela sature inutilement les CVMs et vos contrôleurs de domaine.

La bonne pratique si vous scriptez massivement : Authentifiez-vous une seule fois, et utilisez les Cookies de session ! Lorsque vous faites une première requête d’authentification ou que vous interrogez l’API, Nutanix vous renvoie un cookie nommé JSESSIONID. Postman le stocke automatiquement et l’utilise pour les requêtes suivantes de votre collection. Dans vos futurs scripts Bash/Python, pensez toujours à récupérer ce cookie lors du premier appel, et passez-le dans les Headers de vos appels suivants. Vous soulagerez drastiquement le management plane de votre cluster !

Conclusion : Rappel de sécurité et utilisation avancée

Tous les outils sont désormais en place pour s’affranchir au maximum du SSH lors de mes prochaines sessions troubleshooting.

Je dois faire un rappel de sécurité fondamental. Postman permet d’exporter vos collections pour les partager avec vos collègues ou les sauvegarder. C’est génial pour le travail en équipe. Mais attention : si vous n’avez pas utilisé les variables d’environnement comme nous l’avons vu précédemment, et que vous avez tapé vos mots de passe « en dur » directement dans l’onglet Authorization de vos requêtes, ils seront exportés en clair dans le fichier JSON de la collection.

Assurez-vous toujours que vos « Secrets » restent dans votre configuration d’Environnement locale (qui, par défaut, n’exporte pas les valeurs actuelles avec la collection). J’ai vu trop de mots de passe d’administration traîner sur le réseau à cause de ça !

Maintenant, il ne me reste plus qu’à me pencher sur la partie scripting et automatisation afin de pouvoir développer des applications qui m’aideront à piloter, auditer et configurer mes clusters Nutanix.

Mais ça, ce sera le sujet d’un prochain article ! D’ici là, bonnes requêtes à tous.

Read More

Nutanix AHV : déployer une VM Ubuntu 24.04 avec un GPU NVidia Tesla P4

Published: 27 février 2026
Written by Julien D.
No comments
Categories: Linux, Nutanix, Nutanix AHV FR
Nutanix AHV GPU Linux

L’intégration de puissance de calcul graphique au sein d’environnements virtualisés est devenue un incontournable. Que ce soit pour faire tourner des modèles d’Intelligence Artificielle, du Machine Learning ou simplement pour du traitement vidéo intensif, nos machines virtuelles ont de plus en plus besoin de muscles.

Lorsque je discute avec des clients, je reçois souvent des questions à ce sujet : comment assigner une carte graphique physique à une VM de manière simple et performante ?

Aujourd’hui, je vous propose de voir ensemble comment déployer un GPU NVIDIA Tesla P4 sur une VM Ubuntu Server 24.04 hébergée sous Nutanix AHV, en utilisant le mode « Passthrough ».

1. Les prérequis

Avant de mettre les mains dans le cambouis, prenons un instant pour vérifier notre équipement. Une bonne préparation, c’est la moitié du travail de fait ! J’ai moi-même perdu des heures par le passé à cause d’un simple prérequis oublié.

Pour suivre ce tutoriel, vous aurez besoin de :

  • Un nœud Nutanix (cluster physique) équipé d’au moins une carte NVIDIA Tesla P4.
  • Une machine virtuelle sous Ubuntu Server 24.04.
  • Un accès SSH fonctionnel vers cette VM avec des privilèges sudo.

Bien que Nutanix AHV gère cela de manière transparente pour vous, gardez en tête que le mode Passthrough repose sur des instructions matérielles spécifiques. Il nécessite que les extensions de virtualisation des I/O (VT-d chez Intel ou AMD-Vi chez AMD) soient bien activées au niveau du BIOS de votre nœud physique. Si un jour vous montez un cluster « home-lab », c’est la première chose à vérifier !

2. Configuration côté Nutanix : Le mode Passthrough

Maintenant que notre base est solide, passons à l’interface d’administration. C’est ici que la magie opère. Que vous utilisiez Prism Element ou Prism Central, la logique reste la même. Assurez-vous d’abord que votre machine virtuelle est bien éteinte.

Allez dans les paramètres de votre VM, sélectionnez « Update », puis descendez jusqu’à la section « GPUs ». Cliquez sur « Add GPU ».

Dans la fenêtre qui s’ouvre, le choix est crucial : dans le menu déroulant « GPU Type », sélectionnez le mode Passthrough, puis choisissez votre Tesla P4 dans la liste.

Le mode Passthrough est une fonctionnalité particulière : il permet de « donner les clés » matérielles de la carte graphique directement à la machine virtuelle. L’OS invité a l’illusion (et les avantages) de posséder la carte physiquement.

Vous vous demandez peut-être pourquoi nous privilégions le Passthrough plutôt que le vGPU ? C’est une question de cas d’usage, mais aussi d’architecture.

Le vGPU permet de découper virtuellement une carte pour la partager entre plusieurs VMs, ce qui est génial pour du VDI, mais il nécessite l’installation et la maintenance d’un serveur de licences NVIDIA (vGPU Software).

Le Passthrough, en revanche, dédie 100% de la puissance de la Tesla P4 à notre VM Ubuntu, sans aucun serveur de licence additionnel. Pour un besoin de performance brute mono-VM, c’est clairement la meilleure option.

3. Préparation et mise à jour d’Ubuntu 24.04

Une fois le GPU attaché, sauvegardez la configuration, allumez votre VM et connectez-vous en SSH.

Avant de nous précipiter sur l’installation des drivers NVIDIA, il y a une étape que je ne saute absolument jamais : la mise à jour du système.

Tapez simplement cette commande :

sudo apt update && sudo apt upgrade -y

Les pilotes propriétaires NVIDIA s’appuient sur le système DKMS (Dynamic Kernel Module Support) pour compiler les modules du noyau à la volée lors de l’installation.

Si vos en-têtes de noyau (kernel headers) ne sont pas parfaitement synchronisés avec votre version actuelle du noyau linux, l’installation échouera silencieusement. Un système fraîchement mis à jour est votre meilleure garantie pour une compilation propre et sans accroc !

4. Installation des drivers NVIDIA (Branche Server)

Maintenant que notre système est propre et à jour, passons au plat de résistance. Sous Ubuntu, on a souvent le réflexe d’utiliser la commande ubuntu-drivers autoinstall ou d’installer la dernière version « desktop » à la mode. Je vous arrête tout de suite !

Pour un serveur, surtout en production, la stabilité est le maître mot. C’est pourquoi nous allons installer la branche « Server » du pilote. Tapez la commande suivante :

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

💡 L’astuce de l’Expert : Pourquoi précisément le paquet « server » ? NVIDIA maintient des branches de pilotes spécifiques pour les data centers. La branche « Server » (ou Tesla driver) est conçue pour des cycles de vie longs (LTS) et minimise le risque de régression. Installer un pilote « Desktop » sur un hyperviseur ou un serveur IA, c’est s’exposer à ce qu’une mise à jour mineure casse votre environnement de production un vendredi à 17h !

Laissez l’installation se terminer (cela peut prendre quelques minutes le temps que DKMS compile le module pour votre noyau). Une fois terminé, un redémarrage est obligatoire pour charger correctement le pilote :

sudo reboot

5. Vérification

Après le redémarrage, reconnectez-vous en SSH à votre machine virtuelle. Pour vérifier que l’OS, le pilote et le matériel communiquent parfaitement, NVIDIA nous fournit un outil en ligne de commande :

nvidia-smi

Si tout s’est bien passé, vous devriez voir apparaître un magnifique tableau de bord en ASCII.

💡 Décryptage : En haut à droite, notez la CUDA Version (ici 12.2) : c’est la version maximale de l’API CUDA supportée par ce pilote, une info cruciale pour les développeurs IA. Regardez aussi la colonne Perf : elle indique « P0 », ce qui correspond à l’état de performance maximum (les « P-states » vont de P0 à P12 pour l’économie d’énergie). Si votre carte reste bloquée sur un P-state bas alors qu’elle est en charge, c’est qu’il y a un souci matériel ou thermique ! Enfin, cet output confirme que l’OS est prêt à accueillir le NVIDIA Container Toolkit (pour du Docker avec GPU).

Conclusion

Et voilà ! En quelques étapes simples, nous avons réussi à présenter physiquement notre GPU NVIDIA Tesla P4 à notre VM Ubuntu 24.04 sous Nutanix AHV. Le mode Passthrough nous a permis d’obtenir une configuration performante, sans latence et sans l’usine à gaz d’un serveur de licences externe.

Notre Tesla P4 est désormais correctement installée ! La prochaine étape logique ? Le déploiement de modèles LLM (Large Language Models) ou d’applications gourmandes en calcul dans des conteneurs isolés. Mais ça, ce sera pour un prochain article sur le blog !

Read More

L’Hyperconvergence (HCI) : la fin de l’ère monolithique

Published: 12 février 2026
Written by Julien D.
No comments
Categories: Nutanix, Nutanix AHV FR

Je n’oublierai jamais le jour où la réalité de l’hyperconvergence m’a scotché. Nous étions en pleine migration d’infrastructure. D’un côté, nous avions deux baies complètes de 42U de l’ère 3-tiers remplies de serveurs et de baies de stockage. De l’autre, pour les remplacer, nous n’avions besoin que de… 6U.

Deux blocs Nutanix de 2U (4 noeuds dans chacun des blocs) et deux switchs Top of Rack. C’était tout. 84 unités de rack réduites à 6. Le contraste était si violent qu’il en devenait presque suspect. Comment une si petite empreinte physique pouvait-elle remplacer nos armoires historiques ?

Mais ne vous y trompez pas. Sous cette apparente simplicité se cachait une rupture technologique majeure. Nous étions passés d’une ère « Hardware-Defined », où l’intelligence résidait dans des ASIC propriétaires coûteux, à l’ère du « Software-Defined ».

Ce vide dans les racks n’était pas juste esthétique. Il racontait une autre histoire : celle d’une densité qui explosait, changeant radicalement l’équation économique du datacenter. Moins de refroidissement, moins d’espace locatif, moins de consommation électrique pour une puissance de calcul décuplée. La baie de stockage n’avait pas disparu : elle avait été absorbée et virtualisée par le logiciel.

L’héritage des géants du Web

Pour comprendre d’où vient cette magie, il faut remonter au début des années 2000, loin des salles serveurs d’entreprises climatisées, dans les laboratoires de Google et d’Amazon.

À cette époque, ces géants faisaient face à un mur : le modèle 3-tiers ne passait pas à l’échelle. Pour indexer le web entier, utiliser des baies de stockage traditionnelles type EMC ou NetApp aurait coûté extrêmement cher. Ils devaient trouver une autre voie.

Leur coup de génie a été de renverser la table. Au lieu d’acheter du matériel « Premium » conçu pour ne jamais tomber en panne (et vendu à prix d’or), ils ont décidé d’utiliser du « Commodity Hardware ». Des serveurs x86 standards, bon marché, presque jetables.

La philosophie a changé du tout au tout : le matériel va tomber en panne. C’est une certitude statistique. Plutôt que de lutter contre cette réalité avec des composants redondants, ils ont décidé de gérer la panne au niveau du logiciel.

Pour les puristes et les historiens de la tech, le moment fondateur tient en un document PDF publié en octobre 2003 : « The Google File System« . Ce papier de recherche (SOSP’03) est la bible de l’infrastructure moderne. Il décrit un système où des milliers de disques durs peu fiables sont agrégés par un logiciel intelligent qui assure la résilience. Si un disque meurt ? Le système s’en moque. Pas besoin de courir remplacer le disque à 3h du matin. Le logiciel a déjà répliqué les données ailleurs.

L’Hyperconvergence, c’est simplement l’arrivée de cette technologie « Web Scale », packagée et démocratisée pour nos entreprises.

Anatomie d’un nœud HCI : Comment ça marche ?

Concrètement, qu’est-ce qui change au niveau matériel ? Dans une infrastructure hyperconvergée, on ne sépare plus le calcul (Compute) et le stockage (Storage). Tout est réuni dans le même châssis, qu’on appelle un « Nœud » (Node).

Chaque nœud contient ses propres processeurs, sa RAM, et ses propres disques (SSD, NVMe, HDD). Mais contrairement à un serveur classique, ces disques ne servent pas juste à installer l’OS local. Ils sont agrégés avec les disques des autres nœuds du cluster pour former un espace de stockage global.

C’est là qu’intervient la véritable révolution : la CVM (Controller VM).

Imaginez que l’on ait pris les contrôleurs physiques de votre ancienne baie SAN (la partie compute) et qu’on les ait transformés en logiciel. Sur chaque serveur physique du cluster, une machine virtuelle spéciale (la CVM) tourne en permanence. C’est elle le chef d’orchestre.

Pour l’expert technique, le tour de force réside dans la gestion du matériel. L’hyperviseur (ESXi ou AHV) ne gère pas les disques de stockage. Grâce à une technologie appelée PCI Passthrough (ou I/O Passthrough), elle contourne l’hyperviseur pour parler aux disques. Résultat : des performances brutes sans l’overhead de virtualisation habituel.

Les Forces de l’hyperconvergence

Au-delà de l’effet de mode, trois arguments techniques ont fait mouche dans les entreprises.

1. Le Scale-Out (L’approche LEGO)

Fini le casse-tête du dimensionnement sur 5 ans. Avec le 3-Tiers, quand la baie était pleine, c’était la panique (Scale-Up). Avec le HCI, si vous avez besoin de plus de ressources, vous achetez un nouveau nœud et vous le branchez. Le cluster absorbe automatiquement la nouvelle puissance CPU et la nouvelle capacité de stockage. C’est une croissance linéaire et prédictible.

2. La Localité de la Donnée (Data Locality)

C’est le Graal de la performance. Dans une architecture classique, la donnée devait traverser le réseau SAN pour arriver au processeur. Avec l’HCI, l’intelligence logicielle s’assure que les données utilisées par une VM sont (dans la mesure du possible) stockées sur les disques du serveur physique où elle s’exécute. Le trajet est quasi-instantané. Le réseau n’est plus un goulot d’étranglement.

3. Le Rebuild Distribué (Many-to-Many)

C’est souvent l’argument qui achève de convaincre les administrateurs traumatisés par les reconstructions RAID. Sur une baie classique (RAID 5 ou 6), si un disque de 4 To casse, un seul disque de secours (« hot spare ») doit tout réécrire. Cela peut prendre des jours, pendant lesquels les performances s’effondrent. En HCI, la donnée est répliquée en morceaux partout dans le cluster. Si un disque meurt, tous les autres disques de tous les autres nœuds participent simultanément à la reconstruction des données manquantes. On passe d’un problème « 1 to 1 » à une solution « Many to Many ». Résultat : on retrouve la résilience en quelques minutes.

Les Faiblesses : Ce que le marketing oublie de dire

Si l’hyperconvergence semble magique, elle n’est pas exempte de défauts. En tant qu’expert, il est crucial de comprendre les contreparties de cette architecture.

La première, c’est la « Taxe CVM ». L’intelligence n’est pas gratuite. Puisque le contrôleur de stockage est désormais logiciel, il consomme des ressources CPU et RAM qui ne sont plus disponibles pour vos applications. Sur de très petits clusters, réserver 20 Go ou 24 Go de RAM par nœud juste pour « faire tourner la boutique » peut sembler lourd, même si c’est le prix de la tranquillité.

La seconde limitation technique, c’est la dépendance critique au réseau « Est-Ouest ». Dans une baie 3-Tiers, le trafic de réplication restait confiné dans la baie. En HCI, pour sécuriser une donnée (RF2 ou RF3), la CVM doit l’écrire localement, mais aussi l’envoyer immédiatement via le réseau sur un autre nœud. Si votre réseau 10/25 GbE est instable ou mal configuré, c’est toute la performance et la stabilité du cluster qui s’effondrent. Le réseau n’est plus une simple commodité, c’est le centre nerveux de votre cluster. Je le répète à chaque client : un cluster HCI c’est 80% de réseau. Si votre réseau à un problème, votre cluster HCI a un problème.

Nutanix, le pionnier

L’hyperconvergence a marqué la fin d’une époque. Elle a prouvé que le logiciel pouvait supplanter le matériel spécialisé, transformant nos datacenters rigides en clouds privés agiles.

Mais une idée, aussi brillante soit-elle (comme le Google File System), ne sert à rien si elle reste confinée dans un laboratoire de recherche. Il fallait quelqu’un pour prendre ces concepts complexes et les rendre accessibles à n’importe quel administrateur système en moins d’une heure.

C’est là qu’entre en scène Nutanix.

Fondée par des anciens de Google qui avaient travaillé sur le GFS, cette entreprise a créé le NDFS (Nutanix Distributed File System). Ils ont réussi le pari fou de faire tourner une infrastructure de type « Google » sur des serveurs Dell, HP ou Lenovo standards.

Comment Nutanix a-t-il réussi à devenir le leader incontesté de ce marché, survivant même à l’assaut de VMware avec vSAN ? C’est ce que nous décortiquerons dans le prochain article de cette série.

Read More