Team Leader - Nutanix Technology Champion - Nutanix NTC Storyteller

Julien DUMUR
Infrastructure in a Nutshell

cli

Nutanix AHV : Éteindre proprement un cluster

Published: 10 février 2026
Written by Julien D.
1 Comment
Categories: Nutanix, Nutanix AHV FR
Éteindre proprement un cluster Nutanix AHV

On ne va pas se mentir : éteindre un cluster Nutanix complet, c’est toujours un moment un peu stressant. Même après 15 ans de métier. Pourquoi ? Parce qu’on a beau avoir la meilleure techno HCI du marché, couper le courant sur une infrastructure informatique n’est jamais anodin.

J’ai vu trop de « cowboys » tirer la prise ou faire un « Shutdown » brutal via l’IPMI en pensant que la résilience des données ferait le reste. Spoiler : ça finit souvent avec un support Nutanix niveau 3 pour récupérer des métadonnées Cassandra corrompues ou avec la perte d’un ou plusieurs disques.

Ce guide, c’est ma ligne de vie pour m’assurer que mon cluster redémarrera sans problème. Pas de GUI, pas de Prism Element pour les étapes critiques. On ouvre le terminal, on se connecte en SSH, et on fait ça proprement.

Phase 1 : Le Health Checks

Avant même de penser à arrêter la moindre VM, il faut s’assurer que le cluster est capable de s’arrêter (et surtout de redémarrer). Si votre cluster est déjà en souffrance, l’éteindre n’est pas toujours une bonne option.

1.1 Connexion en SSH a la CVM

Ouvrez votre terminal préféré (PuTTy fait très bien l’affaire) et connectez-vous en SSH à l’adresse IP virtuelle du cluster (Cluster VIP) avec l’utilisateur nutanix.

1.2 Nutanix Cluster Checks (NCC)

Pour s’assurer que le cluster est en bonne santé, il est nécessaire de lancer un NCC. Lancez un check complet :

ncc health_checks run_all

Mon conseil : Ne survolez pas le rapport. Si vous avez un « FAIL » sur la partie Cassandra, Zookeeper ou Metadata, STOP. On répare avant d’éteindre. Un warning sur un disque plein ou une vieille alerte NTP, ça passe. Mais l’intégrité des données, c’est non-négociable.

1.3 Vérification de la résilience

Le dashboard Prism est joli, il vous dit « Data Resiliency Status: OK ». C’est bien, mais ce n’est pas assez précis pour un arrêt total. Je veux savoir si mes données sont réellement synchronisées, maintenant.

Tapez cette commande et regardez-la dans les yeux :

ncli cluster get-domain-fault-tolerance-status type=node

Ce que vous devez voir : Une ligne indiquant Current Fault Tolerance: 2.

Si vous voyez un état indiquant une reconstruction en cours, n’éteignez pas le cluster et patientez pendant la reconstruction.

Phase 2 : L’extinction des machines virtuelles

Une fois le cluster validé comme sain, on passe aux machines virtuelles. L’erreur classique est de se précipiter sur l’arrêt des nœuds, mais il vous sera refusé si des machines virtuelles sont toujours allumées sur le cluster.

2.1 L’ordre de bataille

Commencez par éteindre vos environnements de test/dev, puis les serveurs applicatifs, et enfin les bases de données. C’est du bon sens, mais il est toujours bon de le rappeler.

Une fois l’ensemble des machines de production éteintes, vous pouvez maintenant éteindre le reste des machines virtuelles “outils” de votre infrastructure : AD, DNS, firewalls…

2.2 La gestion de Prism Central

Connectez vous à Prism Central en SSH avec le compte nutanix puis lancez la commande d’arrêt :

cluster stop

Patientez pendant l’arrêt des services de la PCVM et vérifiez que le cluster est bien éteint :

cluster status

Si l’ensemble des services sont éteints et que le statut du cluster est “stop”, nous pouvons maintenant procéder à l’arrêt de la PCVM :

sudo shutdown -h now

Phase 3 : L’arrêt des services Nutanix (« Cluster Stop »)

Vos VMs et Prism Central sont éteints. Vos hôtes ne font plus tourner que les CVMs (Controller VMs). C’est le moment critique. On ne fait jamais un shutdown de l’OS des CVMs sans avoir d’abord arrêté les services du cluster proprement.

Pourquoi ? Parce qu’un arrêt brutal des CVMs peut entrainer une corruption des données ou une inconsistances des métadonnées qui pourra nécessiter l’intervention du support.

3.1 L’arrêt du cluster

Reconnectez vous à la VIP de votre cluster Nutanix et tapez simplement :

cluster stop

Le système va demander une confirmation avant de lancer les opérations. Tapez Y.

Cette commande ordonne à chaque CVM d’arrêter ses services dans un ordre précis. Le service Stargate (qui gère les I/O de stockage) s’assure que tout est « flushé » sur disque avant de s’éteindre.

