Team Leader - Nutanix Technology Champion - Nutanix NTC Storyteller

Julien DUMUR
Infrastructure in a Nutshell

Author: Julien D.

Urgence et budget : Pourquoi j’ai imprimé en 3D des adaptateurs de disques

Published: 3 avril 2026
Written by Julien D.
2 Comments
Categories: Lifestyle, Tech et Lab

On a tous connu ce moment de solitude dans notre parcours professionnel. Celui où tu as planifié l’upgrade matériel pour ton infrastructure, mais où un détail insignifiant vient perturber le déroulé des opérations. Récemment, nous devions remplacer les disques mécaniques 3.5 pouces d’un de nos clusters de 4 nœuds par des disques SSD 2.5 pouces. Une opération de maintenance classique pour passer d’un stockage hybride a une stockage full-flash et gagner en IOPS.

Seul problème, et de taille : les caddys d’origine des serveurs n’étaient pas compatibles avec ce format réduit.

Première approche : les adaptateurs “officiels”

La solution évidente quand on gère une infra pro ? Commander des adaptateurs officiels ou des caddys de remplacement. Il nous fallait 24 pièces au total (6 disques pour chacun des 4 nœuds). Et là, c’est la douche froide.

Plus de 500 euros (avec les taxes et la livraison).

Mais le pire n’était finalement pas le prix : c’était le délai d’approvisionnement. Attendre plusieurs semaines alors que le projet devait avancer ? Inenvisageable. Puisque je refuse de payer ce tarif et que les délais sont beaucoup trop longs, mon imprimante 3D va s’en charger.

La plan B : la solution DIY

L’avantage d’avoir du matériel standard comme du Supermicro, c’est que l’on n’est jamais le premier à rencontrer un problème. Pas besoin de passer des heures sur Fusion 360 à modéliser la pièce au millimètre près : la communauté open-source l’a probablement déjà fait.

En quelques clics sur les plateformes de partage de modèles 3D (comme Printables ou Thingiverse), j’ai déniché le fichier .stl parfait : https://www.thingiverse.com/thing:4353094

Pour m’assurer de la compatibilité, j’en ai imprimé un rapidement pour valider les dimensions et que cela faisait le job…

L’étape suivante : l’industrialisation. J’ai positionné mes modèles de sorte de pouvoir imprimer 6 adaptateurs d’un seul coup. Cela impliquait de laisser tourner l’imprimante pendant 7h30 environ pour chaque plateau.

Sur ma Creality CR-10S Pro v2 tournant sous Klipper, j’ai pu monitorer le job d’impression pour m’assurer que tout se passait comme prévu du coin de l’oeil tout en continuant à travailler sur mes projets.

Malgré un couac lors du premier batch qui m’a contraint à faire un peu de mécanique, les impressions se sont parfaitement bien déroulées.

Maker Spirit for the Win !

Le verdict final est sans appel :

  • Option Fournisseur : ~543 € et 3 semaines d’attente.
  • Option Maker : 20 € de filament, quelques kWh et deux grosses journées d’impression.

Au-delà de l’économie financière évidente (pour le prix des adaptateurs officiels, on aurait pu acheter l’imprimante + le filament), la vraie leçon de cette aventure, c’est que l’état d’esprit maker permet de transformer une problématique budgétaire et temporelle en une solution DIY 20 fois moins chère et qui fait le job dans des délais ultra-courts.

Alors, la prochaine fois qu’un problème pointe le bout de son nez, pensez “out-of-the-box” et éventuellement, dégainez votre plus belle bobine de filament.

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.
No comments
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

Lovable vs Gemini : J’ai codé la même app et le résultat est sans appel

Published: 18 février 2026
Written by Julien D.
No comments
Categories: Tech et Lab

Le codage assisté par IA, pour moi qui suis une buse en développement, c’est une révolution qui me permet de concrétiser des idées en quelques heures là où cela relevait de l’impossible auparavant. Mais cette vitesse a un prix que l’on néglige trop souvent : la dette technique.

Le contexte de développement

