Team Leader - Nutanix Technology Champion - Nutanix NTC Storyteller

Julien DUMUR
Infrastructure in a Nutshell

ahv

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.

Appel curl à l'API v2 du cluster depuis WSL

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

Variables d'environnement Postman du cluster

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

Import du Swagger Nutanix dans Postman

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 !

Collection Postman générée depuis le Swagger

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 !

Réponse JSON du cluster dans Postman

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.

Ajout d'un GPU Tesla P4 en Passthrough sur la VM

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.

Résultat de nvidia-smi avec la Tesla P4

💡 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.
2 Comments
Categories: Nutanix, Nutanix AHV FR
L'hyperconvergence, la fin de l'ère monolithique

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.

Encombrement d'une architecture classique face à l'hyperconvergence

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.

Vue en coupe d'un nœud HCI avec la CVM et le PCI Passthrough

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.

Scale-out par empilement de nœuds

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.

Reconstruction RAID classique face au rebuild distribué HCI

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
Éteindre proprement un cluster Nutanix AHV

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

Tableau de bord Prism Element d'un cluster de 3 nœuds

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 ?

Services Centreon du cluster avec une VM en critique

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

Configuration SNMP v2c dans Prism Element

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.

Macros SNMPEXTRAOPTIONS et FILTERNAME d'un hôte nœud

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

Tableau de bord Centreon du cluster CLUSTER-2170

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.

Services supervisés par nœud dans Centreon

Graphique d'utilisation CPU par nœud dans Centreon

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

Architecture 3-Tiers : Anatomie, forces et limites du standard historique de la virtualisation

Published: 3 février 2026
Written by Julien D.
No comments
Categories: Nutanix, Nutanix AHV FR
Architecture de virtualisation 3-tiers

Je me souviens encore de ma première entrée dans une salle serveur « sérieuse » au milieu des années 2000. Ce qui m’a frappé, ce n’était pas tant le bruit assourdissant de la climatisation, mais la densité physique de l’infrastructure.

À cette époque, pour faire tourner quelques centaines de machines virtuelles, il ne fallait pas juste « un cluster ». Il fallait des rangées entières. Des serveurs lames gourmands en énergie, des switchs Fibre Channel monstrueux avec leurs câbles oranges caractéristiques, et surtout, trônant au centre de la pièce comme un totem sacré : la Baie de Stockage. Des armoires entières remplies de disques mécaniques 10k tours/minute, pesant le poids d’une petite voiture et consommant autant de ‘U’ (unités de rack) que possible.

C’est ce qu’on appelle l’architecture 3-Tiers. Si aujourd’hui l’Hyperconvergence (HCI) et le Cloud public semblent être la norme, il est crucial de comprendre que le 3-Tiers a été la colonne vertébrale de l’informatique d’entreprise pendant près de 20 ans. Comprendre cette architecture, c’est comprendre d’où l’on vient, et pourquoi nous avons cherché à en changer.

Dans cet article, le premier d’une série qui va présenter l’évolution des infrastructures de virtualisation 3-tiers vers les infrastructures hyperconvergées Nutanix, nous allons disséquer factuellement ce standard : son fonctionnement, pourquoi il a dominé le marché, et les limites techniques qui ont fini par le rendre obsolète pour les workloads modernes.

Genèse : Pourquoi avons-nous construit ainsi ?

Pour comprendre le 3-Tiers, il faut revenir à l’ère pré-virtualisation. Un serveur physique hébergeait une seule application (Windows + SQL, par exemple). C’était le modèle « Silo ». Inefficace, coûteux, et cauchemardesque à gérer.

La virtualisation (VMware en tête) est arrivée avec une promesse : consolider plusieurs serveurs virtuels sur un seul serveur physique. Mais pour que cette magie opère, il y avait une condition technique absolue : la mobilité.

Pour qu’une VM puisse passer d’un serveur physique A à un serveur physique B sans interruption de service (le fameux vMotion), les deux serveurs devaient voir exactement les mêmes données, au même moment.

C’est là que l’architecture s’est scindée en trois couches distinctes :

  1. On a retiré les disques des serveurs (qui ne font plus que du calcul).
  2. On a centralisé toutes les données dans un stockage partagé externe (la Baie).
  3. On a relié le tout par un réseau dédié ultra-rapide (le SAN).

C’était une révolution : le serveur devenait « jetable » ou du moins interchangeable, car il ne possédait plus la donnée. Mais cette centralisation a créé un point unique de complexité et de performance : le stockage partagé. C’est le cœur du réacteur, mais aussi son talon d’Achille.

L’Anatomie du 3-Tiers : Décorticage des couches

Si l’on devait dessiner cette architecture, elle ressemblerait à un gâteau à trois étages, où chaque étage parle une langue différente.

Infographie de l'anatomie d'une architecture 3-tiers

1. La couche Compute (Calcul)

Tout en haut, nous avons les serveurs physiques (Hosts). Ils exécutent l’hyperviseur (ESXi, Hyper-V, KVM). Leur rôle est purement mathématique : fournir du CPU et de la RAM aux machines virtuelles.

