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 !
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.
Dans un de mes précédents articles, je vous avais parlé de mon installation de Nutanix Foundation sur mon Steamdeck. Malheureusement, je n’avais pas encore eu l’opportunité de pouvoir lancer une installation avec le setup faute de serveur à imager.
Mais les choses ont changé car j’ai depuis peu en ma possession un serveur Supermicro SuperServer 5019D-FN8TP ! J’ai d’ailleurs rédigé un article sur la mise en oeuvre de Nutanix Foundation sur un matériel non officiellement supporté :
Pour pouvoir espérer imager mon noeud avec Nutanix Foundation depuis mon Steamdeck, il fallait impérativement que je sois connecté au réseau en RJ45, un type de connectique absent de la console de Valve…
J’ai donc fait l’acquisition d’un dock externe disposant de plusieurs ports USB et d’un port RJ45 connectable en USB-C.
J’ai réalisé les branchements suivants :
connexion du dock externe sur le port USB-C du Steamdeck
connexion de l’alimentation sur le port USB-C du dock prévu à cet effet
connexion du cable réseau sur le port RJ45 du dock
connexion du disque SSD externe (sur lequel est installé Windows) sur un des ports USB du dock
Cela m’a permis de faire booter le Steamdeck sur le SSD pour démarrer sous Windows 11 !
Nutanix Foundation d’un noeud avec un Steamdeck
Comme je vous en avait parlé dans le précédent article, j’ai déjà Nutanix Foundation installé donc je ne vais pas m’étendre sur cette partie là et passer directement à la partie Foundation !
Pour ce Foundation, j’ai utilisé la toute dernière version disponible à savoir la Foundation 5.9 avec les versions AOS 7 et AHV 10 !
Le processus de Foundation démarre impeccablement bien comme attendu et le processus arrive à son terme après un certains temps :
Comme vous pouvez le constater, imager un noeud avec le Steamdeck c’est possible ! Est ce que c’est pertinent ? Aucune certitude mais je peux au moins dire que « je l’ai fait ! ».
Cession à un tiers ou réutilisation du cluster pour un autre usage, il arrive parfois qu’il faille détruire un cluster Nutanix. Voici la marche à suivre pour y parvenir…
Préparation du cluster pour la destruction
Avant de pouvoir procéder à la destruction d’un cluster, il est nécessaire de réaliser quelques préparatifs.
Parmi les prérequis nécessaires, il est impératif qu’il n’y ai plus de machine virtuelle allumée sur le cluster. Veillez à migrer / éteindre / supprimer (au choix) l’ensemble des machines virtuelles sur le cluster.
Note : l’ensemble des commandes de cet article sont à saisir sur une des CVM du cluster.
Une fois que ce prérequis est rempli, on commence par vérifier le statut du cluster :
cluster status
Vous devriez obtenir un retour tel que celui ci :
nutanix@NTNX-5f832032-A-CVM:192.168.84.22:~$ cluster status
2025-07-24 07:20:18,663Z INFO MainThread zookeeper_session.py:136 Using multithreaded Zookeeper client library: 1
2025-07-24 07:20:18,666Z INFO MainThread zookeeper_session.py:248 Parsed cluster id: 4439894058604263884, cluster incarnation id: 1753169113232129
2025-07-24 07:20:18,666Z INFO MainThread zookeeper_session.py:270 cluster is attempting to connect to Zookeeper, host port list zk1:9876
2025-07-24 07:20:18,676Z INFO Dummy-1 zookeeper_session.py:840 ZK session establishment complete, sessionId=0x198310781ce5e38, negotiated timeout=20 secs
2025-07-24 07:20:18,678Z INFO MainThread cluster:3303 Executing action status on SVMs 192.168.84.22
2025-07-24 07:20:18,682Z INFO Dummy-2 zookeeper_session.py:940 Calling c_impl.close() for session 0x198310781ce5e38
2025-07-24 07:20:18,683Z INFO Dummy-2 zookeeper_session.py:941 Calling zookeeper_close and invalidating zhandle
The state of the cluster: start
Lockdown mode: Disabled
CVM: 192.168.84.22 Up, ZeusLeader
Xmount UP [459073, 459235, 459236, 459311]
IkatProxy UP [458789, 458917, 458918, 458919]
Zeus UP [454133, 454189, 454190, 454191, 454201, 454218]
Scavenger UP [459084, 459296, 459297, 459298]
SysStatCollector UP [464017, 464089, 464090, 464091]
IkatControlPlane UP [464039, 464218, 464219, 464220]
SSLTerminator UP [464170, 464323, 464324]
SecureFileSync UP [464362, 464646, 464647, 464648]
Medusa UP [468604, 469223, 469224, 469395, 470062]
DynamicRingChanger UP [476814, 476897, 476898, 476920]
Pithos UP [476843, 477058, 477060, 477086]
InsightsDB UP [476918, 477131, 477132, 477155]
Athena UP [477152, 477270, 477271, 477273]
Mercury UP [513735, 513803, 513804, 513808]
Mantle UP [477391, 477551, 477552, 477562]
VipMonitor UP [485663, 485664, 485665, 485666, 485670]
Stargate UP [477857, 477995, 477996, 477997, 477998]
InsightsDataTransfer UP [478768, 478929, 478930, 478934, 478935, 478936, 478937, 478938, 478939]
GoErgon UP [478834, 479020, 479021, 479039]
Cerebro UP [478950, 479138, 479139, 479306]
Chronos UP [479088, 479286, 479287, 479310]
Curator UP [479234, 479406, 479407, 483968]
Prism UP [479436, 479600, 479601, 479650, 480643, 480885]
Hera UP [479602, 479917, 479918, 479919]
AlertManager UP [479860, 480436, 480438, 480555]
Arithmos UP [480751, 481566, 481567, 481765]
Catalog UP [481670, 482699, 482700, 482701, 483502]
Acropolis UP [483575, 484493, 484494, 488301]
Castor UP [484403, 484877, 484878, 484911, 484972]
Uhura UP [484912, 485066, 485067, 485300]
NutanixGuestTools UP [485132, 485254, 485255, 485284, 485611]
MinervaCVM UP [491046, 491263, 491264, 491265]
ClusterConfig UP [491188, 491361, 491362, 491363, 491381]
APLOSEngine UP [491374, 491650, 491651, 491652]
APLOS UP [495252, 496063, 496064, 496065]
PlacementSolver UP [497033, 497330, 497331, 497332, 497341]
Lazan UP [497256, 497568, 497569, 497570]
Polaris UP [498016, 498620, 498621, 498911]
Delphi UP [498765, 499238, 499239, 499240, 499332]
Security UP [500506, 501578, 501579, 501581]
Flow UP [501478, 502168, 502169, 502171, 502178]
Anduril UP [510708, 511248, 511249, 511252, 511335]
Narsil UP [502382, 502472, 502473, 502474]
XTrim UP [502488, 502629, 502630, 502631]
ClusterHealth UP [502656, 502774, 503156, 503158, 503166, 503174, 503183, 503351, 503352, 503359, 503384, 503385, 503396, 503401, 503402, 503420, 503421, 503444, 503445, 503468, 503469, 503474, 503752, 503753, 503785, 503786, 503817, 503818, 528495, 528533, 528534, 530466, 530467, 530468, 530469, 530474, 530475, 530488, 530512, 530522, 530571, 530576, 530684, 530773, 530791, 531349, 531357]
2025-07-24 07:20:20,740Z INFO MainThread cluster:3466 Success!
Comme le cluster est actuellement démarré, je dois d’abord le stopper avec la commande suivante :
cluster stop
Attention, pour pouvoir arrêter le cluster, il ne doit plus rester aucune machine virtuelle allumée sur le cluster à l’exception de la CVM.
La commande va arrêter le cluster et les services associés après que vous ayez confirmé l’opération par « I agree » et devrait vous renvoyer ce type de résultat :
The state of the cluster: stop
Lockdown mode: Disabled
CVM: 192.168.84.22 Up, ZeusLeader
Xmount UP [1761344, 1761418, 1761419, 1761475]
IkatProxy UP [458789, 458917, 458918, 458919]
Zeus UP [454133, 454189, 454190, 454191, 454201, 454218]
Scavenger UP [459084, 459296, 459297, 459298]
SysStatCollector DOWN []
IkatControlPlane DOWN []
SSLTerminator DOWN []
SecureFileSync DOWN []
Medusa DOWN []
DynamicRingChanger DOWN []
Pithos DOWN []
InsightsDB DOWN []
Athena DOWN []
Mercury DOWN []
Mantle DOWN []
VipMonitor UP [485663, 485664, 485665, 485666, 485670]
Stargate DOWN []
InsightsDataTransfer DOWN []
GoErgon DOWN []
Cerebro DOWN []
Chronos DOWN []
Curator DOWN []
Prism DOWN []
Hera DOWN []
AlertManager DOWN []
Arithmos DOWN []
Catalog DOWN []
Acropolis DOWN []
Castor DOWN []
Uhura DOWN []
NutanixGuestTools DOWN []
MinervaCVM DOWN []
ClusterConfig DOWN []
APLOSEngine DOWN []
APLOS DOWN []
PlacementSolver DOWN []
Lazan DOWN []
Polaris DOWN []
Delphi DOWN []
Security DOWN []
Flow DOWN []
Anduril DOWN []
Narsil DOWN []
XTrim DOWN []
ClusterHealth DOWN []
2025-07-24 07:23:57,716Z INFO MainThread cluster:2194 Cluster has been stopped via 'cluster stop' command, hence stopping all services.
2025-07-24 07:23:57,716Z INFO MainThread cluster:3466 Success!
Nous pouvons maintenant passer à la destruction du cluster.
Destruction du cluster
La destruction du cluster nécessite l’exécution de la commande suivante :
cluster destroy
Le système vous demandera ensuite une confirmation avant de procéder à la suppression de l’ensemble des configurations et données :
2025-07-24 07:35:45,898Z INFO MainThread zookeeper_session.py:136 Using multithreaded Zookeeper client library: 1
2025-07-24 07:35:45,900Z INFO MainThread zookeeper_session.py:248 Parsed cluster id: 4439894058604263884, cluster incarnation id: 1753169113232129
2025-07-24 07:35:45,900Z INFO MainThread zookeeper_session.py:270 cluster is attempting to connect to Zookeeper, host port list zk1:9876
2025-07-24 07:35:45,916Z INFO Dummy-1 zookeeper_session.py:840 ZK session establishment complete, sessionId=0x198310781ce5e6e, negotiated timeout=20 secs
2025-07-24 07:35:45,918Z INFO Dummy-2 zookeeper_session.py:940 Calling c_impl.close() for session 0x198310781ce5e6e
2025-07-24 07:35:45,918Z INFO Dummy-2 zookeeper_session.py:941 Calling zookeeper_close and invalidating zhandle
2025-07-24 07:35:45,921Z INFO MainThread cluster:3303 Executing action destroy on SVMs 192.168.84.22
2025-07-24 07:35:45,922Z WARNING MainThread genesis_utils.py:348 Deprecated: use util.cluster.info.get_node_uuid() instead
2025-07-24 07:35:45,928Z INFO MainThread cluster:3350
***** CLUSTER NAME *****
Unnamed
This operation will completely erase all data and all metadata, and each node will no longer belong to a cluster. Do you want to proceed? (Y/[N]): Y
L’opération de destruction du cluster prend quelques minutes durant lesquelles l’ensemble des données encore présentes vont être complètement effacées.
Une fois la destruction du cluster terminée, un « cluster status » vous permettra de vérifier qu’AHV est en attente de création du cluster :
nutanix@NTNX-5f832032-A-CVM:192.168.84.22:~$ cluster status
2025-07-24 07:42:50,694Z CRITICAL MainThread cluster:3242 Cluster is currently unconfigured. Please create the cluster.
Voilà, votre cluster est détruit et il ne vous reste plus qu’à le recréer.
Pour ceux qui préfèrent suivre la procédure en vidéo, voici ma vidéo YouTube associée :
Nutanix X-Ray est un outil de test et de benchmarking conçu par Nutanix pour évaluer les performances et la résilience des infrastructures hyperconvergées (HCI). Il permet ainsi aux entreprises de simuler des charges de travail réelles et de tester la robustesse de leurs infrastructures avant leur déploiement en production.
Pourquoi utiliser Nutanix X-Ray ?
La première raison d’utiliser X-Ray est d’évaluer les performances avant un déploiement. En effet, avant de mettre en production une infrastructure hyperconvergée, il est essentiel de s’assurer qu’elle répond aux exigences de performances qui ont été définies en amont du projet.
Nutanix X-Ray répond à cette première problématique en proposant des scénarios concrets permettant de :
Simuler des charges de travail réelles, comme celles d’un data center ou d’un environnement cloud hybride.
Mesurer les performances en termes d’IOPS, de latence et de débit.
Identifier les éventuels goulets d’étranglement et les points d’amélioration.
Grâce à ces tests, les entreprises peuvent valider leurs choix technologiques avant d’investir massivement dans une solution HCI.
La seconde raison d’utiliser X-Ray est de tester la résilience d’un cluster, une caractéristique cruciale pour éviter les interruptions de service. Avec Nutanix X-Ray, il est ainsi possible de :
Simuler des pannes de nœuds, de disques ou de réseau pour voir comment l’infrastructure réagit.
Tester les mécanismes de basculement et de reprise après incident (failover).
Mesurer le temps nécessaire pour rétablir un service en cas de défaillance.
Ces tests aident à garantir une haute disponibilité et une continuité de service même en cas de problème majeur une fois le cluster en production.
X-Ray permet également de comparer plusieurs infrastructures HCI et de choisir la plus adaptée en fonction des besoins. Pour cela, il permet de réaliser :
Des benchmarks comparatifs entre différentes solutions (ex : Nutanix vs VMware vSAN).
Une analyse neutre et impartiale des performances.
Une meilleure compréhension des forces et faiblesses de chaque infrastructure.
Les résultats alors collectés vont permettre aux entreprises de prendre les bonnes décisions concernant l’évolution ou le remplacement de leur infrastructure.
Les résultats fournis par X-Ray vont également permettre de faciliter l’optimisation des environnements HCI en :
Ajustant les configurations pour maximiser la performance.
Identifiant les améliorations possibles au niveau du stockage, du réseau et du CPU.
Planifiant les évolutions de l’infrastructure en fonction des besoins futurs.
L’outil aide ainsi à réduire les coûts et à améliorer l’efficacité opérationnelle en réduisant les erreurs de dimensionnement ou de choix technologique.
Vous l’aurez compris, Nutanix X-Ray est un outil indispensable pour toute entreprise souhaitant tester, comparer et optimiser son infrastructure HCI avant et après son déploiement.
Dans le prochain article, je vous exposerais la mise en service de l’outil sur un cluster Nutanix.
Je suis intervenu chez un client qui a une grande quantité de noeuds assez anciens en production sur ses sites distants. Malheureusement, il est face à une problématique pour réaliser des installations d’AOS et AHV dessus car le matériel n’est pas officiellement supporté par Nutanix. Ayant récupéré quelques noeuds identiques, je me suis penché sur le problème pour trouver une solution…
Ils sont parfaits pour réaliser des homelabs avec leur forme factor 1U et en demi profondeur, ils peuvent s’intégrer à n’importe quelle baie domestique.
2 SSD de 1Tb (possibilité d’en ajouter 2 supplémentaires)
4 ports RJ45 1G
2 ports RJ45 10G
2 ports SFP 10G
1 port RJ45 dédié à l’IPMI
1 carte graphique NVidia Tesla P40
Je vous ai dit que ces noeuds étaient parfait pour du homelab ?
Premiers tests de foundation
Pour mes premiers tests de Foundation, j’ai choisi de partir avec une très vieille version de Foundation : la 4.6.
Niveau logiciel, je suis également partis sur une vieillerie avec une version 5.5.9.5 et l’AHV fourni dans le package. La plupart des noeuds du client tournant également sur de vieilles versions, je me suis dit que cela devrait passer.
Premier échec… d’une longue série !
J’ai testé plein de combinaisons possibles avec des Foundation en 4.6 / 5.0 / 5.4 / 5.9, des AOS en 5.5.9.5 / 5.6.1 / 5.20 / 6.10, AHV en bundle, pas en bundle… et même une image custom de Phoenix générée depuis un des noeuds récupérés… Et absolument aucun succès, avec souvent des messages d’erreurs qui différaient en fonction des combinaisons réalisées.
Mais un message revenait tout de même plus fréquemment que les autres…
La vérification de la compatibilité matérielle
Lors du processus de Foundation, il y a une étape durant laquelle le système Phoenix génère un fichier d’état de la configuration matérielle du ou des noeuds que l’on souhaite imager : le hardware_config.json.
Une fois ce fichier généré, Foundation le compare à sa liste de matériels connus pour vérifier qu’il s’agit d’un noeud qu’il est capable d’imager… Et c’est là qu’apparait mon problème :
2025-06-17 11:55:58,642Z foundation_tools.py:1634 INFO Node with ip 192.168.84.22 is in phoenix. Generating hardware_config.json
2025-06-17 11:55:58,942Z foundation_tools.py:1650 DEBUG Running command .local/bin/layout_finder.py local
2025-06-17 11:56:02,383Z foundation_tools.py:334 ERROR Command '.local/bin/layout_finder.py local' returned error code 1
stdout:
stderr:
Traceback (most recent call last):
File "/root/.local/bin/layout_finder.py", line 297, in <module>
write_layout("hardware_config.json", 1)
File "/root/.local/bin/layout_finder.py", line 238, in write_layout
top = get_layout(node_position)
File "/root/.local/bin/layout_finder.py", line 130, in get_layout
vpd_info = vpd_info_override or get_vpd_info(system_info_override)
File "/root/.local/bin/layout_finder.py", line 249, in get_vpd_info
module, model, model_string, hardware_id = _find_model_match(
File "/root/.local/bin/layout_finder.py", line 78, in _find_model_match
raise exceptions[0]
__main__.NoMatchingModule: Raw FRU: FRU Device Description : Builtin FRU Device (ID 0)
Chassis Type : Other
Chassis Part Number : CSE-505-203B
Chassis Serial : C5050LH47NA0950
Board Mfg Date : Wed Oct 31 16:00:00 2018
Board Mfg : Supermicro
Board Serial : ZM18AS036679
Board Part Number : X11SDV-8C-TP8F
Product Manufacturer : Supermicro
Product Name :
Product Part Number : SYS-5019D-FN8TP-1-NI22
Product Version :
Product Serial : S348084X9211699
Product Name: SYS-5019D-FN8TP-1-NI22
Unable to match system information to layout module. Please refer KB-7138 to resolve the issue.
Trop aimable, Foundation m’indique qu’il existe une KB car visiblement c’est un problème récurrent !
La commande va interroger l’ipmi et remonter les informations concernant le matériel :
Getting FRU ... Chassis Type (CT) = Other (01h) Chassis Part Number (CP) = CSE-505-203B Chassis Serial Number (CS) = XXXXXXXXXXXXXXX Board mfg. Date/Time (BDT) = 2018/10/31 16:00:00 (A0 3E B7) Board Manufacturer Name (BM) = Supermicro Board Product Name (BPN) = Board Serial Number (BS) = XXXXXXXXXXXX Board Part Number (BP) = X11SDV-8C-TP8F Board FRU File ID = Product Manufacturer Name (PM) = Supermicro Product Name (PN) = Product PartModel Number (PPM) = SYS-5019D-FN8TP-1-NI22 Product Version (PV) = Product Serial Number (PS) = XXXXXXXXXXXXXXX Product Asset Tag (PAT) = Product FRU File ID =
Il est ensuite possible d’éditer chacun des éléments via différentes commandes avec notamment par exemple :
Evidemment, je remplace « param » avec le paramètre désiré. Maintenant que j’ai une technique pour « mentir » au système, je dois trouver un bon mensonge…
A la recherche du modèle perdu…
La problématique dans notre cas, c’est d’avoir un FRU qui corresponde à un matériel de la liste de compatibilité intégrée à Phoenix…
J’ai testé à la chance avec des matériels approchant en remplaçant le PPM existant :
SYS-5019D-FN8TP-1-NI22 (celui d’origine
X11SDV-8C-TP8F (c’est ce modèle qui est reconnu sur Nutanix sur les noeuds du client)
NX-1120S-G7
NX-1065-G7
Le premier n’est pas reconnu lors du processus de Foundation, idem pour le second. Pour les 2 suivants, ils sont bien reconnu mais c’est un message d’erreur légèrement différent qui s’affiche…
stderr:
Traceback (most recent call last):
File "/root/.local/bin/layout_finder.py", line 297, in
write_layout("hardware_config.json", 1)
File "/root/.local/bin/layout_finder.py", line 238, in write_layout
top = get_layout(node_position)
File "/root/.local/bin/layout_finder.py", line 146, in get_layout
module.populate_layout(layout_api, layout_api.discovery_info, layout,
File "/root/.local/lib/python3.9/site-packages/layout/modules/smc_gen11_4node.py", line 104, in populate_layout
data_hbas = api.find_devices(pci_ids=["1000:0097"], min_=1, max_=1,
File "/root/.local/lib/python3.9/site-packages/layout/layout_api.py", line 300, in find_devices
raise Exception(msg)
Exception: This node is expected to have exactly 1 SAS3008. But phoenix could not find any such device
2025-06-17 12:22:11,405Z imaging_step.py:123 DEBUG Setting state of ) @c2b0> from RUNNING to FAILED
2025-06-17 12:22:11,409Z imaging_step.py:123 DEBUG Setting state of ) @ca90> from PENDING to NR
2025-06-17 12:22:11,410Z imaging_step.py:182 WARNING Skipping ) @ca90> because dependencies not met, failed tasks: [) @c2b0>]
2025-06-17 12:22:11,412Z imaging_step.py:123 DEBUG Setting state of ) @c940> from PENDING to NR
2025-06-17 12:22:11,413Z imaging_step.py:182 WARNING Skipping ) @c940> because dependencies not met
2025-06-17 12:22:11,413Z imaging_step.py:123 DEBUG Setting state of ) @c2e0> from PENDING to NR
2025-06-17 12:22:11,414Z imaging_step.py:182 WARNING Skipping ) @c2e0> because dependencies not met
Le modèle de noeud est reconnu par le processus Foundation mais il y a également une vérification de la configuration matérielle du noeud ! Par conséquent, trouver un modèle approchant n’est pas suffisant, il faut impérativement que le modèle ET la configuration matérielle soient similaires…
Mais comment trouver le bon modèle ? Et là m’est venue une idée : aller fouiller les fichiers du Phoenix monté lors de l’installation pour trouver quels modèles il s’attend à trouver…
Un petit coup de SSH sur le noeud qui est démarré sur Phoenix et dont l’installation à échouée, et me voilà à me promener dans les méandres du système pour trouver mon bonheur…
C’est dans le dossier /root/.local/lib/python3.9/site-packages/layout/modules que sont situées les informations concernant les modèles supportés. Comment je le sais ? Car dans les logs générés lors de mes précédentes tentatives, il indiquait :
File "/root/.local/lib/python3.9/site-packages/layout/modules/smc_gen11_4node.py", line 104, in populate_layout
Et dans ce dossier module, il y en a absolument pour tous les goûts :
Les noeuds concernés étant des Supermicro, j’ai axé mes recherches sur le préfixe « smc » afin de réduire le champ des possibles :
Afin de réduire encore le nombre de possibilités, j’ai éliminé tout ce qui concernait plus de 1 node (2 et 4 nodes donc) ce qui ne me laissait plus qu’une petite dizaine de possibilités et comme j’ai commencé dans l’ordre, j’ai tout de suite trouvé le bon template : smc_e300_gen11.py !
A l’intérieur du fichier, je repère immédiatement la même carte mère : X11SDV-8C-TP8F
Il est décliné en 2 modèles, SMC-E300-2 qui comporte 2 disques et le SMC-E300-4 qui en comporte 4. C’est donc le premier qui m’intéresse et en cherchant sur internet, je suis tombé sur un autre noeud de chez Supermicro, le SuperServer E300-9D-8CN8TP : https://www.supermicro.com/en/products/system/Mini-ITX/SYS-E300-9D-8CN8TP.cfm
Extrêmement ressemblant avec le noeud en ma possession, je pense que j’ai enfin trouvé le bon modèle ! Je note les éléments importants et j’éteins mon noeuds :
X11SDV-8C-TP8F (board part number)
SMC-E300-2 (modèle)
CSE-E300 (chassis part number)
La dernière ligne droite : le FRU custom
Maintenant que j’ai les informations manquantes, il faut que je modifie mon FRU pour qu’il corresponde à ce que Foundation attend comme modèle.
Puis j’ai relancé un Foundation 5.9 avec un AOS 6.10.1.6 et un AHV 20230302.103014 afin de valider que ce que j’ai trouvé fonctionne :
2025-06-18 07:35:49,786Z foundation_tools.py:1634 INFO Node with ip 192.168.84.22 is in phoenix. Generating hardware_config.json 2025-06-18 07:35:50,071Z foundation_tools.py:1650 DEBUG Running command .local/bin/layout_finder.py local 2025-06-18 07:35:54,153Z imaging_step_misc_hw_checks.py:168 DEBUG Not an NX G7+ node with RAID boot drives. Skipping RAID checks. 2025-06-18 07:35:54,156Z imaging_step.py:123 DEBUG Setting state of ) @dee0> from RUNNING to FINISHED 2025-06-18 07:35:54,157Z imaging_step.py:162 INFO Completed ) @dee0> 2025-06-18 07:35:54,159Z imaging_step.py:123 DEBUG Setting state of ) @deb0> from PENDING to RUNNING 2025-06-18 07:35:54,162Z imaging_step.py:159 INFO Running ) @deb0> 2025-06-18 07:35:54,165Z imaging_step_pre_install.py:364 INFO Rebooting into staging environment 2025-06-18 07:35:54,687Z cache_manager.py:142 DEBUG Cache HIT: key(get_nos_version_from_tarball_()_{'nos_package_path': '/home/nutanix/foundation/nos/nutanix_installer_package-release-fraser-6.10.1.6-stable-a5f69491f9523eef80d3c703f2ad4d2156e71eeb-x86_64.tar.gz'}) 2025-06-18 07:35:54,690Z imaging_step_pre_install.py:389 INFO NOS version is 6.10.1.6 2025-06-18 07:35:54,691Z imaging_step_pre_install.py:392 INFO Preparing NOS package (/home/nutanix/foundation/nos/nutanix_installer_package-release-fraser-6.10.1.6-stable-a5f69491f9523eef80d3c703f2ad4d2156e71eeb-x86_64.tar.gz) 2025-06-18 07:35:54,691Z phoenix_prep.py:82 INFO Unzipping NOS package
Il passe sans encontre la validation du matériel et l’installation fini par aller jusqu’à son terme.
Bien évidemment, c’est une rustine pour permettre à mon client de pouvoir redéployer ses noeuds et les faire durer dans le temps. La solution idéale aurait été de pouvoir créer un fichier .py personnalisé qui corresponde parfaitement à mon modèle sans que j’ai à le modifier, ce qui est malheureusement impossible à l’heure actuelle à ma connaissance.
Un soucis persiste néanmoins : le cluster peut être créé en RF2 mais la Data Resiliency sera en critique… Je cherche toujours une solution à ce problème…
Merci à Théo et Jeroen pour leurs idées qui m’ont montré le début du chemin qui m’a mené jusqu’à la solution !
Au travers de ce nouvel article, je vais vous expliquer comment assurer la supervision de votre cluster Nutanix sur Centreon en SNMP v3.
Pré requis
Il y a quelques pré requis a respecter afin de pouvoir ajouter son cluster Nutanix sur la solution Centreon. Voici la liste de ce dont vous avez besoin :
un cluster Nutanix avec des accès admin à l’interface web
un serveur Centreon opérationnel avec le connecteur Nutanix installé
un accès SSH a la VM Centreon
les flux doivent être ouverts dans le pare feu
Configuration du SNMP v3 sur le cluster Nutanix
Pour configurer le SNMP sur son cluster Nutanix, il faut commencer par se connecter au Prism Element puis aller dans « Settings > SNMP ». Cocher « Enable SNMP » et cliquer sur « + New Transport » pour ajouter le port 161 en UDP :
Ensuite, dans « Users » cliquer sur « New User », entrer un nom d’utilisateur ainsi qu’un couple clé privée en AES et clé d’authentification en SHA :
Dans mon cas, j’ai mis les informations suivantes car c’est uniquement a des fins de lab mais je vous conseille de renseigner des informations qui soient beaucoup plus complexes :
username : snmp-centreon
Priv Key : snmp-priv-key
Auth Key : snmp-auth-key
Notez bien le Username, la Priv Key et l’Auth Key, nous en aurons besoin ultérieurement. La configuration est terminée coté Nutanix, passons maintenant à la configuration coté Centreon.
Ajout du cluster Nutanix sur Centreon
Pour ajouter son cluster Nutanix sur Centreon, il faut se connecter à l’interface web de votre supervision et aller dans « Configuration > Hosts » et cliquer sur « Add » :
Sur la page qui s’affiche, il y a un premier block d’informations à remplir avec :
1 : nom du cluster
2 : adresse IP du cluster
3 : la version 3 de SNMP
4 : le serveur Centreon qui va superviser le cluster
5 : le fuseau horaire associé à votre cluster
6 : les templates que vous souhaitez ajouter
7 : cocher « Yes » pour être sûr que tous les services associés aux templates précédemment ajoutés soient automatiquement créés
Sur la deuxième partie de la page, il y a quelques petites choses a configurer notamment l’amplitude, la fréquence des checks mais surtout le champ « SNMPEXTRAOPTIONS » qui va nous permettre de configurer les identifiants précédemment créés :
La syntaxe de la ligne de commande à entrer dans SNMPEXTRAOPTIONS est la suivante :
Pensez à bien cocher la case « Password » afin de masquer les informations sensibles :
Une fois l’ensemble des informations saisies, valider afin que le nouvel hôte soit créé sur le serveur. Il faut ensuite exporter la configuration vers les pollers. Pour ce faire, cliquer en haut à gauche sur « Pollers » puis sur « Export configuration » :
Cliquer ensuite sur « Export & Reload » dans la petite fenêtre qui s’affiche :
Pour vérifier que votre hôte est bien pris en compte, rendez vous dans « Monitoring > Ressources Status », vos premiers check devraient commencer à remonter :
Si tout se passe comme prévu, vous devriez avoir toutes vos sondes au vert en quelques minutes !
Troubleshooting
Si par malheur vous avez une supervision qui ressemble à ceci :
Je vous conseille de vérifier les points suivants :
ouverture des flux SNMP (port 161/UDP) dans le pare-feu
configuration du couple AuthKey / PrivKey et du username
Effectuer une supervision constante de son cluster est la meilleure option pour s’assurer que tout fonctionne comme vous le souhaitez.
Au travers de cet article, je vais vous expliquer comment assurer la supervision de votre cluster Nutanix sur Centreon en SNMP v2c.
Pré requis
Il y a quelques pré requis a respecter afin de pouvoir ajouter son cluster Nutanix sur la solution Centreon. Voici la liste de ce dont vous avez besoin :
un cluster Nutanix avec des accès admin à l’interface web
un serveur Centreon opérationnel avec le connecteur Nutanix installé
un accès SSH a la VM Centreon
les flux doivent être ouverts dans le pare feu
Configuration du SNMP v2c sur le cluster Nutanix
Pour configurer le SNMP sur son cluster Nutanix, il faut commencer par se connecter au Prism Element puis aller dans « Settings > SNMP ». Cocher « Enable SNMP » et cliquer sur « + New Transport » pour ajouter le port 161 en UDP :
Ensuite, dans « Traps » cliquer sur « + New Trap Receiver » et renseigner les champs suivants :
Receiver Name : le nom que vous souhaitez attribuer à votre Receiver
Cocher v2c
Community : indiquez la communauté SNMP que vous souhaitez utiliser
Address : l’adresse de votre serveur Centreon
Port : 161
Transport protocol : UDP
Cliquer sur « Save » pour enregistrer la configuration.
Ajout du cluster Nutanix sur Centreon
Pour ajouter son cluster Nutanix sur Centreon, il faut se connecter à l’interface web de votre supervision et aller dans « Configuration > Hosts » et cliquer sur « Add » :
Sur la page qui s’affiche, il y a un premier block d’informations à remplir avec :
1 : nom du cluster
2 : adresse IP du cluster
3 : la communauté que vous avez renseigné sur le trap receiver
4 : la version 2c de SNMP
5 : le serveur Centreon qui va superviser le cluster
6 : le fuseau horaire associé à votre cluster
7 : les templates que vous souhaitez ajouter
8 : cocher « Yes » pour être sûr que tous les services associés aux templates précédemment ajoutés soient automatiquement créés
Sur la deuxième partie de la page, il y a quelques petites choses a configurer notamment l’amplitude et la fréquence des checks :
Une fois l’ensemble des informations saisies, valider afin que le nouvel hôte soit créé sur le serveur. Il faut ensuite exporter la configuration vers les pollers. Pour ce faire, cliquer en haut à gauche sur « Pollers » puis sur « Export configuration » :
Cliquer ensuite sur « Export & Reload » dans la petite fenêtre qui s’affiche :
Pour vérifier que votre hôte est bien pris en compte, rendez vous dans « Monitoring > Ressources Status », vos premiers check devraient commencer à remonter :
Si tout se passe comme prévu, vous devriez avoir toutes vos sondes au vert en quelques minutes !
Troubleshooting
Si par malheur vous avez une supervision qui ressemble à ceci :
Je vous conseille de vérifier les points suivants :
ouverture des flux SNMP (port 161/UDP) dans le pare-feu
configuration du Traps Receiver sur le cluster Nutanix
configuration de la communauté sur le serveur Centreon
Lors d’une intervention le cluster de l’un de nos clients, je me suis heurté à un soucis de taille : l’impossibilité de supprimer un container de stockage qui avait pourtant été vidé de son contenu au préalable…
Un peu de contexte
La nécessité de supprimer un container de stockage est apparue lorsque nous avons décidé de migrer les machines virtuelles vers d’autres containers. Pourquoi devoir faire cela ? Dans le cadre d’un On Demand Cross Cluster Live Migration, l’un des prérequis est d’avoir des noms identiques sur les containers de stockages…
Pour ce faire, nous avons donc procédé à la migration des vdisks en CLI, une opération longue et fastidieuse que je détaillerais peut être dans un prochain article.
Une fois l’ensemble des vdisks migrés, nous ne pouvions toujours pas supprimer le container…
Diagnostic du problème
Pour commencer, j’ai d’abord listé l’ensemble des containers présents sur mon cluster pour identifier celui qui m’intéresse :
nutanix@CVM:~$ ncli container list
Id : 00060f28-23f5-dbbb-7c17-7cc255a7f766::7
Uuid : ecc3d02d-57c0-4253-a5a4-a335aa3bdcd4
Name : default-container-15796345896744
Storage Pool Id : 00060f28-23f5-dbbb-7c17-7cc255a7f766::6
Storage Pool Uuid : 4fa56350-ece0-4932-8ec9-70669e241470
Free Space (Logical) : 31.16 TiB (34,265,616,109,568 bytes)
Used Space (Logical) : 90.79 GiB (97,483,378,688 bytes)
Allowed Max Capacity : 31.25 TiB (34,363,099,488,256 bytes)
Used by other Containers : 574.87 GiB (617,261,654,016 bytes)
Explicit Reservation : 0 bytes
Thick Provisioned : 0 bytes
Replication Factor : 2
Oplog Replication Factor : 2
NFS Whitelist Inherited : false
Container NFS Whitelist :
VStore Name(s) : default-container-15796345896744
Random I/O Pri Order : SSD-MEM-NVMe, SSD-PCIe, SSD-SATA, DAS-SATA
Sequential I/O Pri Order : SSD-PCIe, SSD-SATA, SSD-MEM-NVMe, DAS-SATA
Compression : on
Compression Delay : 0 mins
Fingerprint On Write : off
On-Disk Dedup : off
Erasure Code : off
Software Encryption : off
Une fois mon container identifié (default-container-15796345896744), je tente une suppression en CLI avec la ligne de commande suivante :
Error: Storage container default-container-15796345896744 contains VDisk(s) not marked for removal.
Le message est assez explicite, il reste des VDisks dans mon container ce qui bloque complètement la suppression. Pour rappel, j’ai procédé à la migration de l’ensemble des vdisks de mes machines virtuelles, il ne devrait donc rien rester dessus…
Je check le contenu de mon vdisk avec la commande suivante (remplacez le container_id par celui correspondant à votre container) :
Il faut remplacer le « vdisk_id » en gras dans la commande par le vdisk_id de chaque fichier renvoyé par la commande « vdisk_config_printer -container_id=7 -skip_to_remove_vdisks », par exemple :
Répétez l’opération avec l’ensemble des fichiers jusqu’à ce que la commande « vdisk_config_printer -container_id=7 -skip_to_remove_vdisks » n’affiche plus rien.
Cette opération est assez longue et fastidieuse à appliquer mais elle vous permettra de supprimer un container de stockage récalcitrant. Si après ces manipulations la suppression du container de stockage est tout de même impossible, c’est qu’il reste des fichiers qui n’ont pas été déplacés / migrés.
Voici une petite procédure rapide pour installer les Nutanix Guest Tools manuellement sur vos machines virtuelles Linux (Rocky Linux, RHEL, CentOS…) en lignes de commande.
Qu’est ce que les Nutanix Guest Tools ?
NGT est un ensemble de fonctionnalités logicielles installées sur une machine virtuelle (VM) et une machine virtuelle Nutanix CVM. Un agent invité Nutanix publie des informations sur la machine virtuelle sur le cluster Nutanix, telles que le type de système d’exploitation invité, l’état de mobilité de la machine virtuelle et le service de cliché instantané des volumes (VSS). L’agent invité Nutanix est installé sur les machines virtuelles invitées Windows et Linux.
Montage des Nutanix Guest Tools
Connectez vous à votre cluster Nutanix sur Prism Central, allez dans la liste des machines virtuelles, faites un clic droit sur la machine virtuelle sur laquelle vous souhaitez installer les NGT et cliquez sur « Install NGT » :
Sur l’écran suivant, dans mon cas pas besoin de changer quoi que ce soit, cliquez sur « Confirm and Enter Password » :
On ne touche à rien sur cet écran, cliquez simplement sur « Skip and Mount » en bas à gauche :
L’ISO est monté, on passe maintenant aux lignes de commande !
Installation des Nutanix Guest Tools (ex : Rocky Linux)
Voici les commandes à passer sur la machine virtuelle pour installer les Nutanix Guest Tools :
Mise à jour du système :
sudo dnf update && sudo dnf upgrade
Installation de python (si non présent sur la machine) :
sudo dnf install python3
Vérification de l’identifiant du lecteur :
blkid -L NUTANIX_TOOLS
Retour de commande:
/dev/sr0
Montage de l’ISO :
sudo mount /dev/sr0 /mnt
Installation des NGT :
systemd-run --unit=ngt_guest_agent_upgrade --slice=upgrade_ngt sh /mnt/installer/linux/ngt_rpm_installer/ngt_install_upgrade.sh
Vérification de l’installation en ligne de commande :
We use cookies to improve your experience on our site. By using our site, you consent to cookies.
This website uses cookies
Websites store cookies to enhance functionality and personalise your experience. You can manage your preferences, but blocking some cookies may impact site performance and services.
Essential cookies enable basic functions and are necessary for the proper function of the website.
Name
Description
Duration
Cookie Preferences
This cookie is used to store the user's cookie consent preferences.
30 days
These cookies are needed for adding comments on this website.
Name
Description
Duration
comment_author
Used to track the user across multiple sessions.
Session
comment_author_email
Used to track the user across multiple sessions.
Session
comment_author_url
Used to track the user across multiple sessions.
Session
Statistics cookies collect information anonymously. This information helps us understand how visitors use our website.
Matomo is an open-source web analytics platform that provides detailed insights into website traffic and user behavior.