Récemment, j’en parlais ici, j’ai développé une petite application web nommée HYCU Upgrade Path. Le concept est simple : une interface épurée pour générer et visualiser l’upgrade path d’une version A à une version B du logiciel de backup.

Pour ce faire, j’ai utilisé Lovable, une solution « no-code/low-code » qui m’a permis en quelques jours de mettre l’application en ligne.

Quelques semaines plus tard, j’ai décidé de redévelopper l’application à l’aide de Gemini, l’IA multimodale de Google, pour voir ce qu’elle avait dans le ventre.

J’ai donné des instructions similaires à chacune des 2 IA. J’attendais un résultat fonctionnel et similaire des deux côtés. Ce que je n’avais pas prévu, c’est l’écart abyssal dans la structure du code… Et le temps passé.

On parle d’une différence de 628ko contre 115ko. On parle de passer de 79 fichiers à 21 fichiers. On parle d’une semaine contre une demi journée. Un gouffre.

L’expérience Lovable

Sur le papier Lovable vend du rêve : vous décrivez, ça s’affiche. Et c’est vrai, l’expérience utilisateur est bluffante de fluidité. J’ai décrit mon besoin pour HYCU Upgrade Path, et en quelques itérations, l’application tournait sous mes yeux. Visuellement, c’était propre avec quelques ajustements à faire. Fonctionnellement, c’était un peu plus bancal.

Je ne suis pas développeur, mais mon premier réflexe a été d’aller voir le repository généré. Et là… ça a été la douche froide.

Pour une application aussi simple qu’un générateur d’upgrade path, Lovable m’a pondu une véritable usine à gaz :

  • 79 fichiers créés.
  • 8 dossiers imbriqués.
  • Un poids total de 628ko.

Lovable a fragmenté l’application en une myriade de petits composants atomiques, a généré des fichiers de configuration en doublon et a importé des librairies « au cas où ». En regardant le dossier components/ui, j’ai trouvé 38 fichiers ! Des accordéons, des badges, des carrousels, des « toasters »… alors que mon app n’utilise qu’une fraction de tout ça.

C’est l’approche « Black Box » : tant que ça marche en façade, on ne se soucie pas de l’élégance du moteur. Le résultat est une application lourde et difficilement maintenable dans le temps. Et ça pour moi, c’est un premier red flag.

Coté modification du code par itération, je ne l’ai pas trouvé très précise. J’ai été contraint d’avancer par toutes petites itérations ce qui a rallongé le temps de développement… Une itération un peu trop musclée ? Ca cassait une fois sur deux mon interface ou donnait un résultat qui n’était pas celui attendu. Bref, pas hyper satisfait de l’expérience bien que j’ai réussi à atteindre mon but en une petite semaine de discussions.

L’expérience Gemini : L’architecte logiciel

Après cette semaine de lutte et quelques semaines en production, j’ai tenté la même expérience avec Gemini. Même prompt, même besoin, juste “pour voir” de quoi l’IA de Google était capable.

Le résultat ? Au départ, j’ai cru qu’il manquait des morceaux.

  • 21 fichiers au total.
  • 5 dossiers.
  • 115ko sur la balance.
  • Temps de développement : une demi-journée.

Gemini a adopté une approche radicalement différente, bien plus mature. Au lieu d’importer une librairie graphique massive, il a structuré le code et n’a gardé que ce qui était réellement nécessaire.

En ouvrant le dossier src/components, la différence est flagrante : 7 fichiers, tous essentiels. Pas de bruit, pas de composants inutiles.

Plus impressionnant encore, Gemini m’a fourni une architecture « Prête à mettre en prod ». Là où Lovable m’a donné un frontend en vrac, Gemini a séparé proprement le frontend du backend, et m’a même généré un docker-compose.yml et un script de déploiement (deploy.sh) pour mon VPS. Il n’a pas juste codé l’interface, il a pensé à comment je la ferais tourner, avec un joli README.md en prime.

Pour le plaisir, j’ai ajouté quelques détails supplémentaires sur mon application au passage.

Le Match Technique : L’obésité vs L’efficacité

Comparons ce qui est comparable. Voici le bilan des courses pour la même fonctionnalité :