Ces serveurs sont « Stateless ». Ils ne stockent rien de persistant. Si un serveur brûle, ce n’est pas grave : on redémarre les VMs sur le voisin (HA).

Cette logique a été poussée à l’extrême avec le « Boot from SAN ». On a même fini par retirer les petits disques locaux (SD cards ou SATA DOM) qui contenaient l’OS de l’hyperviseur pour que le serveur soit une coquille vide totale, chargeant son propre système d’exploitation depuis la baie de stockage distante. Une prouesse technique, mais un cauchemar en cas de perte de connectivité SAN.

2. La couche Network (SAN)

Au milieu se trouve le réseau de stockage (Storage Area Network). C’est l’autoroute qui transporte les données entre les serveurs et la baie. Historiquement, cela ne passait pas par le réseau Ethernet classique (trop instable à l’époque), mais par un protocole dédié : le Fibre Channel (FC).

C’est un réseau déterministe et sans perte. Contrairement à l’Ethernet qui fait du « best effort », le FC garantit que les paquets arrivent dans l’ordre.

Si vous avez administré du SAN, vous connaissez la douleur du Zoning. Il fallait configurer manuellement sur les switchs quel port (WWN) avait le droit de parler à quel autre port. Une erreur d’un chiffre dans une adresse hexadécimale de 16 caractères, et votre cluster de production s’arrêtait net. C’était une tâche si complexe qu’elle nécessitait souvent une équipe dédiée (« L’équipe SAN »).

3. La couche Storage (Stockage)

Tout en bas, la Baie de Stockage (Storage Array). C’est un ordinateur géant spécialisé dans l’écriture et la lecture de blocs de données. Elle contient des contrôleurs (les cerveaux) et des tiroirs de disques (la capacité).

La baie agrège des dizaines voire des centaines de disques physiques pour créer de gros volumes virtuels (LUNs) qu’elle présente aux serveurs. Elle assure la protection des données via du RAID matériel.

Toute l’intelligence réside dans deux contrôleurs (souvent en mode Actif/Passif ou Actif/Actif asymétrique). C’est un goulot d’étranglement architectural : peu importe que vous ayez 500 disques SSD ultra-rapides derrière, si vos deux contrôleurs saturent en CPU ou en cache, toute l’infrastructure ralentit. C’est ce qu’on appelle le « Front-end bottleneck ».

Les Forces : Pourquoi ce modèle a dominé le monde

Il est facile de critiquer le 3-Tiers avec nos yeux de 2024, mais il faut reconnaître qu’il a apporté une stabilité incroyable.

  1. Robustesse et Maturité : C’est du matériel conçu pour ne jamais faillir. Les baies de stockage ont des composants redondants partout (alimentations, ventilateurs, contrôleurs, chemins d’accès). On parle de « Five Nines » (99,999% de disponibilité).
  2. Isolation des fautes : Si un serveur plante, le stockage continue de vivre. Si un disque casse, le RAID matériel le reconstruit sans que le serveur ne s’en aperçoive (ou presque).
  3. Indépendance du Scale-Up : C’était l’argument roi. Vous manquez de place mais vos CPU dorment ? Vous achetez juste un tiroir de disques supplémentaire. Vous manquez de puissance mais avez plein de place ? Vous rajoutez un serveur. On pouvait dimensionner chaque étage indépendamment.
Infographie des forces de l'architecture 3-tiers

Les Faiblesses : Le revers de la médaille

Malgré sa robustesse, le modèle 3-Tiers a commencé à montrer de sérieux signes de fatigue face à la virtualisation moderne. Pour nous, administrateurs, cela s’est traduit par des nuits écourtées et quelques cheveux blancs prématurés.

Infographie des faiblesses de l'architecture 3-tiers

La complexité opérationnelle

Le plus grand ennemi du 3-tiers n’est pas la panne, c’est la mise à jour. Imaginez devoir mettre à jour la version de votre hyperviseur (ESXi). Vous ne pouvez pas simplement cliquer sur « Update ». Vous devez consulter la HCL (Hardware Compatibility List). Est-ce que le nouveau driver de ma carte HBA est compatible avec le firmware de mon switch Fibre Channel, lui-même compatible avec la version de l’OS de ma baie de stockage ? C’est un château de cartes. J’ai vu des infrastructures entières devenir instables simplement parce qu’un firmware de carte réseau avait 3 mois de retard sur celui préconisé par le constructeur de la baie.

Le goulot d’étranglement

C’est un phénomène fascinant et destructeur. Imaginez 50 VMs sur un hôte.

  • La VM 1 écrit un gros fichier séquentiel.
  • La VM 2 fait une lecture de base de données.
  • La VM 3 boot.

Au niveau de la VM, les opérations sont propres. Mais quand toutes ces opérations arrivent en même temps dans l’entonnoir du contrôleur de stockage, elles sont mélangées. Ce qui était une belle écriture séquentielle devient une bouillie d’écritures aléatoires (Random I/O). Les contrôleurs de baies traditionnelles, conçus à l’origine pour des serveurs physiques uniques, s’effondrent souvent sous ce type de charge, créant une latence perceptible par l’utilisateur final.

