Team Leader - Nutanix Technology Champion - Nutanix NTC Storyteller

Julien DUMUR
Infrastructure in a Nutshell
nutanix ahv cli reference guide

Dans ce nouvel article, nous allons voir l’ensemble des principales commandes CLI de Nutanix AHV qui permettent de réaliser certaines vérifications sur vos machines virtuelles, en lignes de commandes.

L’ensemble des commandes de cet article sont à exécuter en SSH depuis n’importe quelle CVM du cluster.

Afficher la liste des machines virtuelles

Pour afficher la liste des machines virtuelles présentes sur le cluster Nutanix, il suffit de lancer la commande suivante :

acli vm.list

Cela vous affichera l’ensemble des VMs présentes sur le cluster, sans les CVMs :

nutanix@NTNX-S348084X9211699-B-CVM:192.168.84.22:~$ acli vm.list
VM name VM UUID
LINUX 88699c96-11a5-49ce-9d1d-ac6dfeff913d
NTNX-192-168-84-200-PCVM-1760699089 f659d248-9ece-4aa0-bb0c-22a3b3abbe12
vm_test 9439094a-7b6b-48ca-9821-a01310763886

Comme vous pouvez le constater, je n’ai que 2 machines virtuelles sur mon cluster :

  • mon Prism Central
  • une machine virtuelle « LINUX » fraichement déployée
  • une machine virtuelle de test

Une commande pratique pour récupérer rapidement l’intégralité des machines virtuelles et leurs UUID respectifs. Voyons maintenant comment récupérer des informations sur une machine virtuelle en particulier.

Récupérer les informations d’une machine virtuelle

Pour afficher les informations détaillées d’une machine virtuelle, il faut utiliser la commande suivante :

acli vm.get VM_NAME

En reprenant l’exemple de ma machine virtuelle « LINUX », cela renvoi les informations suivantes :