Vous allez voir des lignes défiler indiquant l’arrêt de Zeus, Scavenger, Cassandra, etc. Soyez patient. Selon la taille du cluster, cela peut prendre 2 à 5 minutes.

3.2 La vérification

Une fois l’opération terminée, vérifiez l’état réel des services :

cluster status

Ce que vous devez voir : Une liste de services pour chaque CVM. Ils doivent tous être en état DOWN, à l’exception potentielle du service Genesis qui peut rester UP , c’est normal.

Si vous voyez d’autres services encore UP, patientez une minute et relancez la vérification. Ne passez pas à la suite tant que le cluster n’est pas totalement à l’arrêt logique.

Phase 4 : Extinction des CVMs et des Nœuds physiques

Nous voici au bout du tunnel. Le cluster est arrêté logiciellement. Il ne reste plus que les coquilles vides : les CVMs (qui sont des VMs Linux, ne l’oublions pas) et les hyperviseurs.

4.1 Arrêt des CVMs

Il faut maintenant se connecter sur chaque CVM individuellement (via son IP, plus via la VIP) et lancer la commande d’extinction.

La commande officielle :

cvm_shutdown -P now

La commande cvm_shutdown contient des hooks spécifiques pour notifier l’hyperviseur. Répétez l’opération sur chaque nœud du cluster.

4.2 Arrêt des Hyperviseurs

Une fois les CVMs éteintes, connectez-vous à vos hôtes (en SSH ou via IPMI) et sur chacun d’entre eux tapez la commande suivante :

shutdown -h now

La Pépite Expert : Le Script d’Automatisation ⚡

Vous avez un cluster de 16 nœuds et la flemme de vous connecter 32 fois (16 CVM + 16 Hosts) ? Je vous comprends.

Voici un script à lancer depuis n’importe quelle CVM du cluster qui va éteindre toutes les CVMs, puis tous les hôtes AHV.

⚠️ AVERTISSEMENT : Ce script ne pose pas de questions. Assurez-vous d’avoir validé la Phase 3 (cluster stop) avant de lancer ça, sinon c’est le crash assuré.

Le script « Kill Switch » (Pour AHV)

Depuis une CVM, ce script récupère les IPs des autres CVMs et des hôtes, puis envoie l’ordre d’extinction en séquence.

for svmip in `svmips`; do ssh -q nutanix@$svmip "sudo /usr/sbin/shutdown +1 ; hostname"; done
for hostip in `hostips`; do ssh -q root@$hostip "/usr/sbin/shutdown +3 ; hostname"; done
  • La première commande ordonne l’extinction des CVMs après un délai d’une minute.
  • La seconde commande ordonne l’extinction des noeuds après un délai de 3 minutes.

Une fois que vous aurez lancé les commandes, vous perdrez la connexion au bout d’une minute. Vous pouvez alors suivre l’extinction de vos noeuds depuis leurs interfaces IPMI respectives.

Phase 5 : Le Rallumage (Cold Boot)

La période de maintenance est terminée. On fait quoi ? On appuie sur ON et on prie ? Non, on respecte l’ordre inverse.

  1. Réseau Physique : Allumez vos switchs Top-of-Rack en premier. Si le réseau n’est pas là, les nœuds ne se verront pas au démarrage.
  2. IPMI / Physique : Allumez les nœuds physiques.
  3. Patience : AHV va booter, puis démarrer automatiquement la CVM.
    • Astuce : Ne touchez à rien pendant 10 minutes. Laissez les CVMs former le cluster.
  4. Démarrage du Cluster : Connectez-vous en SSH sur une CVM. Vérifiez que toutes les CVMs sont up (svmips doit toutes les lister). Puis :cluster start
  5. Vérifier que le cluster est bien démarré avec la commande :cluster status
  6. Démarrage des Workloads : Une fois le cluster UP, rallumez d’abord la PCVM puis vos VMs (Infra d’abord, Appli ensuite).

Conclusion

L’arrêt d’un cluster Nutanix est une procédure simple mais qui nécessite un bon séquençage. Ce n’est pas compliqué, mais ça ne pardonne pas l’impatience. Si vous suivez ces étapes, vous dormirez tranquille pendant la coupure électrique.

Read More

Maxi Best Of Nutanix CLI : vérification des VMs

Published: 28 octobre 2025
Written by Julien D.
No comments
Categories: Nutanix, Nutanix AHV FR, Tutoriels, Tutoriels-AHV
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

Maxi Best Of Nutanix CLI : gestion des subnets

Published: 12 août 2025
Written by Julien D.
2 Comments
Categories: Nutanix, Nutanix AHV FR, Tutoriels, Tutoriels-AHV
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é :

Nutanix AHV : gérer les subnets en lots via CLI

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

Maxi Best Of Nutanix CLI : vérification de la configuration réseau

Published: 8 août 2025
Written by Julien D.
3 Comments
Categories: Nutanix, Nutanix AHV FR, Tutoriels, Tutoriels-AHV
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 :

Résultat de la commande acli net.list_host_nic

