foundation

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

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 !

Team Leader - Nutanix Technology Champion - Nutanix NTC Storyteller

Nutanix : Foundation d’un cluster avec le Steamdeck

Préparation du matériel en vue du Foundation

Nutanix Foundation d’un noeud avec un Steamdeck

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