MétriqueLovableGeminiGain
Poids du projet628 ko115 ko-82%
Nombre de fichiers7921-73%
PhilosophieUI Kit complet (« au cas où »)Code propre, lisibleMaintenance facilitée
ArchitectureFrontend monolithiqueDockerisé (Front + Back)Prêt à déployer
Temps de dev1 semaine1/2 journéeProductivité x10

Pourquoi la « propreté » compte (même pour les non-devs comme moi) ?

Vous pourriez me dire : « On s’en fiche du code ou du nombre de fichiers tant que l’app fonctionne ! ». C’est une erreur.

La maintenance : Modifier à la main le projet créé sous Lovable, c’est chercher une aiguille dans une botte de 79 fichiers. Avec Gemini, chaque fichier a un nom qui décrit réellement ce qu’il fait.

La consommation : 628ko de code à charger pour un utilisateur mobile, c’est lourd. 115ko, c’est presque instantané.

Le coût cognitif : Quand l’IA génère du code « brouillon », elle a elle-même plus de mal à se relire pour les itérations suivantes. C’est pour ça que Lovable « cassait » l’interface : elle se perdait dans sa propre complexité.

Conclusion : Le choix de l’outils fait la différence

Mon verdict est sans appel. Si vous voulez prototyper une idée en 10 minutes pour montrer que « ça bouge » à votre boss, Lovable fait illusion. C’est spectaculaire, c’est visuel, c’est une belle démo technologique.

Mais si vous voulez construire une application pérenne, que vous pourrez faire évoluer sans tout casser, une IA comme Gemini est bien plus performante à mes yeux.

L’écosystème évolue vite. Je ne l’ai pas testé pour le moment, mais un outils comme Claude Code doit même surement être capable de faire encore mieux.

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

Nutanix AHV : Éteindre proprement un cluster

Published: 10 février 2026
Written by Julien D.
1 Comment
Categories: Nutanix, Nutanix AHV FR

On ne va pas se mentir : éteindre un cluster Nutanix complet, c’est toujours un moment un peu stressant. Même après 15 ans de métier. Pourquoi ? Parce qu’on a beau avoir la meilleure techno HCI du marché, couper le courant sur une infrastructure informatique n’est jamais anodin.

J’ai vu trop de « cowboys » tirer la prise ou faire un « Shutdown » brutal via l’IPMI en pensant que la résilience des données ferait le reste. Spoiler : ça finit souvent avec un support Nutanix niveau 3 pour récupérer des métadonnées Cassandra corrompues ou avec la perte d’un ou plusieurs disques.

Ce guide, c’est ma ligne de vie pour m’assurer que mon cluster redémarrera sans problème. Pas de GUI, pas de Prism Element pour les étapes critiques. On ouvre le terminal, on se connecte en SSH, et on fait ça proprement.

Phase 1 : Le Health Checks

Avant même de penser à arrêter la moindre VM, il faut s’assurer que le cluster est capable de s’arrêter (et surtout de redémarrer). Si votre cluster est déjà en souffrance, l’éteindre n’est pas toujours une bonne option.

1.1 Connexion en SSH a la CVM

Ouvrez votre terminal préféré (PuTTy fait très bien l’affaire) et connectez-vous en SSH à l’adresse IP virtuelle du cluster (Cluster VIP) avec l’utilisateur nutanix.

1.2 Nutanix Cluster Checks (NCC)

Pour s’assurer que le cluster est en bonne santé, il est nécessaire de lancer un NCC. Lancez un check complet :

ncc health_checks run_all

Mon conseil : Ne survolez pas le rapport. Si vous avez un « FAIL » sur la partie Cassandra, Zookeeper ou Metadata, STOP. On répare avant d’éteindre. Un warning sur un disque plein ou une vieille alerte NTP, ça passe. Mais l’intégrité des données, c’est non-négociable.

1.3 Vérification de la résilience

Le dashboard Prism est joli, il vous dit « Data Resiliency Status: OK ». C’est bien, mais ce n’est pas assez précis pour un arrêt total. Je veux savoir si mes données sont réellement synchronisées, maintenant.

Tapez cette commande et regardez-la dans les yeux :

ncli cluster get-domain-fault-tolerance-status type=node