Lister tous les vSwitchs actuellement configurés sur le cluster : 

acli net.list_virtual_switch 

Résultat :

Résultat de la commande acli net.list_virtual_switch

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 :

Résultat de la commande acli net.list

Lister les VMs rattachées à un subnet en particulier :

acli net.list_vms SUBNET
Résultat de la commande acli net.list_vms pour un 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 :

Résultat de la commande manage_ovs show_interfaces

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 :

Résultat de la commande manage_ovs show_uplinks

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 :

Résultat de la commande manage_ovs show_lldp

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 :

Résultat de la commande manage_ovs show_bridges

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 :

Résultat de la commande manage_ovs show_cvm_uplinks_map

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 :

Résultat de la commande ovs-vsctl list-br

Lister toutes les interfaces attachées à un bridge en particulier d’un host AHV :

ovs-vsctl list-ifaces br0

Résultat :

Résultat de la commande ovs-vsctl list-ifaces br0

Afficher la configuration d’un port bond d’un host AHV :

ovs-vsctl list port br0-up

Résultat :

Résultat de la commande ovs-vsctl list port br0-up

Afficher la configuration et l’état d’un bond sur un host AHV :

ovs-appctl bond/show br0-up

Résultat :

Résultat de la commande ovs-appctl bond/show br0-up

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

Nutanix AHV – Détruire un cluster

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

Cession à un tiers ou réutilisation du cluster pour un autre usage, il arrive parfois qu’il faille détruire un cluster Nutanix. Voici la marche à suivre pour y parvenir…

Préparation du cluster pour la destruction

Avant de pouvoir procéder à la destruction d’un cluster, il est nécessaire de réaliser quelques préparatifs.

Parmi les prérequis nécessaires, il est impératif qu’il n’y ai plus de machine virtuelle allumée sur le cluster. Veillez à migrer / éteindre / supprimer (au choix) l’ensemble des machines virtuelles sur le cluster.

Note : l’ensemble des commandes de cet article sont à saisir sur une des CVM du cluster.

Une fois que ce prérequis est rempli, on commence par vérifier le statut du cluster :

cluster status

Vous devriez obtenir un retour tel que celui ci : 

nutanix@NTNX-5f832032-A-CVM:192.168.84.22:~$ cluster status
2025-07-24 07:20:18,663Z INFO MainThread zookeeper_session.py:136 Using multithreaded Zookeeper client library: 1
2025-07-24 07:20:18,666Z INFO MainThread zookeeper_session.py:248 Parsed cluster id: 4439894058604263884, cluster incarnation id: 1753169113232129
2025-07-24 07:20:18,666Z INFO MainThread zookeeper_session.py:270 cluster is attempting to connect to Zookeeper, host port list zk1:9876
2025-07-24 07:20:18,676Z INFO Dummy-1 zookeeper_session.py:840 ZK session establishment complete, sessionId=0x198310781ce5e38, negotiated timeout=20 secs
2025-07-24 07:20:18,678Z INFO MainThread cluster:3303 Executing action status on SVMs 192.168.84.22
2025-07-24 07:20:18,682Z INFO Dummy-2 zookeeper_session.py:940 Calling c_impl.close() for session 0x198310781ce5e38
2025-07-24 07:20:18,683Z INFO Dummy-2 zookeeper_session.py:941 Calling zookeeper_close and invalidating zhandle
The state of the cluster: start
Lockdown mode: Disabled

        CVM: 192.168.84.22 Up, ZeusLeader
                              Xmount   UP       [459073, 459235, 459236, 459311]
                           IkatProxy   UP       [458789, 458917, 458918, 458919]
                                Zeus   UP       [454133, 454189, 454190, 454191, 454201, 454218]
                           Scavenger   UP       [459084, 459296, 459297, 459298]
                    SysStatCollector   UP       [464017, 464089, 464090, 464091]
                    IkatControlPlane   UP       [464039, 464218, 464219, 464220]
                       SSLTerminator   UP       [464170, 464323, 464324]
                      SecureFileSync   UP       [464362, 464646, 464647, 464648]
                              Medusa   UP       [468604, 469223, 469224, 469395, 470062]
                  DynamicRingChanger   UP       [476814, 476897, 476898, 476920]
                              Pithos   UP       [476843, 477058, 477060, 477086]
                          InsightsDB   UP       [476918, 477131, 477132, 477155]
                              Athena   UP       [477152, 477270, 477271, 477273]
                             Mercury   UP       [513735, 513803, 513804, 513808]
                              Mantle   UP       [477391, 477551, 477552, 477562]
                          VipMonitor   UP       [485663, 485664, 485665, 485666, 485670]
                            Stargate   UP       [477857, 477995, 477996, 477997, 477998]
                InsightsDataTransfer   UP       [478768, 478929, 478930, 478934, 478935, 478936, 478937, 478938, 478939]
                             GoErgon   UP       [478834, 479020, 479021, 479039]
                             Cerebro   UP       [478950, 479138, 479139, 479306]
                             Chronos   UP       [479088, 479286, 479287, 479310]
                             Curator   UP       [479234, 479406, 479407, 483968]
                               Prism   UP       [479436, 479600, 479601, 479650, 480643, 480885]
                                Hera   UP       [479602, 479917, 479918, 479919]
                        AlertManager   UP       [479860, 480436, 480438, 480555]
                            Arithmos   UP       [480751, 481566, 481567, 481765]
                             Catalog   UP       [481670, 482699, 482700, 482701, 483502]
                           Acropolis   UP       [483575, 484493, 484494, 488301]
                              Castor   UP       [484403, 484877, 484878, 484911, 484972]
                               Uhura   UP       [484912, 485066, 485067, 485300]
                   NutanixGuestTools   UP       [485132, 485254, 485255, 485284, 485611]
                          MinervaCVM   UP       [491046, 491263, 491264, 491265]
                       ClusterConfig   UP       [491188, 491361, 491362, 491363, 491381]
                         APLOSEngine   UP       [491374, 491650, 491651, 491652]
                               APLOS   UP       [495252, 496063, 496064, 496065]
                     PlacementSolver   UP       [497033, 497330, 497331, 497332, 497341]
                               Lazan   UP       [497256, 497568, 497569, 497570]
                             Polaris   UP       [498016, 498620, 498621, 498911]
                              Delphi   UP       [498765, 499238, 499239, 499240, 499332]
                            Security   UP       [500506, 501578, 501579, 501581]
                                Flow   UP       [501478, 502168, 502169, 502171, 502178]
                             Anduril   UP       [510708, 511248, 511249, 511252, 511335]
                              Narsil   UP       [502382, 502472, 502473, 502474]
                               XTrim   UP       [502488, 502629, 502630, 502631]
                       ClusterHealth   UP       [502656, 502774, 503156, 503158, 503166, 503174, 503183, 503351, 503352, 503359, 503384, 503385, 503396, 503401, 503402, 503420, 503421, 503444, 503445, 503468, 503469, 503474, 503752, 503753, 503785, 503786, 503817, 503818, 528495, 528533, 528534, 530466, 530467, 530468, 530469, 530474, 530475, 530488, 530512, 530522, 530571, 530576, 530684, 530773, 530791, 531349, 531357]
