Team Leader - Nutanix Technology Champion - Nutanix NTC Storyteller

Julien DUMUR
Infrastructure in a Nutshell

AHV

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: AHV, Nutanix, 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

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: AHV, Nutanix

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.

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.

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.

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

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

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: AHV, Guides-fr, Nutanix, 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: AHV, Nutanix, Tutoriels, Tutoriels-AHV
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 remplacement la passerelle de base fourni 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é :

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

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 :

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

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 :

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 :

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

Nutanix sur OVHcloud : redéployer son cluster

Published: 11 septembre 2025
Written by Julien D.
1 Comment
Categories: AHV, Guides-fr, Nutanix
nutanix on ovhcloud hosted private cloud

Dans cet article, je vous partage mon retour d’expérience complet sur la réinstallation complète d’un cluster Nutanix chez OVHcloud.

Une fois connecté à l’interface de gestion OVHcloud, se rendre dans « Hosted Private Cloud » : 

Dans le menu déroulant de gauche, cliquez sur le cluster que vous souhaitez redéployer :

Sur la page qui s’affiche, cliquez sur « Redéployer mon cluster » : 

Cliquez sur « Continuer » :

Redéploiement automatique

La première option consiste à reprendre les paramètres par défaut fournis par OVHcloud pour réinstaller complètement le cluster dans sa configuration de base :

Un récapitulatif des paramètres s’affiche avant que vous ne validiez pour de bon la réinstallation de votre cluster :

Redéploiement personnalisé

Il est possible de personnaliser entièrement la configuration du réseau IP de votre cluster lors de sa phase d’installation. Lors du choix de la méthode de déploiement du cluster, sélectionnez « Personnaliser la configuration » et cliquez sur « Suivant » : 

Renseignez les différents champs avec les informations que vous souhaitez attribuer à votre cluster et cliquez sur « Redéployer » : 

Saisissez « REDEPLOY » dans le champ prévu à cet effet et cliquez sur « Confirmer » pour lancer la procédure de réinstallation : 

Sur la page générale de votre cluster, un message indique que le redéploiement du cluster est en cours : 

Il ne reste plus qu’à patienter jusqu’à ce que le cluster soit complètement redéployé. L’ensemble des configurations de base sont déjà réalisées, il ne vous reste plus qu’à finaliser les spécifiques tels que l’authentification, le relais smtp, la supervision…

Read More

Maxi Best Of Nutanix CLI : les containers de stockage

Published: 4 septembre 2025
Written by Julien D.
No comments
Categories: AHV, Guides-fr, Nutanix, Tutoriels, Tutoriels-AHV
nutanix ahv cli reference guide

Dans la série Maxi Best Of Nutanix CLI, les 2 précédents articles traitaient de la vérification de la configuration du réseau d’un cluster Nutanix et de la gestion des subnets.

Dans ce nouvel article, nous allons aborder la gestion des containers de stockage via les commandes CLI sur vos clusters Nutanix…

L’ensemble des commandes présentes dans cet article sont à exécuter depuis une des CVMs du cluster et fonctionnent sur un cluster en AOS 6.10+.

Vérifier l’état des containers

Pour vérifier l’état de vos containers de stockage, la commande la plus simple est la suivante :

ncli container list

Cette commande vous permettra d’afficher l’ensemble des informations relatives à tous les containers de votre cluster.

Si vous souhaitez afficher un container en particulier, vous pouvez passer le nom (méthode la plus simple) ou l’ID de votre container si vous l’avez en paramètre :

ncli container list name=NAME
ncli container list id=ID

Enfin, une dernière commande pour n’afficher que les statistiques d’utilisation de vos containers :

ncli container list-stats

Renommer un container

Pour renommer un container de stockage, il est impératif qu’il soit totalement vide.

Le renommage d’un container de stockage peut être effectué grâce à la commande suivante :

ncli container edit name=ACTUALNAME new-name=NEWNAME

Sur le container par défaut, cela donnerai par exemple la commande suivante : 

ncli container edit name=default-container-21425105524428 new-name=ntnx-lab-container

ATTENTION : il existe 2 containers créés par défaut lors du déploiement votre cluster, « SelfServiceContainer » et « NutanixManagementShare ». Il ne faut pas tenter de les renommer !