Le coût caché

Enfin, le 3-Tiers coûte cher. Très cher.

  • Licences & Support : Vous payez le support du serveur, le support des switchs SAN, et le support de la baie (souvent indexé au volume de données !).
  • Empreinte au sol : Comme évoqué en introduction, ces équipements consomment énormément d’espace et d’électricité.
  • Expertise humaine : Il faut souvent une équipe pour le compute, une équipe pour le réseau, et une équipe pour le stockage. Les temps de résolution d’incidents explosent (« C’est pas le réseau, c’est le stockage ! » – « Non, c’est l’hyperviseur ! », vous voyez ce que je veux dire j’en suis certain…).
Dessin des équipes compute, réseau et stockage qui se renvoient la faute

Conclusion : Une fondation nécessaire

L’architecture 3-Tiers n’est pas morte. Elle reste pertinente pour des besoins très spécifiques, comme des bases de données monolithiques massives qui nécessitent des garanties de performance physique dédiées.

Cependant, sa complexité de gestion et son incapacité à évoluer linéairement ont pavé la voie à une nouvelle approche. Nous avons commencé à nous poser la question interdite : « Et si, au lieu de spécialiser le matériel, on utilisait des serveurs standards et qu’on gérait tout par logiciel ? »

C’est cette réflexion qui a donné naissance au Software-Defined Storage (SDS) et à l’Hyperconvergence (HCI). Mais ça, c’est un sujet pour notre prochain article.

Read More

Nutanix Technology Champion (NTC) 2026 : Une 3ème étoile sur le maillot !

Published: 18 décembre 2025
Written by Julien D.
No comments
Categories: Lifestyle
Nutanix Technology Champion 2026

On pourrait croire qu’avec le temps, on s’habitue. Qu’après deux ans, l’ouverture de l’email annonçant les résultats devient une simple formalité administrative. Eh bien, je vous le confesse : pas du tout.

C’est avec une immense fierté – et un soulagement non dissimulé – que je vous annonce ma nomination en tant que Nutanix Technology Champion (NTC) pour l’année 2026. C’est la troisième année consécutive que j’ai l’honneur de rejoindre ce groupe d’experts passionnés.

Annonce officielle des Nutanix Technology Champions 2026

Pour être tout à fait transparent, je ne prends jamais cette distinction pour acquise. Dans le monde de l’IT, les technologies évoluent vite, et nous aussi. Rester pertinent demande du travail, de la curiosité et surtout, l’envie de partager. Voir son nom figurer à nouveau sur la liste officielle des NTC 2026 est donc une belle validation des efforts fournis sur le blog tout au long de l’année.

C’est quoi un « NTC » ? (Spoiler : Ce n’est pas juste un badge LinkedIn)

Souvent, on me demande si c’est un examen que j’ai passé, comme une certification NCP-MCI. La réponse est non, et c’est justement ce qui fait la beauté de ce programme.

Le programme Nutanix Technology Champion ne récompense pas uniquement la réussite à un QCM technique. C’est une distinction qui reconnaît l’engagement communautaire. En gros, Nutanix repère ceux qui passent leur temps libre à tester, casser, réparer et surtout expliquer leurs technologies aux autres. Que ce soit via des articles de blog (comme ici), des interventions sur les forums, ou des talks lors d’événements.

Pour les puristes, c’est l’équivalent du vExpert chez VMware ou du MVP chez Microsoft. C’est la validation de ce qu’on appelle les « Soft Skills » techniques : la capacité à évangéliser une solution non pas parce qu’on est payé pour le faire, mais parce qu’on en maîtrise les arcanes et qu’on aime ça. C’est une reconnaissance par les pairs et par l’éditeur, et c’est ce qui rend la chose si gratifiante.

Sous le capot : Pourquoi cette nomination est importante pour le blog

Au-delà du logo brillant à mettre en signature, être NTC a un impact direct sur la qualité de ce que je peux vous proposer sur juliendumur.fr. Ce n’est pas un titre honorifique vide de sens, c’est une clé qui ouvre des portes intéressantes.

Concrètement, ce statut me donne un accès privilégié aux coulisses. J’ai l’opportunité d’échanger directement avec les Product Managers et les équipes d’ingénierie de Nutanix. Cela signifie que lorsque je rédige un article technique, je peux valider mes hypothèses à la source, évitant ainsi les approximations.

De plus, nous avons accès à des briefings sur la roadmap et aux versions Bêtas. Même si ces informations sont souvent sous NDA (je ne peux pas tout vous révéler à l’avance !), cela me permet de comprendre la direction que prend la technologie. Je peux ainsi mieux anticiper les sujets à traiter et vous proposer des analyses plus pertinentes dès que les fonctionnalités passent en General Availability (GA). C’est l’assurance pour vous de lire du contenu qui est non seulement techniquement juste, mais aussi en phase avec la réalité du marché.

