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 10 et AHV 7 !
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 :
Cela fait partie des opérations que je conseille de réaliser sur un cluster OVHcloud juste après la livraison : le remplacement de la passerelle pré déployée qui permettra à votre cluster de sortir sur internet.
Nous allons voir dans cet article comment déployer une PA-VM de chez Palo Alto et comment réaliser sa configuration de base afin qu’elle soit prête à être connectée au RTvRack OVHcloud (ce qui fera l’objet d’un autre article).
Pré-requis
Voici la liste des pré-requis nécessaires au déploiement :
un cluster Nutanix OVHcloud déployé
les subnets dont vous avez besoin créés sur le cluster
une VM de rebond déployée sur le cluster
un compte Palo Alto avec les accès aux téléchargements d’images
Le disque a ajouter est celui qui a été récupéré au format qcow2 sur le site de Palo Alto.
Sélectionnez également les subnets qui devront être connectés à votre passerelle. La première interface que vous allez ajouter sera toujours l’interface de management de la PA-VM, veillez donc à sélectionner le bon subnet qui dans l’idéal sera un subnet dédié aux interfaces de management. Votre VM de rebond devra avoir une interface dans ce subnet afin de pouvoir accéder à l’interface web de la PA-VM. Voici par exemple ce que je recommanderais comme configuration des interfaces :
Management
ethernet1/1 (subnet 0 créé par défaut sur le cluster, pour la sortie WAN)
ethernet1/2 (subnet interne 1, souvent celui qui correspond à votre infra Nutanix)
ethernet1/3 (subnet interne 2)
…
Il est important de bien sélectionner « Legacy BIOS Mode » lors de la création de la VM sinon elle ne bootera pas !
Sélectionner « Use this VM as an Agent VM » pour qu’elle soit démarrée en tout premier.
Validez les paramètres, la machine virtuelle est prête à être démarrée.
Initialisation de la PA-VM
Démarrer la VM et lancer la console depuis l’interface Nutanix. Patienter pendant le démarrage du système d’exploitation.
La première connexion se fait en CLI avec les identifiants suivants :
Identifiant : admin
Mot de passe : admin
Le système va demander de changer le mot de passe par défaut. On passe ensuite en mode configuration :
configure
Ensuite, configuration de l’IP de management en mode static :
set deviceconfig system type static
Configuration des paramètres de l’interface de management :
set deviceconfig system ip-address <Firewall-IP> netmask <netmask> default-gateway <gateway-IP> dns-setting servers primary <DNS-IP>
A ce stade, le pare feu est accessible depuis le navigateur web de la machine de rebond à l’adresse : https://<Firewall-IP>
ATTENTION : cela ne fonctionne que si la VM de rebond a une patte dans le même subnet que celui de l’interface de Management
On oublie pas de commit soit depuis l’interface web, soit en ligne de commande :
commit
Vous pouvez maintenant poursuivre la configuration sur l’interface Web.
Configurations de base de la PA-VM
On attaque avec la configuration de base de la PA-VM.
Sur l’interface web, dans « Device > Setup », éditer le widget « General Settings » pour renseigner à minima le Hostname et la Timezone :
Aller ensuite dans l’onglet « Services » et éditer le widget « Services » pour ajouter les serveurs DNS et les serveurs NTP :
Il ne reste plus qu’à commit les changements, la configuration basique de la passerelle Palo Alto est terminée.
Je tiens à préciser qu’il s’agit là d’une configuration de base et qu’il y en encore beaucoup d’autres points de configuration à réaliser pour avoir une passerelle qui soit parfaitement configurée, sécurisée et qui permette à votre cluster de sortir sur internet, avec notamment la partie authentification, la complexité des mots de passe, le VPN, les règles de pare-feu…
Nous verrons dans un prochain article comment connecter votre passerelle Palo Alto PA-VM au RTvRack OVHcloud afin de permettre à votre cluster de sortir sur Internet.
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 sur 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 facile 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 outils 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’outils sur un cluster Nutanix.
Angelo Luciani, le responsable du programme Nutanix Technology Champion, nous avait prévenu qu’il préparait des récompenses qui seraient décernées lors du .NEXT à certains d’entre nous sans pour autant nous donner plus de détails.
Une fois le déjeuner terminé, il est monté sur l’estrade et a lancé la cérémonie qui allait récompenser 3 membres du programme pour leur implication. Les prix étaient les suivants :
Nutanix Community Excellence récompensant l’implication sur les forums Nutanix
Nutanix NTC Storyteller récompensant l’implication sur le blog et les réseaux sociaux
Nutanix User Group Champion récompensant l’implication dans les NUG
Nutanix NTC Storyteller : une reconnaissance qui donne du sens
Quand j’ai commencé à bloguer, mon objectif était simple : partager. Mes tests, mes galères, mes découvertes, mes coups de cœur tech. Je n’avais ni prétention, ni feuille de route précise, juste l’envie de partager à ma façon.
Le blog comptabilise aujourd’hui plus de 110 articles, chacun écrits en français et entièrement traduis en anglais. C’est un travail colossal et de longue haleine, qui a nécessité des heures de recherches, de tests, de brainstorming… pour aboutir à de simples posts ou bien des guides entiers.
Et il y a des moments dans un parcours où tout ce travail de l’ombre, tous ces mots alignés, finissent par résonner au-delà de l’écran.
Aujourd’hui, j’ai l’immense plaisir (et une certaine émotion, je l’avoue) de partager avec vous l’obtention du trophée « Nutanix NTC Storyteller ».
Être reconnu en tant que « Storyteller » par le programme Nutanix Technology Champions (NTC), ce n’est pas seulement un trophée qui va orner mon étagère, c’est une reconnaissance de ma volonté constante de rendre la technologie plus lisible, plus accessible et plus compréhensible.
Ce trophée c’est pour moi :
Une reconnaissance de mon engagement dans la communauté technique
Un signal fort que le contenu de qualité, authentique et régulier compte plus que la quantité
Un coup de projecteur sur l’importance du rôle de transmission dans notre métier
Mais surtout, une motivation supplémentaire pour continuer à créer, partager et connecter les idées
Merci à tous ceux qui me lisent, commentent, partagent et me challengent (vous vous reconnaitrez).
Merci à Nutanix et tout particulièrement Angelo Luciani sans qui tout ceci n’aurai été possible.
Merci à la communauté NTC qui m’a énormément apporté en inspiration, en rencontres, en apprentissage et en particulier mes 2 « partners in crime » : Jeroen et Maroane.
Ce trophée n’est pas une fin, mais un nouveau point de départ. Il me pousse à aller plus loin, à explorer de nouveaux formats (avec notamment une chaine YouTube) et à continuer à parler d’infrastructures et d’hyperconvergence avec la même passion et la même énergie.
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…
Configuration matérielle des noeuds
Ces noeuds sont des noeuds Supermicro SuperServer 5019D-FN8TP :
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 !
Dans le précédent article, je vous ai expliqué comment superviser votre cluster sur Centreon en SNMP v2c.
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 toute 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 souhaiter 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
Les entreprises sont de plus en plus nombreuses à adopter des infrastructures multicloud pour bénéficier de la flexibilité, de l’agilité et de la sécurité. Pour répondre à ce besoin, OVHcloud s’est associé à Nutanix afin de proposer des solutions optimisées pour la gestion de solutions clouds hybrides.
Je vous propose de découvrir les offres Nutanix on OVHcloud et en quoi elles peuvent aider à transformer les infrastructures des entreprises.
OVHcloud et Nutanix : une collaboration stratégique
OVHcloud, acteur majeur du cloud européen, et Nutanix, leader des solutions hyperconvergées, collaborent pour proposer des services performants, sécurisés et adaptés aux entreprises. Ce partenariat vise à offrir une plateforme cloud intégrée et sécurisée, permettant aux entreprises de se concentrer sur leurs applications sans se soucier de la gestion de l’infrastructure sous-jacente.
L’intégration des solutions Nutanix dans le cloud d’OVHcloud permet de créer un environnement multicloud simplifié, offrant une grande flexibilité d’utilisation pour les équipes IT. Les clients peuvent déployer leurs applications à travers des environnements hybrides et multiclouds tout en bénéficiant d’une gestion unifiée, d’une sécurité renforcée et d’une réduction des coûts opérationnels.
Les solutions Nutanix chez OVHcloud
Les offres Nutanix on OVHcloud incluent plusieurs services essentiels pour les entreprises cherchant à moderniser et à simplifier leur infrastructure :
Nutanix Cloud Platform sur OVHcloud : Cette plateforme fournit une infrastructure cloud évolutive et intégrée avec une solution hyperconvergée (HCI) de Nutanix. Elle permet d’exécuter des charges de travail variées, telles que des bases de données, des applications de productivité et des applications critiques, tout en assurant une sécurité élevée et une performance optimale.
HYCU Backup : OVHcloud propose également une offre de backup de votre infrastructure Nutanix au travers de la solution HYCU Backup, un logiciel de sauvegarde complet et parfaitement intégré à Nutanix.
Les avantages des offres Nutanix d’OVHcloud
Adopter les offres Nutanix on OVHcloud présente plusieurs avantages :
Simplicité et gestion centralisée : Les solutions Nutanix offrent une interface de gestion centralisée permettant aux équipes IT de gérer leurs ressources dans un environnement multicloud sans complexité supplémentaire.
Souveraineté des données : OVHcloud est conforme aux standards européens en matière de protection des données. Couplées aux solutions Nutanix, les entreprises bénéficient de niveaux de sécurité élevés et de contrôles d’accès renforcés.
Flexibilité des licences : Toutes les licences matérielles et logicielles peuvent être fournies par OVHcloud, contribuant ainsi à éliminer la complexité et les coûts cachés ou à apporter votre propre licence Nutanix pour faciliter l’approvisionnement des ressources OVHcloud.
Performance et évolutivité : Les solutions Nutanix on OVHcloud offrent une infrastructure performante et scalable, adaptée aux besoins croissants des entreprises. Avec la flexibilité des solutions Nutanix, les entreprises peuvent ajuster facilement leurs ressources selon leurs besoins en ajoutant des noeuds à la demande pour augmenter les ressources matérielles de leurs clusters.
Réduction des coûts : L’infrastructure hyperconvergée de Nutanix réduit les coûts opérationnels en simplifiant la gestion de l’infrastructure et en diminuant le recours à des serveurs physiques. Les clients d’OVHcloud peuvent ainsi optimiser leurs dépenses IT tout en bénéficiant de performances élevées.
Cas d’utilisation : comment les entreprises tirent-elles parti des offres Nutanix on OVHcloud ?
Les offres Nutanix on OVHcloud sont particulièrement adaptées pour les cas d’usage suivants :
Des cas d’usages renforcés par les options proposées par OVHcloud :
Conclusion
Les offres Nutanix on OVHcloud représentent une solution complète pour les entreprises cherchant à gérer efficacement leurs infrastructures multicloud. En combinant la performance des solutions Nutanix avec la flexibilité et la sécurité du cloud d’OVHcloud, les entreprises peuvent bénéficier d’une infrastructure évolutive, performante et en conformité avec les régulations européennes.
En adoptant les solutions Nutanix on OVHcloud, les entreprises peuvent simplifier leur infrastructure, renforcer leur sécurité, optimiser leurs coûts et se concentrer sur leur croissance.
Si on ajoute à cela des services complémentaires tels que la gestion des clés KMS ou encore la solution de sauvegarde HYCU, nous avons clairement un concurrent Européen sérieux à Google Cloud, AWS ou encore Azure…
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.