Ce que vous devez voir : Une ligne indiquant Current Fault Tolerance: 2.

Si vous voyez un état indiquant une reconstruction en cours, n’éteignez pas le cluster et patientez pendant la reconstruction.

Phase 2 : L’extinction des machines virtuelles

Une fois le cluster validé comme sain, on passe aux machines virtuelles. L’erreur classique est de se précipiter sur l’arrêt des nœuds, mais il vous sera refusé si des machines virtuelles sont toujours allumées sur le cluster.

2.1 L’ordre de bataille

Commencez par éteindre vos environnements de test/dev, puis les serveurs applicatifs, et enfin les bases de données. C’est du bon sens, mais il est toujours bon de le rappeler.

Une fois l’ensemble des machines de production éteintes, vous pouvez maintenant éteindre le reste des machines virtuelles “outils” de votre infrastructure : AD, DNS, firewalls…

2.2 La gestion de Prism Central

Connectez vous à Prism Central en SSH avec le compte nutanix puis lancez la commande d’arrêt :

cluster stop

Patientez pendant l’arrêt des services de la PCVM et vérifiez que le cluster est bien éteint :

cluster status

Si l’ensemble des services sont éteints et que le statut du cluster est “stop”, nous pouvons maintenant procéder à l’arrêt de la PCVM :

sudo shutdown -h now

Phase 3 : L’arrêt des services Nutanix (« Cluster Stop »)

Vos VMs et Prism Central sont éteints. Vos hôtes ne font plus tourner que les CVMs (Controller VMs). C’est le moment critique. On ne fait jamais un shutdown de l’OS des CVMs sans avoir d’abord arrêté les services du cluster proprement.

Pourquoi ? Parce qu’un arrêt brutal des CVMs peut entrainer une corruption des données ou une inconsistances des métadonnées qui pourra nécessiter l’intervention du support.

3.1 L’arrêt du cluster

Reconnectez vous à la VIP de votre cluster Nutanix et tapez simplement :

cluster stop

Le système va demander une confirmation avant de lancer les opérations. Tapez Y.

Cette commande ordonne à chaque CVM d’arrêter ses services dans un ordre précis. Le service Stargate (qui gère les I/O de stockage) s’assure que tout est « flushé » sur disque avant de s’éteindre.

Vous allez voir des lignes défiler indiquant l’arrêt de Zeus, Scavenger, Cassandra, etc. Soyez patient. Selon la taille du cluster, cela peut prendre 2 à 5 minutes.

3.2 La vérification

Une fois l’opération terminée, vérifiez l’état réel des services :

cluster status

Ce que vous devez voir : Une liste de services pour chaque CVM. Ils doivent tous être en état DOWN, à l’exception potentielle du service Genesis qui peut rester UP , c’est normal.

Si vous voyez d’autres services encore UP, patientez une minute et relancez la vérification. Ne passez pas à la suite tant que le cluster n’est pas totalement à l’arrêt logique.

Phase 4 : Extinction des CVMs et des Nœuds physiques

Nous voici au bout du tunnel. Le cluster est arrêté logiciellement. Il ne reste plus que les coquilles vides : les CVMs (qui sont des VMs Linux, ne l’oublions pas) et les hyperviseurs.

4.1 Arrêt des CVMs

Il faut maintenant se connecter sur chaque CVM individuellement (via son IP, plus via la VIP) et lancer la commande d’extinction.

La commande officielle :

cvm_shutdown -P now

La commande cvm_shutdown contient des hooks spécifiques pour notifier l’hyperviseur. Répétez l’opération sur chaque nœud du cluster.

4.2 Arrêt des Hyperviseurs

Une fois les CVMs éteintes, connectez-vous à vos hôtes (en SSH ou via IPMI) et sur chacun d’entre eux tapez la commande suivante :

shutdown -h now

La Pépite Expert : Le Script d’Automatisation ⚡

Vous avez un cluster de 16 nœuds et la flemme de vous connecter 32 fois (16 CVM + 16 Hosts) ? Je vous comprends.

Voici un script à lancer depuis n’importe quelle CVM du cluster qui va éteindre toutes les CVMs, puis tous les hôtes AHV.