Rétrospective et Objectifs 2026 : On ne lâche rien

Cette troisième nomination est le fruit de la régularité. Mais elle marque surtout le début d’une nouvelle année de « lab ». Le but n’est pas de collectionner les étoiles, mais de continuer à explorer la Nutanix Cloud Platform sous toutes ses coutures.

Pour 2026, je compte bien continuer à vous proposer des tutoriels pratiques et des retours d’expérience. Si l’hyperviseur AHV reste le socle incontournable, j’ai très envie de monter un peu plus dans les couches logicielles cette année. Attendez-vous à voir passer des sujets autour de l’orchestration de conteneurs avec NKP (Nutanix Kubernetes Platform), de l’automatisation, et probablement un focus plus appuyé sur la sécurité avec Flow. L’objectif reste le même : décortiquer la techno pour la rendre accessible.

Un immense merci à la communauté pour les échanges quotidiens, et bien sûr à l’équipe du programme NTC (clin d’œil à Angelo Luciani) pour leur confiance renouvelée. C’est un plaisir de faire partie de cette famille virtuelle.

Maintenant, la balle est aussi dans votre camp : y a-t-il des sujets spécifiques ou des fonctionnalités de l’écosystème Nutanix que vous aimeriez me voir traiter cette année ? Les commentaires sont ouverts !

Read More

Nutanix AOS 7.5, AHV 11.0 et PC 7.5 : Décryptage de cette mise à jour massive

Published: 10 décembre 2025
Written by Julien D.
1 Comment
Categories: Nutanix, Nutanix AHV FR
Nutanix AOS 7.5, AHV 11.0 et Prism Central 7.5

C’est le genre de matinée où le café a un goût particulier. Celui des grandes annonces qui vont, à coup sûr, changer nos habitudes d’administrateurs. Nutanix vient de lâcher dans la nature un trio de mises à jour majeures : AOS 7.5, AHV 11.0 et Prism Central 7.5.

Soyons clairs d’entrée de jeu : j’ai épluché les Release Notes pour vous, et ce n’est pas un simple « patch Tuesday ». C’est une refonte structurelle.

Si sur le papier, les promesses de performances (AES partout) et de flexibilité (Elastic Storage) sont alléchantes, mon expérience de terrain me dicte une certaine prudence. Quand on touche au moteur de stockage et aux accès SSH en même temps, on ne se précipite pas en production sans une lecture attentive des petites lignes. C’est exactement ce que je vous propose ici : une analyse technique, sans filtre, de ce qui vous attend.

AOS 7.5 : Performance & Architecture

Commençons par le cœur du réacteur : AOS 7.5. Si vous pensiez que l’architecture de stockage Nutanix était gravée dans le marbre, détrompez-vous. Cette version marque un tournant dans la gestion de la donnée chaude et de l’espace disque.

Le concept clé : L’AES devient le standard absolu

Jusqu’à présent, l’Autonomous Extent Store (AES) était souvent réservé aux environnements All-Flash performants. Avec la 7.5, c’est fini : l’AES devient l’architecture par défaut pour tous les déploiements, qu’ils soient All-Flash ou Hybrides.

Pourquoi c’est important ? Parce que l’AES améliore la localité des métadonnées et réduit la consommation CPU pour les I/O. Mais attention, la nouveauté critique ici, c’est la migration automatique. Si vous mettez à jour un cluster hybride existant vers la 7.5, AOS va lancer une conversion en tâche de fond pour basculer vers AES.

Ne sous-estimez pas l’impact I/O de cette conversion « transparente ». Même si Nutanix gère ça en background, une restructuration des métadonnées n’est jamais anodine sur un cluster chargé. De plus, Nutanix introduit un Garbage Collection (GC) remanié (« Accelerated Data Reclamation »). Il est désormais capable de nettoyer plusieurs « trous » dans une stripe d’Erasure Coding en une seule passe et de fusionner les stripes inefficaces. C’est brillant pour l’efficacité, mais cela confirme que le moteur travaille beaucoup plus « intelligemment » sous le capot.

L’ouverture inattendue : Pure Storage et Nœuds Denses

C’est peut-être le signe le plus fort de cette release : Nutanix s’ouvre officiellement au stockage tiers. AOS 7.5 supporte la connexion à des baies Pure Storage FlashArray via NVMeoF/TCP pour le stockage de capacité. Nutanix gère le compute, Pure gère la donnée. Pour les puristes du HCI comme moi, c’est un changement de paradigme, mais qui répond à un vrai besoin de désagrégation.

Enfin, pour ceux qui gèrent des monstres de stockage, notez que les nœuds All-Flash existants peuvent être mis à jour pour supporter jusqu’à 185 TB par nœud, tout en conservant les RPO agressifs (NearSync/Sync).

AHV 11.0 & Flexibilité : L’ère du « Compute-Only » et du Stockage Élastique

