Team Leader - Nutanix Technology Champion - Nutanix NTC Storyteller

Julien DUMUR
Infrastructure in a Nutshell

Nutanix AHV FR

Nutanix AHV – Détruire un cluster

Published: 25 juillet 2025
Written by Julien D.
No comments
Categories: Nutanix, Nutanix AHV FR, Tutoriels, Tutoriels-AHV
header nutanix

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 :

Read More

Nutanix X-Ray : Présentation de l’outils

Published: 13 juillet 2025
Written by Julien D.
No comments
Categories: Nutanix, Nutanix AHV FR

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.

La documentation officielle de Nutanix X-Ray : https://portal.nutanix.com/page/documents/details?targetId=X-Ray-Guide-v5_3:X-Ray-Guide-v5_3

Read More

Nutanix AHV : foundation d’un matériel non officiel / supporté

Published: 22 juin 2025
Written by Julien D.
2 Comments
Categories: Nutanix, Nutanix AHV FR, Tutoriels, Tutoriels-AHV

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.

La configuration matérielle est la suivante :

  • Processeur : Intel® Xeon® processor D-2146NT, 8 coeurs / 16 threads
  • 128Gb RAM (extension possible jusqu’à 512Gb)
  • 1 boot disque M.2
  • 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 !

Lien de la KB Nutanix : https://portal.nutanix.com/page/documents/kbs/details?targetId=kA00e000000PVxTCAW

Voyons maintenant comment régler mon problème…

Modification du FRU

La KB Nutanix indique qu’il faut éditer le FRU de notre matériel pour le faire correspondre à un matériel de la liste de compatibilité.

Pour ce faire, il faut utiliser l’utilitaire SMCIPMITools fourni par Supermicro et disponible ici : https://www.supermicro.com/en/solutions/management-software/ipmi-utilities

Une fois l’utilitaire récupéré, il faut le lancer en ligne de commande avec les bons paramètres :

./SMCIPMITool.exe IP_ADDRESS ADMIN PASSWORD ipmi fru

Les paramètres sont les suivants :

  • Adresse ip de l’IPMI de votre noeud
  • Login du compte admin (par défaut c’est ADMIN)
  • Le mot de passe associé

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 :

SMCIPMITool.exe IP_ADDRESS ADMIN password ipmi fruw PM "param"
SMCIPMITool.exe IP_ADDRESS ADMIN password ipmi fruw PN "NONE"
SMCIPMITool.exe IP_ADDRESS ADMIN password ipmi fruw PPM "param"
SMCIPMITool.exe IP_ADDRESS ADMIN password ipmi fruw PV "NONE"

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.

Voici les commandes que j’ai lancé :

./SMCIPMITool.exe ip_address ADMIN password ipmi fruw CP "CSE-E300"
./SMCIPMITool.exe ip_address ADMIN password ipmi fruw PPM "SMC-E300-2"
./SMCIPMITool.exe ip_address ADMIN password ipmi fruw PN "NONE"
./SMCIPMITool.exe ip_address ADMIN password ipmi fruw PV "NONE"

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 !

Lien de la KB Nutanix utilisée : https://portal.nutanix.com/page/documents/kbs/details?targetId=kA00e000000PVxTCAW

Read More

Nutanix x Centreon : supervision de son cluster en SNMP v3

Published: 19 juin 2025
Written by Julien D.
No comments
Categories: Nutanix, Nutanix AHV FR, Supervision, Tutoriels, Tutoriels-AHV

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 :

--snmp-username='snmp-centreon' --authprotocol='SHA' --authpassphrase='snmp-auth-key' --privprotocol='AES'--privpassphrase='snmp-priv-key'

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
Read More

Nutanix AHV x Centreon : superviser un cluster en SNMP v2c

Published: 11 juin 2025
Written by Julien D.
No comments
Categories: Nutanix, Nutanix AHV FR, Supervision

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
Read More

Nutanix AHV : Storage container contains VDisk(s) not marked for removal

Published: 2 mai 2025
Written by Julien D.
No comments
Categories: Nutanix, Nutanix AHV FR, Tutoriels, Tutoriels-AHV
header nutanix

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 :

nutanix@CVM:~$ ncli ctr rm name=default-container-15796345896744
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) :

nutanix@CVM:~$ vdisk_config_printer -container_id=7 -skip_to_remove_vdisks