2025-07-24 07:20:20,740Z INFO MainThread cluster:3466 Success!

Comme le cluster est actuellement démarré, je dois d’abord le stopper avec la commande suivante :

cluster stop

Attention, pour pouvoir arrêter le cluster, il ne doit plus rester aucune machine virtuelle allumée sur le cluster à l’exception de la CVM.

La commande va arrêter le cluster et les services associés après que vous ayez confirmé l’opération par « I agree » et devrait vous renvoyer ce type de résultat :

The state of the cluster: stop
Lockdown mode: Disabled

        CVM: 192.168.84.22 Up, ZeusLeader
                              Xmount   UP       [1761344, 1761418, 1761419, 1761475]
                           IkatProxy   UP       [458789, 458917, 458918, 458919]
                                Zeus   UP       [454133, 454189, 454190, 454191, 454201, 454218]
                           Scavenger   UP       [459084, 459296, 459297, 459298]
                    SysStatCollector DOWN       []
                    IkatControlPlane DOWN       []
                       SSLTerminator DOWN       []
                      SecureFileSync DOWN       []
                              Medusa DOWN       []
                  DynamicRingChanger DOWN       []
                              Pithos DOWN       []
                          InsightsDB DOWN       []
                              Athena DOWN       []
                             Mercury DOWN       []
                              Mantle DOWN       []
                          VipMonitor   UP       [485663, 485664, 485665, 485666, 485670]
                            Stargate DOWN       []
                InsightsDataTransfer DOWN       []
                             GoErgon DOWN       []
                             Cerebro DOWN       []
                             Chronos DOWN       []
                             Curator DOWN       []
                               Prism DOWN       []
                                Hera DOWN       []
                        AlertManager DOWN       []
                            Arithmos DOWN       []
                             Catalog DOWN       []
                           Acropolis DOWN       []
                              Castor DOWN       []
                               Uhura DOWN       []
                   NutanixGuestTools DOWN       []
                          MinervaCVM DOWN       []
                       ClusterConfig DOWN       []
                         APLOSEngine DOWN       []
                               APLOS DOWN       []
                     PlacementSolver DOWN       []
                               Lazan DOWN       []
                             Polaris DOWN       []
                              Delphi DOWN       []
                            Security DOWN       []
                                Flow DOWN       []
                             Anduril DOWN       []
                              Narsil DOWN       []
                               XTrim DOWN       []
                       ClusterHealth DOWN       []
2025-07-24 07:23:57,716Z INFO MainThread cluster:2194 Cluster has been stopped via 'cluster stop' command, hence stopping all services.
2025-07-24 07:23:57,716Z INFO MainThread cluster:3466 Success!

Nous pouvons maintenant passer à la destruction du cluster.

Destruction du cluster