Créer un container

Il est également possible de créer des containers de stockage en CLI :

ncli container create name=NAME sp-name=STORAGE-POOL-NAME

Le paramètre « name » et le « sp-name » sont les seuls paramètres obligatoires lors de l’exécution de la commande. Cela vous permettra de créer un container de base sur le storage pool choisi avec les paramètres suivants :

  • pas de mécanisme d’optimisation de la donnée
  • pas de restriction / réservation
  • le replication factor par défaut

Mais la commande de création d’un container peut s’avérer très pratique si vous devez créer des containers de stockage par lot, par exemple si vous hébergez plusieurs clients sur un cluster avec chacun une quantité d’espace de stockage allouée !

Par exemple, pour créer un container de stockage avec comme paramètres :

  • nom de container « client-alpha »
  • capacité réservée de 64Gb
  • capacité maximale de 64Gb
  • avec la compression en temps réel activée

Voici la commande qu’il faudrait passer :

ncli container create name=client-alpha res-capacity=64 adv-capacity=64 enable-compression=true compression-delay=0 sp-name=default-storage-pool-21425105524428

Un container avec les caractéristiques associées sera alors créé :

Modifier les paramètres d’un container

Un container existant peut également être modifié. Vous pouvez a peu prêt tout modifier au niveau des paramètres, des mécanismes d’optimisation de la donnée, aux tailles réservées / allouées, réplication factor…

Pour l’ensemble des paramètres, je vous invite à consulter la documentation officielle (lien en bas de page).

Supprimer un container

Supprimer un container est assez simple mais nécessite que l’ensemble des fichiers stockés dessus soient au préalable supprimés ou déplacés. La suppression se fait via la commande suivante :

ncli container remove name=NAME

Il peut arriver que malgré la suppression ou le déplacement des vdisks de vos VMs, la suppression vous soit toujours refusée. C’est souvent dû à de petits fichiers résiduels.

Il faut alors ajoute le paramètre « ignore-small-files » pour forcer la suppression :

ncli container remove name=NAME ignore-small-files=true

Cela donnerai par exemple :

ncli container remove name=lab-container ignore-small-files=true

ATTENTION : il existe 2 containers créés par défaut lors du déploiement votre cluster, « SelfServiceContainer » et « NutanixManagementShare ». Il ne faut pas tenter de les supprimer !

Documentation officielle

Pour en savoir plus sur certaines options des commandes présentées, je vous invite à consulter la documentation officielle : https://portal.nutanix.com/page/documents/details?targetId=Command-Ref-AOS-v6_10:acl-ncli-container-auto-r.html

Read More

Maxi Best Of Nutanix CLI : gestion des subnets

Published: 12 août 2025
Written by Julien D.
2 Comments
Categories: AHV, Guides-fr, Nutanix, Tutoriels, Tutoriels-AHV
nutanix ahv cli reference guide

Dans le précédent article du menu Maxi Best Of Nutanix CLI, je vous ai présenté l’ensemble des meilleures commandes pour vérifier l’intégralité de la configuration du réseau de votre cluster Nutanix.

Dans ce nouvel article, nous allons maintenant voir comment les commandes CLI peuvent nous aider à à créer ou à modifier les réseaux de notre cluster Nutanix…

L’ensemble des commandes de cet article sont à exécuter au niveau d’une des CVMs du cluster.

Création d’un subnet non managé sur Nutanix AHV 

Pour créer un nouveau subnet non managé (sans IPAM) à l’échelle du cluster AHV, la commande est vraiment très simple : 

acli net.create NAME vlan=VLAN_ID

Il faut remplacer :

  • NAME par le nom que vous souhaitez attribuer à votre subnet
  • VLAN_ID par l’ID du VLAN

Voici un exemple de commande qui permet de créer le vlan « NUTANIX » avec comme vlan id « 84 » :

acli net.create NUTANIX vlan=84

Par défaut, le vlan sera créé sur le vswitch « vs0 » mais si vous souhaitez le créer sur un autre virtual switch, vous pouvez le spécifier en paramètre :