vdisk_id: 1247912
vdisk_name: "$NTNX$-$CURATOR$-$CHAINVDISK$-$0630848d-af0a-440b-9bf2-14ed432105c2$7$"
vdisk_size: 0
container_id: 7
creation_time_usecs: 1724796346611475
mutability_state: kImmutable
snapshot_chain_id: 8053639
vdisk_creation_time_usecs: 1724796346611475
last_updated_pithos_version: kChainIdKey
vdisk_uuid: "faa173c5-be0a-4502-9977-02d9c125b02e"
chain_id: "0630848d-af0a-440b-9bf2-14ed432105c2"
last_modification_time_usecs: 1724800080940533
vdisk_id: 22562934
vdisk_name: "NFS:2:0:2513"
vdisk_size: 4398046511104
container_id: 7
creation_time_usecs: 1741004981139322
vdisk_creator_loc: 4
vdisk_creator_loc: 789428
vdisk_creator_loc: 9451518309
nfs_file_name: "nutanix_guest_tools.iso"
may_be_parent: true
never_hosted: false
snapshot_draining: false
snapshot_chain_id: 22562935
vdisk_creation_time_usecs: 1741004981139322
oplog_type: kVDiskOplog
vdisk_snapshot_time_usecs: 1741004983089382
last_updated_pithos_version: kChainIdKey
always_write_emap_extents: true
vdisk_uuid: "5b601b32-eaf5-4612-9bdf-f8ce3a24c96b"
chain_id: "ebd35e10-4917-476a-9cb7-8447478af99c"
last_modification_time_usecs: 1741004985848279
vdisk_id: 28693745
vdisk_name: "NFS:2:0:2703"
parent_vdisk_id: 9701970
vdisk_size: 10737418240
container_id: 7
creation_time_usecs: 1724235742966570
mutability_state: kImmutableSnapshot
closest_named_ancestor: "NFS:4611686018456079974"
avoid_vblock_copy_when_leaf: true
vdisk_creator_loc: 4
vdisk_creator_loc: 27341647
vdisk_creator_loc: 454849015
nfs_file_name: "a8893eb4-a9b8-4710-80c8-e69fb0093bb0"
may_be_parent: true
parent_nfs_file_name_hint: "a8893eb4-a9b8-4710-80c8-e69fb0093bb0"
scsi_name_identifier: "naa.6506b8dc3a35444155c2731c8d7a8b94"
never_hosted: false
snapshot_draining: false
parent_draining: false
clone_parent_draining: false
snapshot_chain_id: 8053639
has_complete_data: true
clone_source_vdisk_id: 7790073
vdisk_creation_time_usecs: 1745309380225031
originating_vdisk_snapshot_time_usecs: 1724235742966570
oplog_type: kVDiskOplog
vdisk_snapshot_time_usecs: 1745310092381733
last_updated_pithos_version: kChainIdKey
always_write_emap_extents: true
vdisk_uuid: "c1b33a68-dd3e-4afc-917e-67f8c257f40f"
chain_id: "0630848d-af0a-440b-9bf2-14ed432105c2"
parent_chain_id: "af907cc8-795b-4382-907c-4b318529bfcb"
vdisk_snapshot_uuid: "bdbf64db-51ad-4310-86cc-ce68107c20f0"
last_modification_time_usecs: 1745310094964928
vdisk_id: 7783219
vdisk_name: "NFS:2:0:472"
vdisk_size: 4398046511104
container_id: 7
creation_time_usecs: 1723639427516394
vdisk_creator_loc: 3
vdisk_creator_loc: 1247802
vdisk_creator_loc: 675287599
nfs_file_name: "pc.2022.6.0.10-pc-boot.qcow2"
never_hosted: false
snapshot_chain_id: 7783220
vdisk_creation_time_usecs: 1723639427516394
oplog_type: kVDiskOplog
last_updated_pithos_version: kChainIdKey
always_write_emap_extents: true
vdisk_uuid: "db1edf28-7241-451a-b74a-e2f6b68ef394"
chain_id: "874ae2f3-1f2e-4d90-87f3-a755b14c374c"
last_modification_time_usecs: 1723639427524005
vdisk_id: 7783222
vdisk_name: "NFS:2:0:473"
vdisk_size: 4398046511104
container_id: 7
creation_time_usecs: 1723639427831077
vdisk_creator_loc: 3
vdisk_creator_loc: 1247802
vdisk_creator_loc: 675288112
nfs_file_name: "pc.2022.6.0.10-pc-home.qcow2"
never_hosted: false
snapshot_chain_id: 7783223
vdisk_creation_time_usecs: 1723639427831077
oplog_type: kVDiskOplog
last_updated_pithos_version: kChainIdKey
always_write_emap_extents: true
vdisk_uuid: "1d4c82bc-01b2-44da-af1c-fbedda5d3dc2"
chain_id: "83600772-9e50-4050-9957-37da1dac220f"
last_modification_time_usecs: 1723639427839142
vdisk_id: 7783355
vdisk_name: "NFS:2:0:474"
vdisk_size: 4398046511104
container_id: 7
creation_time_usecs: 1723639463452092
vdisk_creator_loc: 3
vdisk_creator_loc: 1247802
vdisk_creator_loc: 675381384
nfs_file_name: "pc.2022.6.0.10-pc-boot.img"
may_be_parent: true
never_hosted: false
snapshot_chain_id: 7783356
vdisk_creation_time_usecs: 1723639463452092
oplog_type: kVDiskOplog
vdisk_snapshot_time_usecs: 1723639536592896
last_updated_pithos_version: kChainIdKey
always_write_emap_extents: true
vdisk_uuid: "cbec4f1c-06e5-400e-bb4b-c71df4cd7e38"
chain_id: "d42ab524-a749-4a51-a1a3-3bf225c0fc12"
last_modification_time_usecs: 1723639536600475
vdisk_id: 7783363
vdisk_name: "NFS:2:0:475"
vdisk_size: 4398046511104
container_id: 7
creation_time_usecs: 1723639463571411
vdisk_creator_loc: 3
vdisk_creator_loc: 1247802
vdisk_creator_loc: 675381960
nfs_file_name: "pc.2022.6.0.10-pc-home.img"
may_be_parent: true
never_hosted: false
snapshot_draining: false
snapshot_chain_id: 7783364
vdisk_creation_time_usecs: 1723639463571411
oplog_type: kVDiskOplog
vdisk_snapshot_time_usecs: 1723639536653959
last_updated_pithos_version: kChainIdKey
always_write_emap_extents: true
vdisk_uuid: "358783f7-b35d-42ae-82cc-24a8dc0bf084"
chain_id: "0805ab92-e816-4fe6-8851-7ffa9af75188"
last_modification_time_usecs: 1723639548309692