Si AOS 7.5 booste le moteur, AHV 11.0 change la carrosserie. Pendant longtemps, Nutanix a prêché le dogme de l’hyperconvergence stricte : « On achète des nœuds identiques, on étend le stockage et le compute en même temps ». Avec cette version, j’ai l’impression que Nutanix écoute enfin ceux qui, comme moi, se sont retrouvés avec trop de CPU et pas assez de disque (ou l’inverse).

Le concept clé : La désagrégation officielle

C’est une petite révolution : Nutanix autorise désormais le déploiement de nœuds « Compute-Only » de manière beaucoup plus souple. On voit arriver un installateur AHV autonome. Concrètement, vous pouvez installer AHV manuellement via une ISO sur un serveur, sans passer par la lourdeur d’un re-imaging complet via Foundation.

Pour les labs ou les extensions rapides de puissance de calcul, c’est un gain de temps phénoménal. Mais attention, cela demande une rigueur accrue sur la gestion des compatibilités matérielles, car Foundation ne sera plus là pour faire le garde-fou à l’installation.

La fonctionnalité attendue : Elastic VM Storage

C’est sans doute la fonctionnalité que j’attendais le plus pour casser les silos. Avec Elastic VM Storage, disponible dès AHV 11.0 et AOS 7.5, on peut enfin partager un container de stockage d’un cluster AHV vers un autre cluster AHV au sein du même Prism Central.

Imaginez : votre Cluster A est plein à craquer niveau stockage, mais votre Cluster B dort à moitié vide. Avant, il fallait déplacer les VMs. Maintenant, vous pouvez monter le container du Cluster B sur le Cluster A et déployer vos VMs directement dessus.

C’est génial, mais prudence. Ce n’est pas magique. Vous introduisez une dépendance réseau critique entre deux clusters qui étaient auparavant isolés. Si votre réseau inter-cluster flanche, les VMs du Cluster A hébergées sur le Cluster B tombent. De plus, Nutanix précise bien que cela permet de « servir du stockage depuis un cluster distant », ce qui implique forcément une latence réseau additionnelle par rapport à la localité des données native. À réserver pour des workloads qui ne sont pas sensibles à la latence disque ou pour du débordement temporaire.

Enfin, notons l’arrivée du Dual Stack IPv6. AHV peut désormais discuter avec vos DNS, NTP et serveurs Syslog en IPv6. Une mise à jour nécessaire pour s’aligner sur les standards réseaux modernes.

Sécurité et Gouvernance : On verrouille tout (SSH, vTPM, Profils)

Passons à la partie qui va faire grincer des dents les habitués de la ligne de commande (dont je fais partie). Nutanix a décidé de serrer la vis sur la sécurité, et ils ne font pas semblant.

Le concept clé : La forteresse numérique

L’objectif est clair : réduire la surface d’attaque, notamment face aux ransomwares qui tentent souvent de se propager via des mouvements latéraux sur les interfaces de management. Nutanix introduit donc des mécanismes pour limiter l’accès humain direct aux composants d’infrastructure (CVM et Hôtes).

Le changement critique : CVM Secure Access (la fin du SSH approche)

C’est le point de vigilance numéro 1 de cet article. Avec AOS 7.5, vous avez désormais l’option (et la forte incitation) de désactiver totalement l’accès SSH aux CVMs et aux hôtes AHV.

Sur le papier, c’est excellent pour la sécurité (« Security by Obscurity »). Dans la réalité opérationnelle, c’est un changement culturel violent. Fini le petit ssh nutanix@cvm pour aller vérifier un log ou lancer un script de diagnostic rapide. Tout doit passer par les API ou la console.

Attention Danger ! Avant de cocher cette case « Disable SSH », vérifiez vos procédures de migration. Les Release Notes sont formelles : désactiver le SSH casse les workflows de Cross-Cluster Live Migration (CCLM), que ce soit en mode On-Demand (OD-CCLM) ou Disaster Recovery (DR-CCLM). Ces opérations s’appuient encore sur des tunnels SSH entre hôtes source et destination. Si vous coupez le SSH, vos migrations échoueront. Il faudra réactiver le SSH pour les faire fonctionner. C’est une contrainte opérationnelle majeure à anticiper.

Gouvernance : vTPM & Profils Invités

Pour les environnements très sensibles, AHV supporte maintenant le stockage des clés de chiffrement vTPM dans un KMS externe. Cela permet de centraliser la gestion des clés et d’aligner la politique de sécurité des vTPM sur celle du chiffrement « Data-at-Rest » du cluster.

Côté confort de vie, je salue l’arrivée des Guest Customization Profiles réutilisables. Fini le copier-coller fastidieux des scripts Sysprep à chaque clonage de VM. On crée un profil (Windows + NGT 4.5 min requis), on le stocke, et on l’applique à la volée sur les clones ou les templates. C’est simple, efficace, et ça évite les erreurs de saisie.

Prism Central 7.5 : L’interface qui facilite la vie (NIM & Politiques)