⚠️ AVERTISSEMENT : Ce script ne pose pas de questions. Assurez-vous d’avoir validé la Phase 3 (cluster stop) avant de lancer ça, sinon c’est le crash assuré.

Le script « Kill Switch » (Pour AHV)

Depuis une CVM, ce script récupère les IPs des autres CVMs et des hôtes, puis envoie l’ordre d’extinction en séquence.

for svmip in `svmips`; do ssh -q nutanix@$svmip "sudo /usr/sbin/shutdown +1 ; hostname"; done
for hostip in `hostips`; do ssh -q root@$hostip "/usr/sbin/shutdown +3 ; hostname"; done
  • La première commande ordonne l’extinction des CVMs après un délai d’une minute.
  • La seconde commande ordonne l’extinction des noeuds après un délai de 3 minutes.

Une fois que vous aurez lancé les commandes, vous perdrez la connexion au bout d’une minute. Vous pouvez alors suivre l’extinction de vos noeuds depuis leurs interfaces IPMI respectives.

Phase 5 : Le Rallumage (Cold Boot)

La période de maintenance est terminée. On fait quoi ? On appuie sur ON et on prie ? Non, on respecte l’ordre inverse.

  1. Réseau Physique : Allumez vos switchs Top-of-Rack en premier. Si le réseau n’est pas là, les nœuds ne se verront pas au démarrage.
  2. IPMI / Physique : Allumez les nœuds physiques.
  3. Patience : AHV va booter, puis démarrer automatiquement la CVM.
    • Astuce : Ne touchez à rien pendant 10 minutes. Laissez les CVMs former le cluster.
  4. Démarrage du Cluster : Connectez-vous en SSH sur une CVM. Vérifiez que toutes les CVMs sont up (svmips doit toutes les lister). Puis :cluster start
  5. Vérifier que le cluster est bien démarré avec la commande :cluster status
  6. Démarrage des Workloads : Une fois le cluster UP, rallumez d’abord la PCVM puis vos VMs (Infra d’abord, Appli ensuite).

Conclusion

L’arrêt d’un cluster Nutanix est une procédure simple mais qui nécessite un bon séquençage. Ce n’est pas compliqué, mais ça ne pardonne pas l’impatience. Si vous suivez ces étapes, vous dormirez tranquille pendant la coupure électrique.

Read More

Supervision Nutanix avec Centreon : Passer d’une vue « Cluster » à une visibilité par Nœud

Published: 5 février 2026
Written by Julien D.
No comments
Categories: Nutanix, Nutanix AHV FR, Supervision
nutanix centreon supervision snmp

On a tous connu ce moment de solitude. Celui où ton dashboard de supervision affiche un magnifique cercle vert pour ton cluster Nutanix, alors qu’en réalité, un des noeuds du cluster est en souffrance. C’est exactement ce qui m’est arrivé récemment.

Quand j’ai intégré Nutanix dans mon infrastructure, mon premier réflexe a été de dégainer Centreon. Pourquoi ? Parce que c’est mon couteau suisse de la supervision. Mais j’ai vite réalisé que la méthode « standard » d’ajout d’un cluster nous enferme dans une illusion de sécurité. On voit le « tout », mais on ignore le « détail ».

Dans ce retex, je vais vous partager mon expérience sur la supervision Nutanix Centreon et vous expliquer pourquoi vous devriez arrêter de monitorer uniquement votre cluster par son IP virtuelle (VIP) pour passer à une stratégie de supervision granulaire par nœud.

Pourquoi la configuration « par défaut » m’a laissé sur ma faim

Lorsqu’on installe le Plugin Pack Nutanix sur Centreon, la documentation nous guide naturellement vers l’ajout d’un hôte unique représentant le cluster.

Le fonctionnement du Plugin Pack Nutanix standard

La méthode classique consiste à interroger l’IP virtuelle (VIP) du cluster ou l’IP d’une des CVM (Controller VM). C’est simple, c’est rapide : on renseigne la communauté SNMP, on applique le template, et hop, les services remontent. On surveille alors l’usage global du CPU, la latence moyenne du stockage et l’état général déclaré par Prism.