nutanix@NTNX-S348084X9211699-B-CVM:192.168.84.22:~$ acli vm.get LINUX
LINUX {
config {
agent_vm: False
allow_live_migrate: True
apc_config {
apc_enabled: False
}
bios_uuid: "88699c96-11a5-49ce-9d1d-ac6dfeff913d"
boot {
boot_device_order: "kCdrom"
boot_device_order: "kDisk"
boot_device_order: "kNetwork"
hardware_virtualization: False
secure_boot: False
uefi_boot: True
}
cpu_hotplug_enabled: True
cpu_passthrough: False
disable_branding: False
disk_list {
addr {
bus: "ide"
index: 0
}
cdrom: True
device_uuid: "fae2ee55-8736-4f3a-9b2c-7d5f5770bf33"
empty: True
iso_type: "kOther"
}
disk_list {
addr {
bus: "scsi"
index: 0
}
cdrom: False
container_id: 4
container_uuid: "2ead3997-e915-4ee2-b9a4-0334889e434b"
device_uuid: "f9a8a84c-6937-4d01-bfd2-080271c44916"
naa_id: "naa.6506b8def195dc769b32f3fe47100297"
storage_vdisk_uuid: "215ba83c-44cb-4c41-bddc-1aa3a44d41c7"[7] 0:python3.9* "ntnx-s348084x9211699-" 21:12 21-Oct-25 vmdisk_size: 42949672960
vmdisk_uuid: "42a18a62-861a-497a-9d73-e959513ce709"
}
generation_uuid: "9c018794-a71a-45ae-aeca-d61c5dd6d11a"
gpu_console: False
hwclock_timezone: "UTC"
machine_type: "pc"
memory_mb: 8192
memory_overcommit: False
name: "LINUX"
ngt_enable_script_exec: False
ngt_fail_on_script_failure: False
nic_list {
connected: True
mac_addr: "50:6b:8d:fb:a1:4c"
network_name: "NUTANIX"
network_type: "kNativeNetwork"
network_uuid: "7d13d75c-5078-414f-a46a-90e3edc42907"
queues: 1
rx_queue_size: 256
type: "kNormalNic"
uuid: "c6f02560-b8e6-4eed-bc09-1675855dfc77"
vlan_mode: "kAccess"
}
num_cores_per_vcpu: 1
num_threads_per_core: 1
num_vcpus: 2
num_vnuma_nodes: 0
power_state_mechanism: "kHard"
scsi_controller_enabled: True
vcpu_hard_pin: False
vga_console: True
vm_type: "kGuestVM"
vtpm_config { is_enabled: False
}
} is_ngt_ipless_reserved_sp_ready: True
is_rf1_vm: False
logical_timestamp: 1
state: "kOff"
uuid: "88699c96-11a5-49ce-9d1d-ac6dfeff913d"

Comme vous pouvez le constater, cela renvoi l’intégralité des informations d’une machine virtuelle. Il est possible de filtrer une partie des informations renvoyées avec certaines commandes. Voici celles que j’utilise le plus souvent :

acli vm.disk_get VM_NAME : pour récupérer les informations détaillées de l’ensemble des disques d’une machine virtuelle

nutanix@NTNX-S348084X9211699-B-CVM:192.168.84.22:~$ acli vm.disk_get LINUX
ide.0 {
addr {
bus: "ide"
index: 0
}
cdrom: True
device_uuid: fae2ee55-8736-4f3a-9b2c-7d5f5770bf33
empty: True
iso_type: "kOther"
}
scsi.0 {
addr {
bus: "scsi"
index: 0
}
cdrom: False
container_id: 4
container_uuid: "2ead3997-e915-4ee2-b9a4-0334889e434b"
device_uuid: f9a8a84c-6937-4d01-bfd2-080271c44916
naa_id: "naa.6506b8def195dc769b32f3fe47100297"
storage_vdisk_uuid: 215ba83c-44cb-4c41-bddc-1aa3a44d41c7
vmdisk_size: 42949672960
vmdisk_uuid: 42a18a62-861a-497a-9d73-e959513ce709
}

acli vm.nic_get VM_NAME : pour récupérer la liste détaillée des cartes réseaux attachées à une machine virtuelle

nutanix@NTNX-S348084X9211699-B-CVM:192.168.84.22:~$ acli vm.nic_get LINUX
50:6b:8d:fb:a1:4c {
connected: True
mac_addr: "50:6b:8d:fb:a1:4c"
network_name: "NUTANIX"
network_type: "kNativeNetwork"
network_uuid: "7d13d75c-5078-414f-a46a-90e3edc42907"
queues: 1
rx_queue_size: 256
type: "kNormalNic"
uuid: "c6f02560-b8e6-4eed-bc09-1675855dfc77"
vlan_mode: "kAccess"
}

acli vm.snapshot_list VM_NAME : pour récupérer la liste des snapshots associés à une machine virtuelle

nutanix@NTNX-S348084X9211699-B-CVM:192.168.84.22:~$ acli vm.snapshot_list LINUX
Snapshot name Snapshot UUID
SNAPSHOT_BEFORE_UPGRADE e7c1e84e-7087-42fd-9e9e-2b053f0d5714

Vous savez tout ou presque sur la vérification de vos machines virtuelles.

Pour la liste complète des commandes, je vous invite à consulter la documentation officielle : https://portal.nutanix.com/page/documents/details?targetId=Command-Ref-AOS-v7_3:man-ncli-c.html

Dans le prochain article, nous nous attaquerons à un gros morceau : la création de machines virtuelles via les commandes CLI.

Read More
nutanix ahv cli reference guide

Dans la série Maxi Best Of Nutanix CLI, les 2 précédents articles traitaient de la vérification de la configuration du réseau d’un cluster Nutanix et de la gestion des subnets.

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.

Le renommage d’un container de stockage peut être effectué grâce à la commande suivante :

ncli container edit name=ACTUALNAME new-name=NEWNAME

Sur le container par défaut, cela donnerai par exemple la commande suivante :

ncli container edit name=default-container-21425105524428 new-name=ntnx-lab-container

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 :

ncli container create name=NAME sp-name=STORAGE-POOL-NAME

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 :

  • nom de container « client-alpha »
  • capacité réservée de 64Gb
  • capacité maximale de 64Gb
  • avec la compression en temps réel activée

Voici la commande qu’il faudrait passer :

ncli container create name=client-alpha res-capacity=64 adv-capacity=64 enable-compression=true compression-delay=0 sp-name=default-storage-pool-21425105524428

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 :

ncli container remove name=NAME ignore-small-files=true

Cela donnerai par exemple :

ncli container remove name=lab-container ignore-small-files=true

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 !

Documentation officielle

Pour en savoir plus sur certaines options des commandes présentées, je vous invite à consulter la documentation officielle : https://portal.nutanix.com/page/documents/details?targetId=Command-Ref-AOS-v6_10:acl-ncli-container-auto-r.html

Read More
nutanix ahv cli reference guide

Dans le précédent article du menu Maxi Best Of Nutanix CLI, je vous ai présenté l’ensemble des meilleures commandes pour vérifier l’intégralité de la configuration du réseau de votre cluster Nutanix.

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 » :

acli net.create NUTANIX vlan=84 virtual_switch=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 » :

acli net.create NUTANIX vlan=84 virtual_switch=vs0 ip_config=10.0.84.254/24

Suppression d’un subnet existant

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.

Tout est sur mon Github : https://github.com/Exe64/NUTANIX

Pour les subnets non managés : https://github.com/Exe64/NUTANIX/blob/main/nutanix-unmanaged-subnets.csv

Pour les subnets managés : https://github.com/Exe64/NUTANIX/blob/main/nutanix-managed-subnets.csv

Pour la suppression de subnets : https://github.com/Exe64/NUTANIX/blob/main/nutanix-subnets-delete.csv

Pour en savoir plus sur l’utilisation de ces fichiers, je vous invite à consulter mon article dédié :

Documentation officielle

La documentation complète des commandes disponibles sur le site officiel de l’éditeur : https://portal.nutanix.com/page/documents/details?targetId=Command-Ref-AOS-v6_10:man-acli-c.html

Read More
nutanix ahv cli reference guide

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 !

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

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

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

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