On termine ce tour d’horizon avec Prism Central 7.5 (pc.7.5). Si AOS est le moteur et AHV le châssis, PC est le tableau de bord. Et croyez-moi, il s’étoffe considérablement pour nous éviter des tâches manuelles ingrates.

Le concept clé : L’orchestration intelligente

L’ajout majeur, c’est l’arrivée des VM Startup Policies. C’est une fonctionnalité que j’attendais depuis des années pour remplacer mes scripts de démarrage bricolés. Concrètement, vous pouvez désormais définir l’ordre exact de redémarrage des VMs lors d’un événement HA (panne de nœud) ou d’un redémarrage de cluster.

Cela permet de gérer les dépendances applicatives proprement : « Démarrer la Base de Données, attendre qu’elle soit UP, puis démarrer le Serveur d’Application ». C’est natif, intégré à l’interface, et ça sécurise grandement les plans de reprise.

Pour les environnements à grande échelle, notez l’apparition de NIM (Nutanix Infrastructure Manager). C’est un nouvel orchestrateur conçu pour provisionner, configurer et gérer vos datacenters de manière standardisée, en s’alignant sur les fameux « Nutanix Validated Designs » (NVD). C’est clairement orienté pour les très gros déploiements qui veulent éviter la dérive de configuration.

La résilience renforcée : PC Backup & Restore

Jusqu’à présent, restaurer un Prism Central crashé pouvait être une aventure, surtout si le cluster d’origine était lui-même en vrac. Nutanix a levé une contrainte technique majeure : vous pouvez maintenant restaurer une instance Prism Central à partir d’une sauvegarde située sur n’importe quel cluster Prism Element.

C’est un détail qui change tout en cas de sinistre total d’un site. Auparavant, la restauration depuis un backup Prism Element était restreinte au cluster spécifique où PC était enregistré. Cette flexibilité nouvelle, couplée à la possibilité de backup vers un Object Store S3 générique, rend l’architecture de management beaucoup plus robuste.

Conclusion & Recommandations : La maturité a un prix

Après avoir décortiqué ces trois releases notes, mon sentiment est clair : Nutanix atteint un niveau de maturité impressionnant. La généralisation de l’AES et l’ouverture au stockage externe montrent que la plateforme est prête pour les workloads les plus exigeants et les architectures les plus complexes.

Cependant, en tant que « Ghost Writer Prudent », je dois lever un dernier drapeau rouge avant que vous ne cliquiez sur « Upgrade ».

⚠️ Attention aux pré-requis : Ne vous lancez pas tête baissée dans la mise à jour de Prism Central. La version pc.7.5 exige que vos clusters Prism Element tournent au minimum en AOS 7.0.1.9. Si vous êtes sur une version antérieure, le déploiement sera bloqué. Il va falloir planifier votre chemin de migration avec rigueur.

C’est une mise à jour incontournable pour les gains de performance et de sécurité, mais c’est aussi une mise à jour structurelle. La conversion AES, la désactivation potentielle du SSH et les nouvelles dépendances réseaux pour le stockage élastique imposent de valider ces changements en environnement de pré-production.

Prenez le temps de tester, vérifiez vos matrices de compatibilité, et surtout, ne coupez pas le SSH avant d’avoir vérifié que vous n’avez pas de migration inter-cluster (CCLM) planifiée !

À vos claviers, et bon upgrade !

Read More

Maxi Best Of Nutanix CLI : vérification des VMs

Published: 28 octobre 2025
Written by Julien D.
No comments
Categories: Nutanix, Nutanix AHV FR, Tutoriels, Tutoriels-AHV
nutanix ahv cli reference guide

Dans ce nouvel article, nous allons voir l’ensemble des principales commandes CLI de Nutanix AHV qui permettent de réaliser certaines vérifications sur vos machines virtuelles, en lignes de commandes.

L’ensemble des commandes de cet article sont à exécuter en SSH depuis n’importe quelle CVM du cluster.

Afficher la liste des machines virtuelles

Pour afficher la liste des machines virtuelles présentes sur le cluster Nutanix, il suffit de lancer la commande suivante :

acli vm.list

Cela vous affichera l’ensemble des VMs présentes sur le cluster, sans les CVMs :

nutanix@NTNX-S348084X9211699-B-CVM:192.168.84.22:~$ acli vm.list
VM name VM UUID
LINUX 88699c96-11a5-49ce-9d1d-ac6dfeff913d
NTNX-192-168-84-200-PCVM-1760699089 f659d248-9ece-4aa0-bb0c-22a3b3abbe12
vm_test 9439094a-7b6b-48ca-9821-a01310763886

Comme vous pouvez le constater, je n’ai que 2 machines virtuelles sur mon cluster :

  • mon Prism Central
  • une machine virtuelle « LINUX » fraichement déployée
  • une machine virtuelle de test

Une commande pratique pour récupérer rapidement l’intégralité des machines virtuelles et leurs UUID respectifs. Voyons maintenant comment récupérer des informations sur une machine virtuelle en particulier.

Récupérer les informations d’une machine virtuelle

Pour afficher les informations détaillées d’une machine virtuelle, il faut utiliser la commande suivante :