La destruction du cluster nécessite l’exécution de la commande suivante :

cluster destroy

Le système vous demandera ensuite une confirmation avant de procéder à la suppression de l’ensemble des configurations et données : 

2025-07-24 07:35:45,898Z INFO MainThread zookeeper_session.py:136 Using multithreaded Zookeeper client library: 1
2025-07-24 07:35:45,900Z INFO MainThread zookeeper_session.py:248 Parsed cluster id: 4439894058604263884, cluster incarnation id: 1753169113232129
2025-07-24 07:35:45,900Z INFO MainThread zookeeper_session.py:270 cluster is attempting to connect to Zookeeper, host port list zk1:9876
2025-07-24 07:35:45,916Z INFO Dummy-1 zookeeper_session.py:840 ZK session establishment complete, sessionId=0x198310781ce5e6e, negotiated timeout=20 secs
2025-07-24 07:35:45,918Z INFO Dummy-2 zookeeper_session.py:940 Calling c_impl.close() for session 0x198310781ce5e6e
2025-07-24 07:35:45,918Z INFO Dummy-2 zookeeper_session.py:941 Calling zookeeper_close and invalidating zhandle
2025-07-24 07:35:45,921Z INFO MainThread cluster:3303 Executing action destroy on SVMs 192.168.84.22
2025-07-24 07:35:45,922Z WARNING MainThread genesis_utils.py:348 Deprecated: use util.cluster.info.get_node_uuid() instead
2025-07-24 07:35:45,928Z INFO MainThread cluster:3350

***** CLUSTER NAME *****
Unnamed

This operation will completely erase all data and all metadata, and each node will no longer belong to a cluster. Do you want to proceed? (Y/[N]): Y

L’opération de destruction du cluster prend quelques minutes durant lesquelles l’ensemble des données encore présentes vont être complètement effacées.

Une fois la destruction du cluster terminée, un « cluster status » vous permettra de vérifier qu’AHV est en attente de création du cluster :

nutanix@NTNX-5f832032-A-CVM:192.168.84.22:~$ cluster status
2025-07-24 07:42:50,694Z CRITICAL MainThread cluster:3242 Cluster is currently unconfigured. Please create the cluster.

Voilà, votre cluster est détruit et il ne vous reste plus qu’à le recréer.

Pour ceux qui préfèrent suivre la procédure en vidéo, voici ma vidéo YouTube associée :

Read More

Nutanix : supprimer les taches bloquées

Published: 18 septembre 2024
Written by Julien D.
No comments
Categories: Nutanix, Nutanix AHV FR, Tutoriels, Tutoriels-AHV
Nutanix Blog Header

Il arrive parfois que des tâches soient bloquées indéfiniment sur votre cluster sans jamais aboutir ni échouer. Il vous faut alors procéder à une action manuelle pour remédier au problème.

Tâche Mount Guest tools bloquée à 0 % dans Recent Tasks de Prism

Attention, cette opération n’est pas sans risques, c’est pourquoi je vous conseille vivement de vous rapprocher du support Nutanix si vous n’êtes pas sûr de vous.

La première étape consiste à vérifier depuis combien de temps la tâche s’exécute. Pour cela, rendez vous sur la page des tâches et filtrez sur les tâches en cours d’exécution :

Liste des tâches en cours d'exécution dans Prism

Dans le cas présent, nous pouvons constater que la tâche s’exécute depuis plus de 10 mois. Aucun doute, elle est plantée et doit être annulée manuellement.

Pour ce faire, il faut se connecter à une des CVMs et taper la commande suivante :

nutanix@CVM:~$ ecli task.list include_completed=false

Vous devriez avoir un retour qui ressemble à ceci :

Task UUID Parent Task UUID Component Sequence-id Type Status
37a430d3-b80b-4ae7-bfaf-9df5247e9ce7 Nutanix Guest Tools 282 MountGuestTools kQueued

Récupérez l’UUID de la tâche concernée et tapez la commande suivante :

ergon_update_task –-task_uuid='TASK_UUID' –-task_status=aborted

Adapté à mon cas, cela donne :

ergon_update_task –-task_uuid='37a430d3-b80b-4ae7-bfaf-9df5247e9ce7' –-task_status=aborted

Cela va forcer l’annulation de la tâche en cours d’exécution.

Read More

Nutanix AHV : gérer les subnets en lots via CLI

Published: 9 août 2024
Written by Julien D.
1 Comment
Categories: Nutanix, Nutanix AHV FR, Tutoriels, Tutoriels-AHV
Nutanix Blog Header

Pour un cas client, nous avons eu à créer plus de 70 subnets sur 2 clusters et réaliser l’opération en passant par l’interface graphique aurait été beaucoup trop long et fastidieux. Voici la méthode pour réaliser l’opération en CLI en seulement quelques minutes.

Création des subnets non-managés

Pour me rendre la tâche beaucoup plus facile, j’ai créé un fichier Excel au format .csv dans lequel j’ai mis 3 colonnes :