Le problème de la « boîte noire »

C’est là que le bât blesse. En interrogeant uniquement la VIP, on interroge en réalité un agent SNMP qui agrège les données. Si vous avez un cluster de 3 nœuds, la supervision va vous dire que la mémoire à l’échelle du cluster est « OK ». Mais qu’en est-il de la charge mémoire du nœud n°3 ?

C’est ce que j’appelle l’effet « boîte noire ». L’architecture Shared Nothing de Nutanix est une force pour la résilience, mais elle peut devenir un angle mort pour la supervision si on ne descend pas au niveau de la couche physique. Pour un expert, savoir que le cluster est « Up » est insuffisant ; on a besoin de savoir quel composant physique précis nécessite une intervention avant que la redondance ne soit plus assurée.

Découpler la supervision pour une visibilité granulaire

Pour sortir de cette impasse, j’ai changé d’approche : traiter chaque nœud comme une entité propre dans Centreon. Voici comment j’ai procédé.

Étape 1 : Préparer le terrain sur Prism Element

Avant de toucher à Centreon, il faut s’assurer que Nutanix est prêt à causer. Direction Prism Element, dans les paramètres SNMP. Ici, j’ai configuré les accès SNMP v2c (ou v3 si vous voulez blinder la sécurité).

Consultez mes articles dédiés, si vous voulez des précisions sur la méthode de configuration du SNMP v2c ou du SNMP v3 sur votre cluster Nutanix.

Étape 2 : La stratégie d’ajout « Nœud par Nœud » dans Centreon

C’est ici que la magie opère. Au lieu de créer un seul hôte « Cluster-Nutanix », j’ai créé autant d’hôtes que j’ai de nœuds physiques (ex: cluster-2170_n1, cluster-2170_n2, etc.).

Configuration de l’Hôte : Chaque hôte pointe vers l’adresse IP de la VIP du cluster ou de la CVM du noeud concerné. De base, cela remontera les mêmes informations globales, mais attendez la suite.

Application des Templates : J’applique le template Virt-Nutanix-Hypervisor-Snmp-Custom.

Filtrage chirurgical : C’est ici que réside le secret. Dans les “Host check options”, j’applique la macro personnalisée FILTERNAME. Elle permet d’indiquer précisément le nom de l’hôte à superviser. Le plugin fait alors le tri dans les données SNMP envoyées par la VIP pour ne remonter que ce qui concerne mon nœud spécifique.

Étape 3 : L’astuce pour garder la cohérence du Cluster

Pour garder une vue d’ensemble, j’utilise les Host Groups dans Centreon. J’ai créé un groupe HG-Cluster-Nutanix-Prod regroupant mes 3 nœuds. Cela me permet de créer des dashboards agrégés tout en conservant la capacité de « drill-down » (cliquer pour voir le détail) sur chaque machine physique.

Les bénéfices immédiats : Dashboarding et Sérénité

Depuis que j’ai basculé sur cette configuration, mon quotidien de sysadmin a radicalement changé :

Analyse de performance granulaire : Je peux désormais identifier un nœud qui consomme anormalement plus de RAM ou de CPU que ses voisins. C’est l’outil idéal pour détecter un « hot point » ou un problème de distribution des VMs.

Réactivité accrue : Lorsqu’un problème survient, Centreon m’envoie une alerte avec le nom précis du nœud (n1, n2, etc.). Plus besoin de jouer aux devinettes dans Prism Element pour savoir où je dois accentuer mes recherches.

Historisation propre : J’ai des graphiques de métriques par serveur physique, ce qui facilite grandement le Capacity Planning ou le troubleshooting.+

Conclusion

Si vous gérez du Nutanix, ne vous contentez pas de la vue superficielle offerte par l’IP VIP seule. En prenant 10 minutes pour déclarer vos hôtes individuellement dans Centreon avec la macro FILTERNAME, vous passez d’une supervision « passive » à une véritable tour de contrôle.

Mon verdict est sans appel : la supervision par nœud est la seule façon de garantir une haute disponibilité réelle et de dormir sur vos deux oreilles.

Read More