La commande me permet d’afficher l’ensemble des fichiers qui ne sont pas marqués « pour suppression ». Dans l’ensemble, il s’agit de :

  • vieux snapshots dont les machines virtuelles n’existent plus ou ne sont plus liées
  • des ISOs d’installation des Nutanix Guest Tools
  • des anciens fichiers de mises à jour de Prism Central

Maintenant que je sais d’où vient le problème, il est temps de le régler…

Suppression des fichiers

Pour supprimer les fichiers, il faut les éditer un par un avec la commande suivante :

edit_vdisk_config --vdisk_id=vdisk_id --editor=vim

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 :

vdisk_id: 1247912
vdisk_name: "$NTNX$-$CURATOR$-$CHAINVDISK$-$0630848d-af0a-440b-9bf2-14ed432105c2$7$"
vdisk_size: 0
container_id: 7
creation_time_usecs: 1724796346611475
mutability_state: kImmutable
snapshot_chain_id: 8053639
vdisk_creation_time_usecs: 1724796346611475
last_updated_pithos_version: kChainIdKey
vdisk_uuid: "faa173c5-be0a-4502-9977-02d9c125b02e"
chain_id: "0630848d-af0a-440b-9bf2-14ed432105c2"
last_modification_time_usecs: 1724800080940533

Donnera la commande suivante :

edit_vdisk_config --vdisk_id=1247912 --editor=vim

Cela ouvre le fichier concerné :

vdisk_id: 1247912
vdisk_name: "$NTNX$-$CURATOR$-$CHAINVDISK$-$0630848d-af0a-440b-9bf2-14ed432105c2$7$"
vdisk_size: 0
container_id: 7
creation_time_usecs: 1724796346611475
mutability_state: kImmutable
snapshot_chain_id: 8053639
vdisk_creation_time_usecs: 1724796346611475
last_updated_pithos_version: kChainIdKey
vdisk_uuid: "faa173c5-be0a-4502-9977-02d9c125b02e"
chain_id: "0630848d-af0a-440b-9bf2-14ed432105c2"
last_modification_time_usecs: 1724800080940533