acli vm.get VM_NAME

En reprenant l’exemple de ma machine virtuelle « LINUX », cela renvoi les informations suivantes :

nutanix@NTNX-S348084X9211699-B-CVM:192.168.84.22:~$ acli vm.get LINUX
LINUX {
config {
agent_vm: False
allow_live_migrate: True
apc_config {
apc_enabled: False
}
bios_uuid: "88699c96-11a5-49ce-9d1d-ac6dfeff913d"
boot {
boot_device_order: "kCdrom"
boot_device_order: "kDisk"
boot_device_order: "kNetwork"
hardware_virtualization: False
secure_boot: False
uefi_boot: True
}
cpu_hotplug_enabled: True
cpu_passthrough: False
disable_branding: False
disk_list {
addr {
bus: "ide"
index: 0
}
cdrom: True
device_uuid: "fae2ee55-8736-4f3a-9b2c-7d5f5770bf33"
empty: True
iso_type: "kOther"
}
disk_list {
addr {
bus: "scsi"
index: 0
}
cdrom: False
container_id: 4
container_uuid: "2ead3997-e915-4ee2-b9a4-0334889e434b"
device_uuid: "f9a8a84c-6937-4d01-bfd2-080271c44916"
naa_id: "naa.6506b8def195dc769b32f3fe47100297"
storage_vdisk_uuid: "215ba83c-44cb-4c41-bddc-1aa3a44d41c7"[7] 0:python3.9* "ntnx-s348084x9211699-" 21:12 21-Oct-25 vmdisk_size: 42949672960
vmdisk_uuid: "42a18a62-861a-497a-9d73-e959513ce709"
}
generation_uuid: "9c018794-a71a-45ae-aeca-d61c5dd6d11a"
gpu_console: False
hwclock_timezone: "UTC"
machine_type: "pc"
memory_mb: 8192
memory_overcommit: False
name: "LINUX"
ngt_enable_script_exec: False
ngt_fail_on_script_failure: False
nic_list {
connected: True
mac_addr: "50:6b:8d:fb:a1:4c"
network_name: "NUTANIX"
network_type: "kNativeNetwork"
network_uuid: "7d13d75c-5078-414f-a46a-90e3edc42907"
queues: 1
rx_queue_size: 256
type: "kNormalNic"
uuid: "c6f02560-b8e6-4eed-bc09-1675855dfc77"
vlan_mode: "kAccess"
}
num_cores_per_vcpu: 1
num_threads_per_core: 1
num_vcpus: 2
num_vnuma_nodes: 0
power_state_mechanism: "kHard"
scsi_controller_enabled: True
vcpu_hard_pin: False
vga_console: True
vm_type: "kGuestVM"
vtpm_config { is_enabled: False
}
} is_ngt_ipless_reserved_sp_ready: True
is_rf1_vm: False
logical_timestamp: 1
state: "kOff"
uuid: "88699c96-11a5-49ce-9d1d-ac6dfeff913d"

Comme vous pouvez le constater, cela renvoi l’intégralité des informations d’une machine virtuelle. Il est possible de filtrer une partie des informations renvoyées avec certaines commandes. Voici celles que j’utilise le plus souvent :

acli vm.disk_get VM_NAME : pour récupérer les informations détaillées de l’ensemble des disques d’une machine virtuelle

nutanix@NTNX-S348084X9211699-B-CVM:192.168.84.22:~$ acli vm.disk_get LINUX
ide.0 {
addr {
bus: "ide"
index: 0
}
cdrom: True
device_uuid: fae2ee55-8736-4f3a-9b2c-7d5f5770bf33
empty: True
iso_type: "kOther"
}
scsi.0 {
addr {
bus: "scsi"
index: 0
}
cdrom: False
container_id: 4
container_uuid: "2ead3997-e915-4ee2-b9a4-0334889e434b"
device_uuid: f9a8a84c-6937-4d01-bfd2-080271c44916
naa_id: "naa.6506b8def195dc769b32f3fe47100297"
storage_vdisk_uuid: 215ba83c-44cb-4c41-bddc-1aa3a44d41c7
vmdisk_size: 42949672960
vmdisk_uuid: 42a18a62-861a-497a-9d73-e959513ce709
}

acli vm.nic_get VM_NAME : pour récupérer la liste détaillée des cartes réseaux attachées à une machine virtuelle

nutanix@NTNX-S348084X9211699-B-CVM:192.168.84.22:~$ acli vm.nic_get LINUX
50:6b:8d:fb:a1:4c {
connected: True
mac_addr: "50:6b:8d:fb:a1:4c"
network_name: "NUTANIX"
network_type: "kNativeNetwork"
network_uuid: "7d13d75c-5078-414f-a46a-90e3edc42907"
queues: 1
rx_queue_size: 256
type: "kNormalNic"
uuid: "c6f02560-b8e6-4eed-bc09-1675855dfc77"
vlan_mode: "kAccess"
}

acli vm.snapshot_list VM_NAME : pour récupérer la liste des snapshots associés à une machine virtuelle

nutanix@NTNX-S348084X9211699-B-CVM:192.168.84.22:~$ acli vm.snapshot_list LINUX
Snapshot name Snapshot UUID
SNAPSHOT_BEFORE_UPGRADE e7c1e84e-7087-42fd-9e9e-2b053f0d5714

Vous savez tout ou presque sur la vérification de vos machines virtuelles.

Pour la liste complète des commandes, je vous invite à consulter la documentation officielle : https://portal.nutanix.com/page/documents/details?targetId=Command-Ref-AOS-v7_3:man-ncli-c.html

Dans le prochain article, nous nous attaquerons à un gros morceau : la création de machines virtuelles via les commandes CLI.

Read More

Nutanix on OVHcloud : connexion de la passerelle Palo Alto au RTvRack

Published: 20 octobre 2025
Written by Julien D.
No comments
Categories: Nutanix, Nutanix NC2 FR
nutanix on ovhcloud hosted private cloud

Nous avons vu dans un précédent article comment déployer et réaliser la configuration de base d’une passerelle Palo Alto afin de remplacer la passerelle de base fournie avec votre cluster Nutanix OVHcloud.

Je vais maintenant vous présenter comment connecter cette passerelle au RTvRack fourni avec votre cluster afin de le connecter à internet.

Connexion de la passerelle au RTvRack

Dans « Network > Zones », on commence par créer une nouvelle zone de type « Layer3 » qu’on va appeler « WAN » pour plus de simplicité :

Création de la zone WAN de type Layer3

Vous pouvez également créer une ou plusieurs autres zones pour y rattacher vos autres interfaces (exemple : une zone « INTERNE »).

Ensuite, dans « Network > Interfaces », éditer l’interface ethernet1/1. Si vous avez correctement créé votre VM sur Nutanix, elle va correspondre à l’interface de sortie WAN. Ce sera une interface de type « Layer3 » :

Interface ethernet1/1 en Layer3 dans la zone WAN

Sur l’onglet « Config », sélectionner le Virtual Router « default » et sélectionner la zone de sécurité « WAN ».

Sur l’onglet « IPv4 », ajouter l’IP publique disponible dans le range qui vous a été fourni par OVHcloud avec votre cluster en veillant à bien mettre un masque en /32 à la fin :

Adresse IPv4 publique en /32 sur ethernet1/1

Vous pouvez retrouver l’information relative au réseau de votre adresse IP publique sur votre compte OVHcloud dans « Hosted Private Cloud > Network > IP » : https://www.ovh.com/manager/#/dedicated/ip

En fonction de l’adresse IP publique et de son masque de réseau associé vous pourrez déduire :

  • l’ip publique à attribuer à la patte WAN de votre passerelle
  • l’ip de la passerelle WAN

Exemple avec le réseau 6.54.32.10/30 :

Adresse de réseau (non utilisable) : 6.54.32.8
Première adresse (adresse publique de la PA-VM) : 6.54.32.9
Dernière adresse : 6.54.32.10 (adresse de la passerelle WAN)
Adresse de broadcast : 6.54.32.11 (adresse de broadcast)

Recommencer l’opération avec l’interface qui correspond au subnet de votre cluster Nutanix avec comme adresse IP celle de la passerelle que vous avez indiqué lors du déploiement de votre cluster.

Veillez par contre à mettre le masque correspondant à celui du réseau dans laquelle l’interface se trouve comme indiqué dans la documentation : https://docs.paloaltonetworks.com/pan-os/11-0/pan-os-networking-admin/configure-interfaces/layer-3-interfaces/configure-layer-3-interfaces#iddc65fa08-60b8-47b2-a695-2e546b4615e9.

Dans « Network > Virtual Routers », éditer le routeur par défaut. Vous devriez retrouver votre interface « ethernet1/1 » à minima, ainsi que les autres interfaces que vous auriez déjà configurées :

Virtual Router default avec ses interfaces

Ensuite, dans le sous menu « Static Routes », créer une nouvelle route avec un nom qui vous parle, une destination en 0.0.0.0/0, sélectionner l’interface « ethernet1/1 » et comme Next Hop l’adresse ip de la passerelle du réseau publique qui vous a été fourni par OVHcloud :

Route statique par défaut vers la passerelle OVHcloud

Enfin, aller dans l’onglet « Device > Setup > Services » et éditer l’option « Service Route Configuration » dans « Services Features » afin de spécifier l’interface de sortie et l’adresse ip en /32 associée pour certain des services :

Service Route Configuration de la PA-VM

La liste des services à configurer à minima est la suivante :

  • DNS
  • External Dynamic Lists
  • NTP
  • Palo Alto Networks Services
  • URL Updates

Vous pouvez valider et faire un commit. Votre passerelle PA-VM communique maintenant avec le RTvRack OVHcloud, il ne vous reste plus qu’à finaliser les configurations pour sécuriser l’installation et créer vos règles de pare-feu pour permettre à votre cluster d’accéder à internet.

Read More