acli net.create NAME vlan=VLAN_ID virtual_switch=VSWITCH

Il faut dans ce cas remplacer :

  • NAME par le nom que vous souhaitez attribuer à votre subnet
  • VLAN_ID par l’ID du VLAN
  • VSWITCH par le nom du bridge sur lequel vous voulez créer le subnet

Voici un exemple de commande qui permet de créer le vlan « NUTANIX » avec comme vlan id « 84 » sur le vswitch « vs0 » :

acli net.create NUTANIX vlan=84 virtual_switch=vs0

Vous pouvez ensuite lancer la commande « acli net.list » et vérifier que votre nouveau subnet apparait bien dans la liste.

Création d’un subnet managé sur Nutanix AHV

Cette commande permet de créer un nouveau subnet managé (avec IPAM) à l’échelle du cluster AHV avec les options de base de passerelle et masque de sous réseau. 

acli net.create NAME vlan=VLAN_ID virtual_switch=vs0 ip_config=GATEWAY/MASK

Il faut remplacer :

  • NAME par le nom que vous souhaitez attribuer à votre subnet
  • VLAN_ID par l’ID du VLAN
  • vs0 par le nom du bridge sur lequel vous voulez créer le subnet
  • GATEWAY par l’adresse IP de la passerelle du subnet
  • MASK par le masque de sous réseau

Voici un exemple de commande qui permet de créer le vlan « NUTANIX » avec un vlan id « 84 » sur le vswitch « vs0 », avec une adresse de passerelle « 10.0.84.254 » sur le réseau « 10.0.84.0/24 » :

acli net.create NUTANIX vlan=84 virtual_switch=vs0 ip_config=10.0.84.254/24

Suppression d’un subnet existant

Pour supprimer un subnet existant sur un cluster Nutanix AHV, rien de plus simple ! Il suffit de lancer la commande suivante : 

acli net.delete NAME 

Il faut remplacer NAME par le nom du subnet que vous souhaitez supprimer, ce qui donnerai par exemple pour le subnet précédemment créé :

acli net.delete NUTANIX

Rien de plus simple !

Création / Suppression de subnets en masse

Afin de me faciliter la tâche lors de l’import de grandes quantités de subnets, j’ai créé plusieurs fichiers CSV que je peux ensuite convertir en liste de commandes afin de créer à la chaine de multiples subnets.

Tout est sur mon Github : https://github.com/Exe64/NUTANIX

Pour les subnets non managés : https://github.com/Exe64/NUTANIX/blob/main/nutanix-unmanaged-subnets.csv

Pour les subnets managés : https://github.com/Exe64/NUTANIX/blob/main/nutanix-managed-subnets.csv

Pour la suppression de subnets : https://github.com/Exe64/NUTANIX/blob/main/nutanix-subnets-delete.csv

Pour en savoir plus sur l’utilisation de ces fichiers, je vous invite à consulter mon article dédié :

Nutanix AHV : gérer les subnets en lots via CLI

Documentation officielle

La documentation complète des commandes disponibles sur le site officiel de l’éditeur : https://portal.nutanix.com/page/documents/details?targetId=Command-Ref-AOS-v6_10:man-acli-c.html

Read More

Maxi Best Of Nutanix CLI : vérification de la configuration réseau

Published: 8 août 2025
Written by Julien D.
2 Comments
Categories: AHV, Guides-fr, Nutanix, Tutoriels, Tutoriels-AHV
nutanix ahv cli reference guide

Que vous ayez besoin de réaliser des opérations particulières ou répétitives, faire du troubleshooting ou d’avoir une vu plus détaillée, les commandes CLI d’un cluster Nutanix seront vos meilleures alliées.

Dans cet article, je vous propose un condensé des meilleures commandes permettant de réaliser toutes les vérifications de la configuration réseau d’un cluster Nutanix, que ce soit au niveau du cluster, des hôtes, des CVMs ou encore des machines virtuelles…

Vous devez avoir un cluster sous AOS 6.10+ pour éxecuter certaines des commandes de ce guide.

A. Via les commandes Nutanix acli depuis n’importe quelle CVM du cluster Nutanix AHV

Lister l’état des interfaces des hosts : 