Il faut alors ajouter « to_remove: true » à la toute fin du fichier et le sauvegarder :

vdisk_id: 1247912
vdisk_name: "$NTNX$-$CURATOR$-$CHAINVDISK$-$0630848d-af0a-440b-9bf2-14ed432105c2$7$"
vdisk_size: 0
container_id: 7
creation_time_usecs: 1724796346611475
mutability_state: kImmutable
snapshot_chain_id: 8053639
vdisk_creation_time_usecs: 1724796346611475
last_updated_pithos_version: kChainIdKey
vdisk_uuid: "faa173c5-be0a-4502-9977-02d9c125b02e"
chain_id: "0630848d-af0a-440b-9bf2-14ed432105c2"
last_modification_time_usecs: 1724800080940533
to_remove: true

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.

On relance la commande de suppression du container :

nutanix@CVM:~$ ncli ctr rm name=default-container-15796345896744
Error: Storage container default-container-15796345896744 contains small NFS files

Encore une erreur ! Et oui, il reste des fichiers de petite taille qui trainent et il faut forcer la suppression :

nutanix@CVM:~$ ncli ctr rm id=7 ignore-small-files=true
Storage container deleted successfully

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.

Read More

Nutanix AHV : Installer manuellement les Nutanix Guests Tools sur Linux en CLI

Published: 24 avril 2025
Written by Julien D.
No comments
Categories: Nutanix, Nutanix AHV FR, Tutoriels, Tutoriels-AHV
header nutanix

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 :
[root@XXXXXXXXXX administrateur]# yum list installed | grep 'nutanix-guest-agent'
nutanix-guest-agent.x86_64 4.1.2-1 @nutanix-ngt-20250423153748
  • Vérification de l’installation sur Prism Central :

  • Démontage de l’ISO :
umount /dev/sr0

Ca y est, vos Nutanix Guest Tools sont installés.

Read More

HYCU Backup : le guide complet

Published: 4 avril 2025
Written by Julien D.
1 Comment
Categories: HYCU, Nutanix, Nutanix AHV FR, Sauvegarde
nutanix hycu

Ca y est, il est enfin complet ! Après une trentaine d’heures passées à installer, configurer, tester un environnement de labo et à rédiger chaque article, mon guide ultime sur la sauvegarde d’un cluster Nutanix à l’aide de la solution HYCU backup est enfin terminé.

Au total, cela représente :

  • 4500+ mots
  • 100+ captures d’écrans
  • 30+ heures de travail

Pour retrouver plus facilement l’ensemble de mes guides actuels ou à venir, j’ai créé un lien dédié dans le menu.

Au programme de ce guide complet :

Sauvegarder son cluster Nutanix avec HYCU – Présentation

Sauvegarder son cluster Nutanix avec HYCU – Pré-requis techniques

Sauvegarder son cluster Nutanix avec HYCU – Déployer le controleur HYCU

Sauvegarder son cluster Nutanix avec HYCU – Initialisation et configuration de base

Sauvegarder son cluster Nutanix avec HYCU – Ajout d’un cluster Nutanix

Sauvegarder son cluster Nutanix avec HYCU – Ajout d’une cible de sauvegardes

Sauvegarder son cluster Nutanix avec HYCU – Mettre à jour le controleur HYCU

Sauvegarder son cluster Nutanix avec HYCU – Création des jobs de sauvegarde

Sauvegarder son cluster Nutanix avec HYCU – Protection des machines virtuelles

Le guide évoluera probablement si je trouve d’autres éléments intéressant à partager pour étoffer mon retour d’expérience.

N’oubliez pas que la sécurité de vos données dépendra du temps que vous accorderez à la configuration de vos politiques de sauvegarde en amont.

N’hésitez pas à venir me faire part de vos interrogations, de vos craintes ou bien encore à demander à d’autres personnes qui ont déjà mis en place HYCU Backup afin qu’elles vous donnent leur retour d’expérience.

D’autres guides arrivent prochainement… Stay tuned !

Read More

Nutanix AHV : Déployer une VM Windows grâce aux VirtIO