Fichier CSV avec les colonnes acli net.create, nom et VLAN

Dans un soucis de partage, vous pouvez retrouver le fichier .csv sur mon Github : https://github.com/Exe64/NUTANIX/blob/main/nutanix-unmanaged-subnets.csv

L’idée est de remplir la colonne VLAN_NAME et VLAN_ID avec le nom des VLANs et leurs ID associés, fournis par le client dans le Predelivery Questionnaire :

Tableau des VLAN du Predelivery Questionnaire

Ce qui donnerai :

Fichier CSV rempli avec les VLAN 10 à 17

Enregistrer le fichier puis l’ouvrir avec Notepad++ :

Fichier CSV ouvert dans Notepad++

Remplacer le caractère « ; » par un espace :

Remplacement du point-virgule par un espace dans Notepad++

Remplacer ensuite « vlan=  » par « vlan= » pour recoller l’ID des VLANs à la commande :

Commandes acli net.create prêtes après remplacement

Connectez vous ensuite à une CVM de votre cluster et faites un copier coller de toutes les lignes en une seule fois dans l’interface en ligne de commandes :

Nutanix Controller VM (CVM) is a virtual storage appliance.

Alteration of the CVM (unless advised by Nutanix Technical Support or
Support Portal Documentation) is unsupported and may result in loss
of User VMs or other data residing on the cluster.

Unsupported alterations may include (but are not limited to):

- Configuration changes / removal of files.
- Installation of third-party software/scripts not approved by Nutanix.
- Installation or upgrade of software packages from non-Nutanix
  sources (using yum, rpm, or similar).

** SSH to CVM via 'nutanix' user will be restricted in coming releases.  **
** Please consider using the 'admin' user for basic workflows.           **
nutanix@NTNX-e854cc31-A-CVM:192.168.2.200:~$ acli net.create VLAN_10 vlan=10
acli net.create VLAN_26 vlan=26
acli net.create VLAN_27 vlan=27
acli net.create VLAN_28 vlan=28
acli net.create VLAN_29 vlan=29
acli net.create VLAN_30 vlan=30
acli net.create VLAN_31 vlan=31
acli net.create VLAN_32 vlan=32
acli net.create VLAN_33 vlan=33
acli net.create VLAN_34 vlan=34
acli net.create VLAN_35 vlan=35
acli net.create VLAN_36 vlan=36
acli net.create VLAN_37 vlan=37
acli net.create VLAN_38 vlan=38
acli net.create VLAN_39 vlan=39
acli net.create VLAN_40 vlan=40nutanix@NTNX-e854cc31-A-CVM:192.168.2.200:~$ acli net.create VLAN_11 vlan=11
nutanix@NTNX-e854cc31-A-CVM:192.168.2.200:~$ acli net.create VLAN_12 vlan=12
nutanix@NTNX-e854cc31-A-CVM:192.168.2.200:~$ acli net.create VLAN_13 vlan=13
nutanix@NTNX-e854cc31-A-CVM:192.168.2.200:~$ acli net.create VLAN_14 vlan=14
nutanix@NTNX-e854cc31-A-CVM:192.168.2.200:~$ acli net.create VLAN_15 vlan=15
nutanix@NTNX-e854cc31-A-CVM:192.168.2.200:~$ acli net.create VLAN_16 vlan=16
nutanix@NTNX-e854cc31-A-CVM:192.168.2.200:~$ acli net.create VLAN_17 vlan=17
nutanix@NTNX-e854cc31-A-CVM:192.168.2.200:~$ acli net.create VLAN_18 vlan=18
nutanix@NTNX-e854cc31-A-CVM:192.168.2.200:~$ acli net.create VLAN_19 vlan=19
nutanix@NTNX-e854cc31-A-CVM:192.168.2.200:~$ acli net.create VLAN_20 vlan=20
nutanix@NTNX-e854cc31-A-CVM:192.168.2.200:~$ acli net.create VLAN_21 vlan=21
nutanix@NTNX-e854cc31-A-CVM:192.168.2.200:~$ acli net.create VLAN_22 vlan=22
nutanix@NTNX-e854cc31-A-CVM:192.168.2.200:~$ acli net.create VLAN_23 vlan=23
nutanix@NTNX-e854cc31-A-CVM:192.168.2.200:~$ acli net.create VLAN_24 vlan=24
nutanix@NTNX-e854cc31-A-CVM:192.168.2.200:~$ acli net.create VLAN_25 vlan=25
nutanix@NTNX-e854cc31-A-CVM:192.168.2.200:~$ acli net.create VLAN_26 vlan=26
nutanix@NTNX-e854cc31-A-CVM:192.168.2.200:~$ acli net.create VLAN_27 vlan=27
nutanix@NTNX-e854cc31-A-CVM:192.168.2.200:~$ acli net.create VLAN_28 vlan=28
nutanix@NTNX-e854cc31-A-CVM:192.168.2.200:~$ acli net.create VLAN_29 vlan=29
nutanix@NTNX-e854cc31-A-CVM:192.168.2.200:~$ acli net.create VLAN_30 vlan=30
nutanix@NTNX-e854cc31-A-CVM:192.168.2.200:~$ acli net.create VLAN_31 vlan=31
nutanix@NTNX-e854cc31-A-CVM:192.168.2.200:~$ acli net.create VLAN_32 vlan=32
nutanix@NTNX-e854cc31-A-CVM:192.168.2.200:~$ acli net.create VLAN_33 vlan=33
nutanix@NTNX-e854cc31-A-CVM:192.168.2.200:~$ acli net.create VLAN_34 vlan=34
nutanix@NTNX-e854cc31-A-CVM:192.168.2.200:~$ acli net.create VLAN_35 vlan=35
nutanix@NTNX-e854cc31-A-CVM:192.168.2.200:~$ acli net.create VLAN_36 vlan=36
nutanix@NTNX-e854cc31-A-CVM:192.168.2.200:~$ acli net.create VLAN_37 vlan=37
nutanix@NTNX-e854cc31-A-CVM:192.168.2.200:~$ acli net.create VLAN_38 vlan=38
nutanix@NTNX-e854cc31-A-CVM:192.168.2.200:~$ acli net.create VLAN_39 vlan=39
nutanix@NTNX-e854cc31-A-CVM:192.168.2.200:~$ acli net.create VLAN_40 vlan=40
nutanix@NTNX-e854cc31-A-CVM:192.168.2.200:~$