acli net.list_host_nic 192.168.84.11 @IP_HOST_AHV 

Résultat :

Lister tous les vSwitchs actuellement configurés sur le cluster : 

acli net.list_virtual_switch 

Résultat :

Vous pouvez lister la configuration d’un vSwitch en particulier en le passant en argument de la commande :

acli net.list_virtual_switch vs1

Lister tous les subnets créés sur le cluster :

acli net.list 

Résultat :

Lister les VMs rattachées à un subnet en particulier :

acli net.list_vms SUBNET

B. Via le script Nutanix manage_ovs depuis n’importe quelle CVM du cluster Nutanix AHV

Lister l’état des interfaces d’un host AHV :

manage_ovs show_interfaces

Résultat :

Vous pouvez également lister l’état des interfaces de l’ensemble des hôtes du cluster :

allssh "manage_ovs show_interfaces"

Lister l’état des uplinks (bond) d’un host AHV :

manage_ovs show_uplinks

Résultat :

Vous pouvez également lister l’état des uplinks (bond) de tous les hôtes AHV du cluster :

allssh "manage_ovs show_uplinks"

Afficher les informations LLDP des interfaces d’un host AHV :

manage_ovs show_lldp

Résultat :

Vous pouvez également afficher les informations LLDP des interfaces de tous les hôtes AHV du cluster :

allssh "manage_ovs show_lldp"

Afficher les bridges actuellement créés sur un host AHV :

manage_ovs show_bridges

Résultat :

Vous pouvez également afficher les bridges actuellement créés sur tous les hôtes AHV du cluster :

allssh "manage_ovs show_bridges"

Afficher le mappage des interfaces de la CVM avec celles des hosts AHV :

manage_ovs show_cvm_uplinks_map

Résultat :

Vous pouvez également afficher le mappage des interfaces des CVM sur tous les hôtes AHV du cluster :

allssh "manage_ovs show_cvm_uplinks_map"

 

C. Via la commande Open vSwitch depuis n’importe quel hote d’un cluster Nutanix AHV 

Lister les bridges existants d’un host AHV :

ovs-vsctl list-br

Résultat :

Lister toutes les interfaces attachées à un bridge en particulier d’un host AHV :

ovs-vsctl list-ifaces br0

Résultat :

Afficher la configuration d’un port bond d’un host AHV :

ovs-vsctl list port br0-up

Résultat :

Afficher la configuration et l’état d’un bond sur un host AHV :

ovs-appctl bond/show br0-up

Résultat :

Afficher des informations sur l’état d’un bond configuré en LACP sur un host AHV :

ovs-appctl lacp/show br1-up

Un grand merci à Yohan pour l’idée d’article et le coup de main !

Read More

Nutanix AHV : VirtIO v1.2.5 est disponible !

Published: 29 juillet 2025
Written by Julien D.
No comments
Categories: AHV, Nutanix
header nutanix

La nouvelle version des VirtIO est disponible et voici les nouveautés et corrections de bugs !

Nouveautés

Le pilote QEMU « null » a été remplacé par un périphérique FwCfg entièrement fonctionnel, permettant la collecte des vidages mémoire des machines virtuelles Windows directement sur les hôtes AHV.

Ajout d’un nouveau bouton de configuration : vous pouvez désormais ajuster le nombre de requêtes d’E/S traitées avant de réessayer lorsque la file d’attente virtuelle est pleine, ce qui vous offre un meilleur contrôle sur le comportement des E/S.

Correction de bugs

Correction d’un problème gênant qui provoquait le blocage des machines virtuelles Windows après le démontage du disque. Les opérations seront fluides à partir de maintenant.

Bon à savoir

Cette nouvelle version est entièrement compatible avec toutes les versions AOS et AHV prises en charge.

Elle est disponible en téléchargement ici : https://portal.nutanix.com/page/downloads/?product=ahv&version=1.2.5&bit=VirtIO

Les anciennes versions sont toujours disponibles sur le portail d’assistance Nutanix, sous Téléchargements > AHV > VirtIO > Autres versions.

Pour obtenir de l’aide sur l’installation, consultez le Guide d’administration AHV.

A vos mises à jour !

Read More