Dans cet article, je vous partage mon retour d’expérience complet sur la réinstallation complète d’un cluster Nutanix chez OVHcloud.
Une fois connecté à l’interface de gestion OVHcloud, se rendre dans « Hosted Private Cloud » :
Dans le menu déroulant de gauche, cliquez sur le cluster que vous souhaitez redéployer :
Sur la page qui s’affiche, cliquez sur « Redéployer mon cluster » :
Cliquez sur « Continuer » :
Redéploiement automatique
La première option consiste à reprendre les paramètres par défaut fournis par OVHcloud pour réinstaller complètement le cluster dans sa configuration de base :
Un récapitulatif des paramètres s’affiche avant que vous ne validiez pour de bon la réinstallation de votre cluster :
Redéploiement personnalisé
Il est possible de personnaliser entièrement la configuration du réseau IP de votre cluster lors de sa phase d’installation. Lors du choix de la méthode de déploiement du cluster, sélectionnez « Personnaliser la configuration » et cliquez sur « Suivant » :
Renseignez les différents champs avec les informations que vous souhaitez attribuer à votre cluster et cliquez sur « Redéployer » :
Saisissez « REDEPLOY » dans le champ prévu à cet effet et cliquez sur « Confirmer » pour lancer la procédure de réinstallation :
Sur la page générale de votre cluster, un message indique que le redéploiement du cluster est en cours :
Il ne reste plus qu’à patienter jusqu’à ce que le cluster soit complètement redéployé. L’ensemble des configurations de base sont déjà réalisées, il ne vous reste plus qu’à finaliser les spécifiques tels que l’authentification, le relais smtp, la supervision…
Dans ce nouvel article, nous allons aborder la gestion des containers de stockage via les commandes CLI sur vos clusters Nutanix…
L’ensemble des commandes présentes dans cet article sont à exécuter depuis une des CVMs du cluster et fonctionnent sur un cluster en AOS 6.10+.
Vérifier l’état des containers
Pour vérifier l’état de vos containers de stockage, la commande la plus simple est la suivante :
ncli container list
Cette commande vous permettra d’afficher l’ensemble des informations relatives à tous les containers de votre cluster.
Si vous souhaitez afficher un container en particulier, vous pouvez passer le nom (méthode la plus simple) ou l’ID de votre container si vous l’avez en paramètre :
ncli container list name=NAME
ncli container list id=ID
Enfin, une dernière commande pour n’afficher que les statistiques d’utilisation de vos containers :
ncli container list-stats
Renommer un container
Pour renommer un container de stockage, il est impératif qu’il soit totalement vide.
ATTENTION : il existe 2 containers créés par défaut lors du déploiement votre cluster, « SelfServiceContainer » et « NutanixManagementShare ». Il ne faut pas tenter de les renommer !
Créer un container
Il est également possible de créer des containers de stockage en CLI :
Le paramètre « name » et le « sp-name » sont les seuls paramètres obligatoires lors de l’exécution de la commande. Cela vous permettra de créer un container de base sur le storage pool choisi avec les paramètres suivants :
pas de mécanisme d’optimisation de la donnée
pas de restriction / réservation
le replication factor par défaut
Mais la commande de création d’un container peut s’avérer très pratique si vous devez créer des containers de stockage par lot, par exemple si vous hébergez plusieurs clients sur un cluster avec chacun une quantité d’espace de stockage allouée !
Par exemple, pour créer un container de stockage avec comme paramètres :
Un container avec les caractéristiques associées sera alors créé :
Modifier les paramètres d’un container
Un container existant peut également être modifié. Vous pouvez a peu prêt tout modifier au niveau des paramètres, des mécanismes d’optimisation de la donnée, aux tailles réservées / allouées, réplication factor…
Pour l’ensemble des paramètres, je vous invite à consulter la documentation officielle (lien en bas de page).
Supprimer un container
Supprimer un container est assez simple mais nécessite que l’ensemble des fichiers stockés dessus soient au préalable supprimés ou déplacés. La suppression se fait via la commande suivante :
ncli container remove name=NAME
Il peut arriver que malgré la suppression ou le déplacement des vdisks de vos VMs, la suppression vous soit toujours refusée. C’est souvent dû à de petits fichiers résiduels.
Il faut alors ajoute le paramètre « ignore-small-files » pour forcer la suppression :
ATTENTION : il existe 2 containers créés par défaut lors du déploiement votre cluster, « SelfServiceContainer » et « NutanixManagementShare ». Il ne faut pas tenter de les supprimer !
Dans ce nouvel article, nous allons maintenant voir comment les commandes CLI peuvent nous aider à à créer ou à modifier les réseaux de notre cluster Nutanix…
L’ensemble des commandes de cet article sont à exécuter au niveau d’une des CVMs du cluster.
Création d’un subnet non managé sur Nutanix AHV
Pour créer un nouveau subnet non managé (sans IPAM) à l’échelle du cluster AHV, la commande est vraiment très simple :
acli net.create NAME vlan=VLAN_ID
Il faut remplacer :
NAME par le nom que vous souhaitez attribuer à votre subnet
VLAN_ID par l’ID du VLAN
Voici un exemple de commande qui permet de créer le vlan « NUTANIX » avec comme vlan id « 84 » :
acli net.create NUTANIX vlan=84
Par défaut, le vlan sera créé sur le vswitch « vs0 » mais si vous souhaitez le créer sur un autre virtual switch, vous pouvez le spécifier en paramètre :
acli net.create NAME vlan=VLAN_ID virtual_switch=VSWITCH
Il faut dans ce cas remplacer :
NAME par le nom que vous souhaitez attribuer à votre subnet
VLAN_ID par l’ID du VLAN
VSWITCH par le nom du bridge sur lequel vous voulez créer le subnet
Voici un exemple de commande qui permet de créer le vlan « NUTANIX » avec comme vlan id « 84 » sur le vswitch « vs0 » :
Vous pouvez ensuite lancer la commande « acli net.list » et vérifier que votre nouveau subnet apparait bien dans la liste.
Création d’un subnet managé sur Nutanix AHV
Cette commande permet de créer un nouveau subnet managé (avec IPAM) à l’échelle du cluster AHV avec les options de base de passerelle et masque de sous réseau.
acli net.create NAME vlan=VLAN_ID virtual_switch=vs0 ip_config=GATEWAY/MASK
Il faut remplacer :
NAME par le nom que vous souhaitez attribuer à votre subnet
VLAN_ID par l’ID du VLAN
vs0 par le nom du bridge sur lequel vous voulez créer le subnet
GATEWAY par l’adresse IP de la passerelle du subnet
MASK par le masque de sous réseau
Voici un exemple de commande qui permet de créer le vlan « NUTANIX » avec un vlan id « 84 » sur le vswitch « vs0 », avec une adresse de passerelle « 10.0.84.254 » sur le réseau « 10.0.84.0/24 » :
Pour supprimer un subnet existant sur un cluster Nutanix AHV, rien de plus simple ! Il suffit de lancer la commande suivante :
acli net.delete NAME
Il faut remplacer NAME par le nom du subnet que vous souhaitez supprimer, ce qui donnerai par exemple pour le subnet précédemment créé :
acli net.delete NUTANIX
Rien de plus simple !
Création / Suppression de subnets en masse
Afin de me faciliter la tâche lors de l’import de grandes quantités de subnets, j’ai créé plusieurs fichiers CSV que je peux ensuite convertir en liste de commandes afin de créer à la chaine de multiples subnets.
Que vous ayez besoin de réaliser des opérations particulières ou répétitives, faire du troubleshooting ou d’avoir une vu plus détaillée, les commandes CLI d’un cluster Nutanix seront vos meilleures alliées.
Dans cet article, je vous propose un condensé des meilleures commandes permettant de réaliser toutes les vérifications de la configuration réseau d’un cluster Nutanix, que ce soit au niveau du cluster, des hôtes, des CVMs ou encore des machines virtuelles…
Vous devez avoir un cluster sous AOS 6.10+ pour éxecuter certaines des commandes de ce guide.
A. Via les commandes Nutanix acli depuis n’importe quelle CVM du cluster Nutanix AHV
Lister l’état des interfaces des hosts :
acli net.list_host_nic 192.168.84.11 @IP_HOST_AHV
Résultat :
Lister tous les vSwitchs actuellement configurés sur le cluster :
acli net.list_virtual_switch
Résultat :
Vous pouvez lister la configuration d’un vSwitch en particulier en le passant en argument de la commande :
acli net.list_virtual_switch vs1
Lister tous les subnets créés sur le cluster :
acli net.list
Résultat :
Lister les VMs rattachées à un subnet en particulier :
acli net.list_vms SUBNET
B. Via le script Nutanix manage_ovs depuis n’importe quelle CVM du cluster Nutanix AHV
Lister l’état des interfaces d’un host AHV :
manage_ovs show_interfaces
Résultat :
Vous pouvez également lister l’état des interfaces de l’ensemble des hôtes du cluster :
allssh "manage_ovs show_interfaces"
Lister l’état des uplinks (bond) d’un host AHV :
manage_ovs show_uplinks
Résultat :
Vous pouvez également lister l’état des uplinks (bond) de tous les hôtes AHV du cluster :
allssh "manage_ovs show_uplinks"
Afficher les informations LLDP des interfaces d’un host AHV :
manage_ovs show_lldp
Résultat :
Vous pouvez également afficher les informations LLDP des interfaces de tous les hôtes AHV du cluster :
allssh "manage_ovs show_lldp"
Afficher les bridges actuellement créés sur un host AHV :
manage_ovs show_bridges
Résultat :
Vous pouvez également afficher les bridges actuellement créés sur tous les hôtes AHV du cluster :
allssh "manage_ovs show_bridges"
Afficher le mappage des interfaces de la CVM avec celles des hosts AHV :
manage_ovs show_cvm_uplinks_map
Résultat :
Vous pouvez également afficher le mappage des interfaces des CVM sur tous les hôtes AHV du cluster :
allssh "manage_ovs show_cvm_uplinks_map"
C. Via la commande Open vSwitch depuis n’importe quel hote d’un cluster Nutanix AHV
Lister les bridges existants d’un host AHV :
ovs-vsctl list-br
Résultat :
Lister toutes les interfaces attachées à un bridge en particulier d’un host AHV :
ovs-vsctl list-ifaces br0
Résultat :
Afficher la configuration d’un port bond d’un host AHV :
ovs-vsctl list port br0-up
Résultat :
Afficher la configuration et l’état d’un bond sur un host AHV :
ovs-appctl bond/show br0-up
Résultat :
Afficher des informations sur l’état d’un bond configuré en LACP sur un host AHV :
ovs-appctl lacp/show br1-up
Un grand merci à Yohan pour l’idée d’article et le coup de main !
La nouvelle version des VirtIO est disponible et voici les nouveautés et corrections de bugs !
Nouveautés
Le pilote QEMU « null » a été remplacé par un périphérique FwCfg entièrement fonctionnel, permettant la collecte des vidages mémoire des machines virtuelles Windows directement sur les hôtes AHV.
Ajout d’un nouveau bouton de configuration : vous pouvez désormais ajuster le nombre de requêtes d’E/S traitées avant de réessayer lorsque la file d’attente virtuelle est pleine, ce qui vous offre un meilleur contrôle sur le comportement des E/S.
Correction de bugs
Correction d’un problème gênant qui provoquait le blocage des machines virtuelles Windows après le démontage du disque. Les opérations seront fluides à partir de maintenant.
Bon à savoir
Cette nouvelle version est entièrement compatible avec toutes les versions AOS et AHV prises en charge.
Dans un de mes précédents articles, je vous avais parlé de mon installation de Nutanix Foundation sur mon Steamdeck. Malheureusement, je n’avais pas encore eu l’opportunité de pouvoir lancer une installation avec le setup faute de serveur à imager.
Mais les choses ont changé car j’ai depuis peu en ma possession un serveur Supermicro SuperServer 5019D-FN8TP ! J’ai d’ailleurs rédigé un article sur la mise en oeuvre de Nutanix Foundation sur un matériel non officiellement supporté :
Pour pouvoir espérer imager mon noeud avec Nutanix Foundation depuis mon Steamdeck, il fallait impérativement que je sois connecté au réseau en RJ45, un type de connectique absent de la console de Valve…
J’ai donc fait l’acquisition d’un dock externe disposant de plusieurs ports USB et d’un port RJ45 connectable en USB-C.
J’ai réalisé les branchements suivants :
connexion du dock externe sur le port USB-C du Steamdeck
connexion de l’alimentation sur le port USB-C du dock prévu à cet effet
connexion du cable réseau sur le port RJ45 du dock
connexion du disque SSD externe (sur lequel est installé Windows) sur un des ports USB du dock
Cela m’a permis de faire booter le Steamdeck sur le SSD pour démarrer sous Windows 11 !
Nutanix Foundation d’un noeud avec un Steamdeck
Comme je vous en avait parlé dans le précédent article, j’ai déjà Nutanix Foundation installé donc je ne vais pas m’étendre sur cette partie là et passer directement à la partie Foundation !
Pour ce Foundation, j’ai utilisé la toute dernière version disponible à savoir la Foundation 5.9 avec les versions AOS 7 et AHV 10 !
Le processus de Foundation démarre impeccablement bien comme attendu et le processus arrive à son terme après un certains temps :
Comme vous pouvez le constater, imager un noeud avec le Steamdeck c’est possible ! Est ce que c’est pertinent ? Aucune certitude mais je peux au moins dire que « je l’ai fait ! ».
Cession à un tiers ou réutilisation du cluster pour un autre usage, il arrive parfois qu’il faille détruire un cluster Nutanix. Voici la marche à suivre pour y parvenir…
Préparation du cluster pour la destruction
Avant de pouvoir procéder à la destruction d’un cluster, il est nécessaire de réaliser quelques préparatifs.
Parmi les prérequis nécessaires, il est impératif qu’il n’y ai plus de machine virtuelle allumée sur le cluster. Veillez à migrer / éteindre / supprimer (au choix) l’ensemble des machines virtuelles sur le cluster.
Note : l’ensemble des commandes de cet article sont à saisir sur une des CVM du cluster.
Une fois que ce prérequis est rempli, on commence par vérifier le statut du cluster :
cluster status
Vous devriez obtenir un retour tel que celui ci :
nutanix@NTNX-5f832032-A-CVM:192.168.84.22:~$ cluster status
2025-07-24 07:20:18,663Z INFO MainThread zookeeper_session.py:136 Using multithreaded Zookeeper client library: 1
2025-07-24 07:20:18,666Z INFO MainThread zookeeper_session.py:248 Parsed cluster id: 4439894058604263884, cluster incarnation id: 1753169113232129
2025-07-24 07:20:18,666Z INFO MainThread zookeeper_session.py:270 cluster is attempting to connect to Zookeeper, host port list zk1:9876
2025-07-24 07:20:18,676Z INFO Dummy-1 zookeeper_session.py:840 ZK session establishment complete, sessionId=0x198310781ce5e38, negotiated timeout=20 secs
2025-07-24 07:20:18,678Z INFO MainThread cluster:3303 Executing action status on SVMs 192.168.84.22
2025-07-24 07:20:18,682Z INFO Dummy-2 zookeeper_session.py:940 Calling c_impl.close() for session 0x198310781ce5e38
2025-07-24 07:20:18,683Z INFO Dummy-2 zookeeper_session.py:941 Calling zookeeper_close and invalidating zhandle
The state of the cluster: start
Lockdown mode: Disabled
CVM: 192.168.84.22 Up, ZeusLeader
Xmount UP [459073, 459235, 459236, 459311]
IkatProxy UP [458789, 458917, 458918, 458919]
Zeus UP [454133, 454189, 454190, 454191, 454201, 454218]
Scavenger UP [459084, 459296, 459297, 459298]
SysStatCollector UP [464017, 464089, 464090, 464091]
IkatControlPlane UP [464039, 464218, 464219, 464220]
SSLTerminator UP [464170, 464323, 464324]
SecureFileSync UP [464362, 464646, 464647, 464648]
Medusa UP [468604, 469223, 469224, 469395, 470062]
DynamicRingChanger UP [476814, 476897, 476898, 476920]
Pithos UP [476843, 477058, 477060, 477086]
InsightsDB UP [476918, 477131, 477132, 477155]
Athena UP [477152, 477270, 477271, 477273]
Mercury UP [513735, 513803, 513804, 513808]
Mantle UP [477391, 477551, 477552, 477562]
VipMonitor UP [485663, 485664, 485665, 485666, 485670]
Stargate UP [477857, 477995, 477996, 477997, 477998]
InsightsDataTransfer UP [478768, 478929, 478930, 478934, 478935, 478936, 478937, 478938, 478939]
GoErgon UP [478834, 479020, 479021, 479039]
Cerebro UP [478950, 479138, 479139, 479306]
Chronos UP [479088, 479286, 479287, 479310]
Curator UP [479234, 479406, 479407, 483968]
Prism UP [479436, 479600, 479601, 479650, 480643, 480885]
Hera UP [479602, 479917, 479918, 479919]
AlertManager UP [479860, 480436, 480438, 480555]
Arithmos UP [480751, 481566, 481567, 481765]
Catalog UP [481670, 482699, 482700, 482701, 483502]
Acropolis UP [483575, 484493, 484494, 488301]
Castor UP [484403, 484877, 484878, 484911, 484972]
Uhura UP [484912, 485066, 485067, 485300]
NutanixGuestTools UP [485132, 485254, 485255, 485284, 485611]
MinervaCVM UP [491046, 491263, 491264, 491265]
ClusterConfig UP [491188, 491361, 491362, 491363, 491381]
APLOSEngine UP [491374, 491650, 491651, 491652]
APLOS UP [495252, 496063, 496064, 496065]
PlacementSolver UP [497033, 497330, 497331, 497332, 497341]
Lazan UP [497256, 497568, 497569, 497570]
Polaris UP [498016, 498620, 498621, 498911]
Delphi UP [498765, 499238, 499239, 499240, 499332]
Security UP [500506, 501578, 501579, 501581]
Flow UP [501478, 502168, 502169, 502171, 502178]
Anduril UP [510708, 511248, 511249, 511252, 511335]
Narsil UP [502382, 502472, 502473, 502474]
XTrim UP [502488, 502629, 502630, 502631]
ClusterHealth UP [502656, 502774, 503156, 503158, 503166, 503174, 503183, 503351, 503352, 503359, 503384, 503385, 503396, 503401, 503402, 503420, 503421, 503444, 503445, 503468, 503469, 503474, 503752, 503753, 503785, 503786, 503817, 503818, 528495, 528533, 528534, 530466, 530467, 530468, 530469, 530474, 530475, 530488, 530512, 530522, 530571, 530576, 530684, 530773, 530791, 531349, 531357]
2025-07-24 07:20:20,740Z INFO MainThread cluster:3466 Success!
Comme le cluster est actuellement démarré, je dois d’abord le stopper avec la commande suivante :
cluster stop
Attention, pour pouvoir arrêter le cluster, il ne doit plus rester aucune machine virtuelle allumée sur le cluster à l’exception de la CVM.
La commande va arrêter le cluster et les services associés après que vous ayez confirmé l’opération par « I agree » et devrait vous renvoyer ce type de résultat :
The state of the cluster: stop
Lockdown mode: Disabled
CVM: 192.168.84.22 Up, ZeusLeader
Xmount UP [1761344, 1761418, 1761419, 1761475]
IkatProxy UP [458789, 458917, 458918, 458919]
Zeus UP [454133, 454189, 454190, 454191, 454201, 454218]
Scavenger UP [459084, 459296, 459297, 459298]
SysStatCollector DOWN []
IkatControlPlane DOWN []
SSLTerminator DOWN []
SecureFileSync DOWN []
Medusa DOWN []
DynamicRingChanger DOWN []
Pithos DOWN []
InsightsDB DOWN []
Athena DOWN []
Mercury DOWN []
Mantle DOWN []
VipMonitor UP [485663, 485664, 485665, 485666, 485670]
Stargate DOWN []
InsightsDataTransfer DOWN []
GoErgon DOWN []
Cerebro DOWN []
Chronos DOWN []
Curator DOWN []
Prism DOWN []
Hera DOWN []
AlertManager DOWN []
Arithmos DOWN []
Catalog DOWN []
Acropolis DOWN []
Castor DOWN []
Uhura DOWN []
NutanixGuestTools DOWN []
MinervaCVM DOWN []
ClusterConfig DOWN []
APLOSEngine DOWN []
APLOS DOWN []
PlacementSolver DOWN []
Lazan DOWN []
Polaris DOWN []
Delphi DOWN []
Security DOWN []
Flow DOWN []
Anduril DOWN []
Narsil DOWN []
XTrim DOWN []
ClusterHealth DOWN []
2025-07-24 07:23:57,716Z INFO MainThread cluster:2194 Cluster has been stopped via 'cluster stop' command, hence stopping all services.
2025-07-24 07:23:57,716Z INFO MainThread cluster:3466 Success!
Nous pouvons maintenant passer à la destruction du cluster.
Destruction du cluster
La destruction du cluster nécessite l’exécution de la commande suivante :
cluster destroy
Le système vous demandera ensuite une confirmation avant de procéder à la suppression de l’ensemble des configurations et données :
2025-07-24 07:35:45,898Z INFO MainThread zookeeper_session.py:136 Using multithreaded Zookeeper client library: 1
2025-07-24 07:35:45,900Z INFO MainThread zookeeper_session.py:248 Parsed cluster id: 4439894058604263884, cluster incarnation id: 1753169113232129
2025-07-24 07:35:45,900Z INFO MainThread zookeeper_session.py:270 cluster is attempting to connect to Zookeeper, host port list zk1:9876
2025-07-24 07:35:45,916Z INFO Dummy-1 zookeeper_session.py:840 ZK session establishment complete, sessionId=0x198310781ce5e6e, negotiated timeout=20 secs
2025-07-24 07:35:45,918Z INFO Dummy-2 zookeeper_session.py:940 Calling c_impl.close() for session 0x198310781ce5e6e
2025-07-24 07:35:45,918Z INFO Dummy-2 zookeeper_session.py:941 Calling zookeeper_close and invalidating zhandle
2025-07-24 07:35:45,921Z INFO MainThread cluster:3303 Executing action destroy on SVMs 192.168.84.22
2025-07-24 07:35:45,922Z WARNING MainThread genesis_utils.py:348 Deprecated: use util.cluster.info.get_node_uuid() instead
2025-07-24 07:35:45,928Z INFO MainThread cluster:3350
***** CLUSTER NAME *****
Unnamed
This operation will completely erase all data and all metadata, and each node will no longer belong to a cluster. Do you want to proceed? (Y/[N]): Y
L’opération de destruction du cluster prend quelques minutes durant lesquelles l’ensemble des données encore présentes vont être complètement effacées.
Une fois la destruction du cluster terminée, un « cluster status » vous permettra de vérifier qu’AHV est en attente de création du cluster :
nutanix@NTNX-5f832032-A-CVM:192.168.84.22:~$ cluster status
2025-07-24 07:42:50,694Z CRITICAL MainThread cluster:3242 Cluster is currently unconfigured. Please create the cluster.
Voilà, votre cluster est détruit et il ne vous reste plus qu’à le recréer.
Pour ceux qui préfèrent suivre la procédure en vidéo, voici ma vidéo YouTube associée :
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 :
Le disque à 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 a 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…
Nutanix X-Ray est un outil de test et de benchmarking conçu par Nutanix pour évaluer les performances et la résilience des infrastructures hyperconvergées (HCI). Il permet ainsi aux entreprises de simuler des charges de travail réelles et de tester la robustesse de leurs infrastructures avant leur déploiement en production.
Pourquoi utiliser Nutanix X-Ray ?
La première raison d’utiliser X-Ray est d’évaluer les performances avant un déploiement. En effet, avant de mettre en production une infrastructure hyperconvergée, il est essentiel de s’assurer qu’elle répond aux exigences de performances qui ont été définies en amont du projet.
Nutanix X-Ray répond à cette première problématique en proposant des scénarios concrets permettant de :
Simuler des charges de travail réelles, comme celles d’un data center ou d’un environnement cloud hybride.
Mesurer les performances en termes d’IOPS, de latence et de débit.
Identifier les éventuels goulets d’étranglement et les points d’amélioration.
Grâce à ces tests, les entreprises peuvent valider leurs choix technologiques avant d’investir massivement dans une solution HCI.
La seconde raison d’utiliser X-Ray est de tester la résilience d’un cluster, une caractéristique cruciale pour éviter les interruptions de service. Avec Nutanix X-Ray, il est ainsi possible de :
Simuler des pannes de nœuds, de disques ou de réseau pour voir comment l’infrastructure réagit.
Tester les mécanismes de basculement et de reprise après incident (failover).
Mesurer le temps nécessaire pour rétablir un service en cas de défaillance.
Ces tests aident à garantir une haute disponibilité et une continuité de service même en cas de problème majeur une fois le cluster en production.
X-Ray permet également de comparer plusieurs infrastructures HCI et de choisir la plus adaptée en fonction des besoins. Pour cela, il permet de réaliser :
Des benchmarks comparatifs entre différentes solutions (ex : Nutanix vs VMware vSAN).
Une analyse neutre et impartiale des performances.
Une meilleure compréhension des forces et faiblesses de chaque infrastructure.
Les résultats alors collectés vont permettre aux entreprises de prendre les bonnes décisions concernant l’évolution ou le remplacement de leur infrastructure.
Les résultats fournis par X-Ray vont également permettre de faciliter l’optimisation des environnements HCI en :
Ajustant les configurations pour maximiser la performance.
Identifiant les améliorations possibles au niveau du stockage, du réseau et du CPU.
Planifiant les évolutions de l’infrastructure en fonction des besoins futurs.
L’outil aide ainsi à réduire les coûts et à améliorer l’efficacité opérationnelle en réduisant les erreurs de dimensionnement ou de choix technologique.
Vous l’aurez compris, Nutanix X-Ray est un outil indispensable pour toute entreprise souhaitant tester, comparer et optimiser son infrastructure HCI avant et après son déploiement.
Dans le prochain article, je vous exposerais la mise en service de l’outil sur un cluster Nutanix.
Je suis intervenu chez un client qui a une grande quantité de noeuds assez anciens en production sur ses sites distants. Malheureusement, il est face à une problématique pour réaliser des installations d’AOS et AHV dessus car le matériel n’est pas officiellement supporté par Nutanix. Ayant récupéré quelques noeuds identiques, je me suis penché sur le problème pour trouver une solution…
Ils sont parfaits pour réaliser des homelabs avec leur forme factor 1U et en demi profondeur, ils peuvent s’intégrer à n’importe quelle baie domestique.
2 SSD de 1Tb (possibilité d’en ajouter 2 supplémentaires)
4 ports RJ45 1G
2 ports RJ45 10G
2 ports SFP 10G
1 port RJ45 dédié à l’IPMI
1 carte graphique NVidia Tesla P40
Je vous ai dit que ces noeuds étaient parfait pour du homelab ?
Premiers tests de foundation
Pour mes premiers tests de Foundation, j’ai choisi de partir avec une très vieille version de Foundation : la 4.6.
Niveau logiciel, je suis également partis sur une vieillerie avec une version 5.5.9.5 et l’AHV fourni dans le package. La plupart des noeuds du client tournant également sur de vieilles versions, je me suis dit que cela devrait passer.
Premier échec… d’une longue série !
J’ai testé plein de combinaisons possibles avec des Foundation en 4.6 / 5.0 / 5.4 / 5.9, des AOS en 5.5.9.5 / 5.6.1 / 5.20 / 6.10, AHV en bundle, pas en bundle… et même une image custom de Phoenix générée depuis un des noeuds récupérés… Et absolument aucun succès, avec souvent des messages d’erreurs qui différaient en fonction des combinaisons réalisées.
Mais un message revenait tout de même plus fréquemment que les autres…
La vérification de la compatibilité matérielle
Lors du processus de Foundation, il y a une étape durant laquelle le système Phoenix génère un fichier d’état de la configuration matérielle du ou des noeuds que l’on souhaite imager : le hardware_config.json.
Une fois ce fichier généré, Foundation le compare à sa liste de matériels connus pour vérifier qu’il s’agit d’un noeud qu’il est capable d’imager… Et c’est là qu’apparait mon problème :
2025-06-17 11:55:58,642Z foundation_tools.py:1634 INFO Node with ip 192.168.84.22 is in phoenix. Generating hardware_config.json
2025-06-17 11:55:58,942Z foundation_tools.py:1650 DEBUG Running command .local/bin/layout_finder.py local
2025-06-17 11:56:02,383Z foundation_tools.py:334 ERROR Command '.local/bin/layout_finder.py local' returned error code 1
stdout:
stderr:
Traceback (most recent call last):
File "/root/.local/bin/layout_finder.py", line 297, in <module>
write_layout("hardware_config.json", 1)
File "/root/.local/bin/layout_finder.py", line 238, in write_layout
top = get_layout(node_position)
File "/root/.local/bin/layout_finder.py", line 130, in get_layout
vpd_info = vpd_info_override or get_vpd_info(system_info_override)
File "/root/.local/bin/layout_finder.py", line 249, in get_vpd_info
module, model, model_string, hardware_id = _find_model_match(
File "/root/.local/bin/layout_finder.py", line 78, in _find_model_match
raise exceptions[0]
__main__.NoMatchingModule: Raw FRU: FRU Device Description : Builtin FRU Device (ID 0)
Chassis Type : Other
Chassis Part Number : CSE-505-203B
Chassis Serial : C5050LH47NA0950
Board Mfg Date : Wed Oct 31 16:00:00 2018
Board Mfg : Supermicro
Board Serial : ZM18AS036679
Board Part Number : X11SDV-8C-TP8F
Product Manufacturer : Supermicro
Product Name :
Product Part Number : SYS-5019D-FN8TP-1-NI22
Product Version :
Product Serial : S348084X9211699
Product Name: SYS-5019D-FN8TP-1-NI22
Unable to match system information to layout module. Please refer KB-7138 to resolve the issue.
Trop aimable, Foundation m’indique qu’il existe une KB car visiblement c’est un problème récurrent !
La commande va interroger l’ipmi et remonter les informations concernant le matériel :
Getting FRU ... Chassis Type (CT) = Other (01h) Chassis Part Number (CP) = CSE-505-203B Chassis Serial Number (CS) = XXXXXXXXXXXXXXX Board mfg. Date/Time (BDT) = 2018/10/31 16:00:00 (A0 3E B7) Board Manufacturer Name (BM) = Supermicro Board Product Name (BPN) = Board Serial Number (BS) = XXXXXXXXXXXX Board Part Number (BP) = X11SDV-8C-TP8F Board FRU File ID = Product Manufacturer Name (PM) = Supermicro Product Name (PN) = Product PartModel Number (PPM) = SYS-5019D-FN8TP-1-NI22 Product Version (PV) = Product Serial Number (PS) = XXXXXXXXXXXXXXX Product Asset Tag (PAT) = Product FRU File ID =
Il est ensuite possible d’éditer chacun des éléments via différentes commandes avec notamment par exemple :
Evidemment, je remplace « param » avec le paramètre désiré. Maintenant que j’ai une technique pour « mentir » au système, je dois trouver un bon mensonge…
A la recherche du modèle perdu…
La problématique dans notre cas, c’est d’avoir un FRU qui corresponde à un matériel de la liste de compatibilité intégrée à Phoenix…
J’ai testé à la chance avec des matériels approchant en remplaçant le PPM existant :
SYS-5019D-FN8TP-1-NI22 (celui d’origine
X11SDV-8C-TP8F (c’est ce modèle qui est reconnu sur Nutanix sur les noeuds du client)
NX-1120S-G7
NX-1065-G7
Le premier n’est pas reconnu lors du processus de Foundation, idem pour le second. Pour les 2 suivants, ils sont bien reconnu mais c’est un message d’erreur légèrement différent qui s’affiche…
stderr:
Traceback (most recent call last):
File "/root/.local/bin/layout_finder.py", line 297, in
write_layout("hardware_config.json", 1)
File "/root/.local/bin/layout_finder.py", line 238, in write_layout
top = get_layout(node_position)
File "/root/.local/bin/layout_finder.py", line 146, in get_layout
module.populate_layout(layout_api, layout_api.discovery_info, layout,
File "/root/.local/lib/python3.9/site-packages/layout/modules/smc_gen11_4node.py", line 104, in populate_layout
data_hbas = api.find_devices(pci_ids=["1000:0097"], min_=1, max_=1,
File "/root/.local/lib/python3.9/site-packages/layout/layout_api.py", line 300, in find_devices
raise Exception(msg)
Exception: This node is expected to have exactly 1 SAS3008. But phoenix could not find any such device
2025-06-17 12:22:11,405Z imaging_step.py:123 DEBUG Setting state of ) @c2b0> from RUNNING to FAILED
2025-06-17 12:22:11,409Z imaging_step.py:123 DEBUG Setting state of ) @ca90> from PENDING to NR
2025-06-17 12:22:11,410Z imaging_step.py:182 WARNING Skipping ) @ca90> because dependencies not met, failed tasks: [) @c2b0>]
2025-06-17 12:22:11,412Z imaging_step.py:123 DEBUG Setting state of ) @c940> from PENDING to NR
2025-06-17 12:22:11,413Z imaging_step.py:182 WARNING Skipping ) @c940> because dependencies not met
2025-06-17 12:22:11,413Z imaging_step.py:123 DEBUG Setting state of ) @c2e0> from PENDING to NR
2025-06-17 12:22:11,414Z imaging_step.py:182 WARNING Skipping ) @c2e0> because dependencies not met
Le modèle de noeud est reconnu par le processus Foundation mais il y a également une vérification de la configuration matérielle du noeud ! Par conséquent, trouver un modèle approchant n’est pas suffisant, il faut impérativement que le modèle ET la configuration matérielle soient similaires…
Mais comment trouver le bon modèle ? Et là m’est venue une idée : aller fouiller les fichiers du Phoenix monté lors de l’installation pour trouver quels modèles il s’attend à trouver…
Un petit coup de SSH sur le noeud qui est démarré sur Phoenix et dont l’installation à échouée, et me voilà à me promener dans les méandres du système pour trouver mon bonheur…
C’est dans le dossier /root/.local/lib/python3.9/site-packages/layout/modules que sont situées les informations concernant les modèles supportés. Comment je le sais ? Car dans les logs générés lors de mes précédentes tentatives, il indiquait :
File "/root/.local/lib/python3.9/site-packages/layout/modules/smc_gen11_4node.py", line 104, in populate_layout
Et dans ce dossier module, il y en a absolument pour tous les goûts :
Les noeuds concernés étant des Supermicro, j’ai axé mes recherches sur le préfixe « smc » afin de réduire le champ des possibles :
Afin de réduire encore le nombre de possibilités, j’ai éliminé tout ce qui concernait plus de 1 node (2 et 4 nodes donc) ce qui ne me laissait plus qu’une petite dizaine de possibilités et comme j’ai commencé dans l’ordre, j’ai tout de suite trouvé le bon template : smc_e300_gen11.py !
A l’intérieur du fichier, je repère immédiatement la même carte mère : X11SDV-8C-TP8F
Il est décliné en 2 modèles, SMC-E300-2 qui comporte 2 disques et le SMC-E300-4 qui en comporte 4. C’est donc le premier qui m’intéresse et en cherchant sur internet, je suis tombé sur un autre noeud de chez Supermicro, le SuperServer E300-9D-8CN8TP : https://www.supermicro.com/en/products/system/Mini-ITX/SYS-E300-9D-8CN8TP.cfm
Extrêmement ressemblant avec le noeud en ma possession, je pense que j’ai enfin trouvé le bon modèle ! Je note les éléments importants et j’éteins mon noeuds :
X11SDV-8C-TP8F (board part number)
SMC-E300-2 (modèle)
CSE-E300 (chassis part number)
La dernière ligne droite : le FRU custom
Maintenant que j’ai les informations manquantes, il faut que je modifie mon FRU pour qu’il corresponde à ce que Foundation attend comme modèle.
Puis j’ai relancé un Foundation 5.9 avec un AOS 6.10.1.6 et un AHV 20230302.103014 afin de valider que ce que j’ai trouvé fonctionne :
2025-06-18 07:35:49,786Z foundation_tools.py:1634 INFO Node with ip 192.168.84.22 is in phoenix. Generating hardware_config.json 2025-06-18 07:35:50,071Z foundation_tools.py:1650 DEBUG Running command .local/bin/layout_finder.py local 2025-06-18 07:35:54,153Z imaging_step_misc_hw_checks.py:168 DEBUG Not an NX G7+ node with RAID boot drives. Skipping RAID checks. 2025-06-18 07:35:54,156Z imaging_step.py:123 DEBUG Setting state of ) @dee0> from RUNNING to FINISHED 2025-06-18 07:35:54,157Z imaging_step.py:162 INFO Completed ) @dee0> 2025-06-18 07:35:54,159Z imaging_step.py:123 DEBUG Setting state of ) @deb0> from PENDING to RUNNING 2025-06-18 07:35:54,162Z imaging_step.py:159 INFO Running ) @deb0> 2025-06-18 07:35:54,165Z imaging_step_pre_install.py:364 INFO Rebooting into staging environment 2025-06-18 07:35:54,687Z cache_manager.py:142 DEBUG Cache HIT: key(get_nos_version_from_tarball_()_{'nos_package_path': '/home/nutanix/foundation/nos/nutanix_installer_package-release-fraser-6.10.1.6-stable-a5f69491f9523eef80d3c703f2ad4d2156e71eeb-x86_64.tar.gz'}) 2025-06-18 07:35:54,690Z imaging_step_pre_install.py:389 INFO NOS version is 6.10.1.6 2025-06-18 07:35:54,691Z imaging_step_pre_install.py:392 INFO Preparing NOS package (/home/nutanix/foundation/nos/nutanix_installer_package-release-fraser-6.10.1.6-stable-a5f69491f9523eef80d3c703f2ad4d2156e71eeb-x86_64.tar.gz) 2025-06-18 07:35:54,691Z phoenix_prep.py:82 INFO Unzipping NOS package
Il passe sans encontre la validation du matériel et l’installation fini par aller jusqu’à son terme.
Bien évidemment, c’est une rustine pour permettre à mon client de pouvoir redéployer ses noeuds et les faire durer dans le temps. La solution idéale aurait été de pouvoir créer un fichier .py personnalisé qui corresponde parfaitement à mon modèle sans que j’ai à le modifier, ce qui est malheureusement impossible à l’heure actuelle à ma connaissance.
Un soucis persiste néanmoins : le cluster peut être créé en RF2 mais la Data Resiliency sera en critique… Je cherche toujours une solution à ce problème…
Merci à Théo et Jeroen pour leurs idées qui m’ont montré le début du chemin qui m’a mené jusqu’à la solution !
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.