Un petit contrôle sur l’interface Prism Element pour confirmer la bonne création de vos VLANs :

VLAN créés dans Network Configuration de Prism Element

Création des subnets managés

Nous sommes sur le même principe que pour les subnets non-managés, je vous ai préparé un petit fichier CSV : https://github.com/Exe64/NUTANIX/blob/main/nutanix-managed-subnets.csv

L’étape supplémentaire, c’est le remplacement de « GATEWAY/MASK » par la passerelle du réseau que vous souhaitez ajouter accompagné de son masque de sous réseau. Exemple :

acli net.create VLAN_SERVEURS vlan=2 ip_config=10.100.2.254/24

Ensuite, il faut bien sûr refaire le nettoyage de votre fichier via Notepad pour remplacer par un espace ou supprimer les « ; » avant d’importer tout cela dans votre terminal SSH.

Dans notre exemple, vous allez créer le réseau suivant :

  • Réseau : 10.100.2.0
  • Masque : 255.255.255.0
  • Passerelle : 10.100.2.254

Vous pouvez également modifier les paramètres DHCP de vos subnets en lot comme cela est indiqué dans la documentation officielle : https://portal.nutanix.com/page/documents/details?targetId=Command-Ref-AOS-v6_8:acl-acli-net-auto-r.html

Suppression de subnets

Pour supprimer des subnets le principe est similaire, il suffit de remplacer « net.create » par « net.delete » et de n’indiquer que le nom des subnets à supprimer :

acli net.delete VLAN_NAME

J’ai également créé un fichier CSV disponible sur mon Github pour cela : https://github.com/Exe64/NUTANIX/blob/main/nutanix-subnets-delete.csv

Read More

Nutanix AHV : Renommer le container de stockage par défaut en CLI

Published: 27 juin 2024
Written by Julien D.
No comments
Categories: Nutanix, Nutanix AHV FR, Tutoriels, Tutoriels-AHV
Renommer le container de stockage par défaut en CLI sur Nutanix AHV

Lors du déploiement d’un nouveau cluster, le nom du container de stockage par défaut est généré automatiquement et n’est pas spécialement esthétique.

Pour le renommer, une seule solution : passer par la Command Line Interface.

Afin de réaliser cette opération, connectez vous à une CVM de votre cluster et listez l’ensemble des containers existants sur le cluster :

nutanix@CVM : ncli container list

L’ensemble des containers et leurs détails associés va alors s’afficher. Cherchez dans la liste le container que vous souhaitez renommer et tapez la commande suivante :

nutanix@CVM : ncli container edit name=NOM_ACTUEL new-name=NOUVEAU_NOM

Remplacez « NOM_ACTUEL » par le nom généré automatiquement par le système lors de la création du container, et NOUVEAU_NOM par le nom que vous souhaitez attribuer à ce container en ne mettant ni espace ni caractère spécial autre que le – et le _

Vérifiez ensuite que votre container a été correctement renommé avec la commande :

nutanix@CVM : ncli container list
Résultat de ncli container list avec le container renommé

Sur Prism Element, vous verrez également apparaitre le nouveau nom que vous avez attribué à votre container de stockage :

Container de stockage renommé dans Prism Element

Read More

Nutanix AHV : déployer un hyperviseur imbriqué sur AHV

Published: 26 février 2024
Written by Julien D.
No comments
Categories: Nutanix, Nutanix AHV FR, Tutoriels, Tutoriels-AHV
Déployer un hyperviseur imbriqué sur Nutanix AHV