Published: 3 avril 2025
Written by Julien D.
No comments
Categories: Community Edition FR, Nutanix, Nutanix AHV FR, Tutoriels, Tutoriels-AHV, Windows

C’est une problématique rencontrée par beaucoup de personnes lors de leur premier déploiement d’une machine virtuelle sous Microsoft Windows : la détection du stockage.

Je vais vous montrer comment procéder pour déployer une machine virtuelle Windows sur Nutanix AHV.

Pré-requis

Pour commencer, il faut récupérer l’image ISO des VirtIO sur le site Support de Nutanix (enregistrement sur le site nécessaire) : https://portal.nutanix.com/page/downloads?product=ahv

Pensez à sélectionner « VirtIO » dans le menu déroulant en haut de page puis téléchargez la version « Nutanix VirtIO for Windows (iso) » :

Une fois l’image ISO récupérée, il faut la transférer sur le cluster. Si vous ne savez pas comment procéder, je vous invite à consulter mon article à ce sujet : https://juliendumur.fr/nutanix-telecharger-une-image-sur-son-cluster/

Passons maintenant au déploiement de la machine virtuelle.

Création de la machine virtuelle sous Prism Element

Connectez vous à l’interface web Prism Element de votre cluster Nutanix, puis dans le menu sélectionnez « VM » :

Sur la page de gestion des machines virtuelles, cliquez sur « Create VM » en haut à droite :

Dans la fenêtre qui s’affiche, il y a un certain nombre de champs à remplir :

Dans l’ordre :

  • Nom de la machine virtuelle
  • Le fuseau horaire
  • La quantité de vCPU
  • La quantité de RAM

Ensuite, il faut ajouter un ou des disques :

Pour chaque type de disque que vous voudrez ajouter, il faudra sélectionner les options qui conviennent :

Dans le cas de notre VM, nous allons ajouter :

  • 1 disque de 40Go pour le système d’exploitation
  • 1 CD-ROM avec l’ISO Windows
  • 1 CD-ROM avec l’ISO contenant les VirtIO

Vous devriez avoir 3 disques à ce stade :

L’ajout d’un adaptateur réseau est la dernière étape avant de finaliser la création de la machine virtuelle :

Si vous ne savez pas comment ajouter de nouveaux réseaux sur votre cluster, je vous recommande de consulter mon article sur le sujet :

La machine est créée, vous pouvez passer à son déploiement.

Création de la machine virtuelle sous Prism Central

Pour créer la VM sous Prism Central, rendez vous dans le menu « Infrastructure > Compute > VMs » :

Cliquez ensuite sur « Create VM » pour accéder au menu de création de la VM :

Les champs à remplir restent globalement similaires à ceux que vous pouvez retrouver sous Prism Element, bien qu’organisés légèrement différemment :

Et répartis sur plusieurs onglets :

Le processus étant globalement identique, je ne vais pas redétailler toutes les étapes. Petite différence notable : la possibilité d’affecter dès la création une ou plusieurs catégories à notre VM :

Le dernier onglet permet de vérifier l’ensemble des informations que nous venons de paramétrer :

Déploiement de la machine virtuelle

Pour déployer la machine virtuelle, démarrez la et lancez la console. La première étape est de choisir la langue :

Cliquez ensuite sur « Installer maintenant » :

Puis sélectionnez la version que vous souhaitez installer :

Acceptez le contrat de licence :

Cliquez maintenant sur « Personnalisé… » :

Malheur ! Le disque dur que vous avez configuré lors de la création de la machine virtuelle n’apparait pas… Cliquez sur « Charger un pilote » afin de corriger ce problème :

Cliquez sur « Parcourir » :

Naviguez maintenant jusqu’au répertoire correspondant à la version de Windows que vous déployez, dans mon cas Windows Server 2022 :

Sélectionnez l’ensemble des pilotes de la liste et cliquez sur « Suivant » :

Une fois l’installation des pilotes terminées, le disque apparait enfin :

L’installation est lancée, il n’y a plus qu’à patienter :

Votre machine virtuelle est déployée !

Read More

Nutanix Foundation sur un Steamdeck ? Absolument !

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

Il y a quelques mois, je m’offrais un Steamdeck pour passer le temps durant ma convalescence après une opération du pied qui m’a cloué à mon canapé. Je vous avais déjà montré que l’on peut administrer un cluster depuis le Steamdeck et j’ai voulu pousser l’expérience un peu plus loin…