Dans le cadre de la mise en place de labs sur une infrastructure Nutanix, vous pouvez être amené à déployer un hyperviseur (ESXi, Promox, Hyper-V…) sur l’hyperviseur AHV (Inception !).

Vous serez alors confronté à ce type de message d’erreur lors de l’installation d’ESXi par exemple (la forme diffère pour d’autres hyperviseurs, mais le fond reste le même) :

Erreur Unsupported CPU à l'installation d'ESXi imbriqué

Le processeur ne sera pas détecté comme étant doté de capacités de virtualisation et vous ne pourrez donc pas déployer d’hyperviseur… Mais il est possible de bypasser cette restriction.

Nutanix AHV : bypasser la restriction processeur

Je pars du principe que la machine virtuelle sur laquelle vous souhaitez déployer un hyperviseur est déjà créée.

Pour bypasser la restriction processeur, il faut se connecter à une des CVMs de notre cluster et modifier notre machine virtuelle avec la commande acli vm.update et le paramètre « cpu_passthrough » :

acli vm.update VM_NAME cpu_passthrough=true

Vous obtiendrez le message suivant :

nutanix@NTNX-a64e778d-A-CVM:192.168.2.241:~$ acli vm.update VM_NAME cpu_passthrough=true
VM_NAME: pending
VM_NAME: complete

Attention, cette commande ne fonctionnera que si votre machine virtuelle est éteinte.

Une fois que la commande est appliquée vous pouvez relancer votre installation… Excepté pour ESXi qui nécessite encore une petite subtilité !

Nutanix AHV : tronquer le type de carte réseau pour installer ESXi

Pour installer un ESXi niché sur Nutanix AHV et qu’il soit pleinement fonctionnel, vous devez également modifier les adaptateurs réseaux pour lui faire croire qu’ils sont de type e1000.

Pour cela, toujours machine virtuelle éteinte, connectez vous à une des CVMs, et tapez la commande suivante :

acli vm.nic_create VM_NAME network=NETWORK_NAME model=e1000

Veillez à remplacer VM_NAME par le nom de la machine virtuelle concernée, et NETWORK_NAME par un des réseaux préalablement créé sur votre cluster Nutanix. Vous obtiendrez le message suivant : 

nutanix@NTNX-a64e778d-A-CVM:192.168.2.241:~$ acli vm.nic_create VM_NAME network=NETWORK_NAME model=e1000
NicCreate: pending
NicCreate: complete

Vous pouvez maintenant relancer l’installation de votre hyperviseur.

Read More

Nutanix AHV : configurer l’anti-affinité entre plusieurs VMs

Published: 25 janvier 2024
Written by Julien D.
No comments
Categories: Nutanix, Nutanix AHV FR, Tutoriels, Tutoriels-AHV
Anti-affinité entre machines virtuelles sur Nutanix AHV

Pour un cas client, j’ai du paramétrer l’anti-affinité entre 2 machines virtuelles.

L’anti-affinité : qu’est ce que c’est ?

Tout d’abord, je vais donner un peu de contexte afin que les bases soient posées. Pour un de nos clients, je suis en train de déployer 2 machines virtuelles Palo Alto pour monter un cluster qui va gérer les flux entre ses différents réseaux.

Afin d’assurer une redondance maximale en cas d’une quelconque panne, il faut impérativement que les machines virtuelles soient hébergées sur des hotes différents. En effet, si elles étaient hébergées sur un seul hote, en cas de défaillance de l’hote, le cluster Palo Alto serait hors service.

Deux VMs Palo Alto hébergées sur le même hôte

C’est là que l’anti-affinité entre en jeu et va me permettre de faire en sorte que les 2 machines virtuelles ne se retrouve jamais sur le même hôte.

Mise en place de l’anti-affinité

La mise en place de l’anti-affinité est à réaliser en lignes de commande directement depuis l’un des CVM du cluster et se déroule en plusieurs étapes :

  • Créer un groupe : connectez vous en SSH puis tapez la commande suivante :
nutanix@cvm$ acli vm_group.create group_name
  • Ajouter les machines virtuelles au groupe : 
nutanix@cvm$ acli vm_group.add_vms group_name vm_list=vm_name1,vm_name2
  • Activer l’anti-affinité :
nutanix@cvm$ acli vm_group.antiaffinity_set group_name

Après un moment, les machines virtuelles qui étaient auparavant sur le même hôte seront alors réparties sur 2 hôtes différents.

VMs Palo Alto réparties sur deux hôtes différents

En cas de défaillance d’un hôte hébergeant l’un des 2 machines virtuelles, la machine concernée sera redémarrée sur un des hôtes dans le respect de la règle anti-affinité.

Attention toutefois, si vous migrez manuellement une machine virtuelle où dans le cadre du hôte mis en maintenance, la règle anti-affinité peut ne pas s’appliquer.

Documentation officielle

La documentation officielle Nutanix : https://portal.nutanix.com/page/documents/details?targetId=AHV-Admin-Guide-v6_7:ahv-vm-anti-affinity-t.html

Read More