Le multi-boot sur le Steamdeck

Pour rendre l’exécution de Foundation for Windows possible sur le Steam deck, il a fallut que je trouve une solution pour faire tourner un Windows 11 à la place du SteamOS nativement embarqué.

Pour réaliser l’opération, j’avais plusieurs options :

  • remplacer le système d’exploitation embarqué pour passer de SteamOS à Windows 11 mais cela me rajoutait énormément de contraintes pour pouvoir jouer sur la console à mes jeux Steam
  • mettre en place un système de multi-boot avec un disque externe sur lequel j’aurai installé un Windows 11 mais cela faisait un périphérique possiblement encombrant à trimballer…

L’objectif étant d’avoir une solution de boot additionnelle pour mon Steamdeck afin de pouvoir expérimenter Windows sur la machine dans diverses situations sans avoir à supprimer le système d’exploitation embarqué nativement, j’ai opté pour la deuxième option et je me suis mis en quête d’un disque externe qui ferait l’affaire.

En parcourant Internet, je suis finalement tombé sur un projet Kickstarter « Genki SavePoint » : https://www.kickstarter.com/projects/humanthings/genki-savepoint?lang=fr

Le Genki Savepoint est un boîtier pour mini SSD conçu pour une utilisation portable. Sur le papier, voici les promesses du boitier :

  • Compatible SSD M.2 2230
  • Capacité max de 2Tb
  • Vitesse de transfert de 10Gb/s
  • Chargement 100w
  • Dissipateur de chaleur intégré
  • Condensateur de protection intégré

Je me suis donc empressé de soutenir le projet en commandant 2 boitiers que j’ai fini par recevoir après quelques semaines d’attentes. J’y ai ajouté un SSD M.2 2230 de 1Tb pour pouvoir avoir un espace suffisant quelle que soit l’utilisation que j’en aurai…

Exit SteamOS, bonjour Windows 11 !

Une fois le boitier et le SSD reçus, j’ai procédé au montage du SSD dans le boitier et pour cela, il suffit de dévisser le dissipateur pour révéler le connecter M.2 et pouvoir insérer le SSD. Une fois connecté à l’ordinateur, le boitier est détecté comme un disque dur externe.

Il m’a fallu maintenant préparer le SSD en installant un Windows 11 dessus à l’aide de Rufus. Je ne vais pas détailler le processus ici puisque le constructeur du boitier s’en est chargé ici : https://www.genkithings.com/blogs/blog/installing-windows-on-savepoint

Une fois Windows 11 installé, j’ai téléchargé l’ensemble des drivers disponibles (https://help.steampowered.com/fr/faqs/view/6121-ECCD-D643-BAA8) et les différents logiciels que je souhaitais installer ensuite (dont Foundation for Windows) et je les ai mis en prévision sur le disque. Les choses sérieux pouvaient commencer…

Installation de Nutanix Foundation

Au premier démarrage sur le boitier, il a fallut évidemment que je fasse toute la configuration du système d’exploitation et que j’installe l’ensemble des drivers préalablement installés.

Ensuite, le déploiement de Foundation sur le Steamdeck est simple puisqu’il m’a suffit d’exécuter le fichier que j’avais téléchargé sur le site officiel (https://portal.nutanix.com/page/downloads?product=foundation).

Une fois l’installation terminée, j’ai ouvert le navigateur internet et j’ai ouvert l’adresse http://locahost:8000/gui/index.html pour accéder à l’interface de Nutanix Foundation :

Sans surprise, Foundation for Windows tourne impeccable sur le Steamdeck, mais quid d’un déploiement sans port réseau RJ45 embarqué ? Pour répondre à cette problématique, il m’a suffit de faire l’acquisition d’un mini dock USB-C avec :

  • 1 RJ45
  • 3 USB2
  • 1 USB-C
  • 2 HDMI

A ce stade, le Steamdeck est « Foundation Ready » et prêt à déployer des clusters. Toutefois, la dernière question qui reste en suspend est la suivante : est ce que cela fonctionne ? En toute honnêteté, je n’en sais rien car malheureusement je n’ai pas eu de cluster à disposition me permettant faire un test grandeur nature, mais dès que l’occasion se présentera ce sera fait !

Read More