Rien n’empêche deux VM de porter le même nom, y compris sur le même cluster et toutes deux allumées. Un outillage qui indexe l’inventaire par nom perd alors des machines, sans le moindre message d’erreur.
Ce qu’on a trouvé
En préparant une campagne de migration sur un Prism Central de production, l’inventaire d’un seul site comptait plus de 40 noms portés par plusieurs machines. Cinq de ces noms correspondaient à deux VM allumées sur le même cluster.
Comment cinq VM ont disparu du plan
Le référentiel de campagne était un dictionnaire dont la clé était le nom de la VM. Chaque paire d’homonymes y a été écrasée silencieusement : une seule machine par nom a survécu. Cinq VM de production allumées manquaient au plan, et l’écart n’est apparu qu’en comparant le plan à l’inventaire réel.
Le mécanisme, en Python, sans aucun appel d’API :
vms = [
{"nom": "<VM>", "uuid": "<uuid-a>", "cluster": "<cluster>", "etat": "ON"},
{"nom": "<VM>", "uuid": "<uuid-b>", "cluster": "<cluster>", "etat": "ON"},
]
par_nom = {vm["nom"]: vm for vm in vms}
print(len(vms), len(par_nom)) # 2 1 : une VM a disparu, sans erreur
Le correctif : indexer par UUID, et détecter les homonymes au lieu de les écraser.
from collections import defaultdict
par_uuid = {vm["uuid"]: vm for vm in vms}
homonymes = defaultdict(list)
for vm in vms:
homonymes[vm["nom"]].append(vm["uuid"])
doublons = {nom: uuids for nom, uuids in homonymes.items() if len(uuids) > 1}
print(doublons) # {'<VM>': ['<uuid-a>', '<uuid-b>']}
Le même piège dans les plans de migration
Un plan de migration ciblé par nom prend la mauvaise des deux machines, ou une seule. Le suivi est tout aussi exposé : voir un nom disparaître d’un cluster source ne prouve pas que « la » VM a été migrée, puisqu’il pouvait y en avoir deux.
Ce qu’en dit Nutanix
Aucune page de documentation officielle trouvée n’énonce la non-unicité des noms de VM. La seule source repérée est un fil de la communauté next.nutanix.com (2024), donc une réponse communautaire, pas une doc officielle : un membre y confirme par un test qu’AHV accepte deux VM de même nom dans un cluster, et que l’unicité repose sur l’UUID plutôt que sur le libellé. L’auteur de la question en conclut qu’il réécrit son script pour travailler sur les UUID.
Ce qu’il faut retenir
- Le nom d’une VM n’est pas un identifiant : deux VM allumées sur un même cluster peuvent le partager.
- Un dictionnaire indexé par nom perd des VM sans erreur ; gardez une liste, ou indexez par UUID.
- Ajoutez une colonne UUID au classeur de campagne et construisez chaque plan sur l’UUID.
- La disparition d’un nom ne prouve pas une migration : contrôlez par UUID.
In English
Several VMs can share the same name while powered on in the same cluster. An inventory indexed by name silently loses one VM from each pair, without any error. A field report and a fix in a few lines of Python: every migration plan should be built on the UUID, never on the name.
Sources & vérification
Testé sur : Prism Central de production, 2026
- Fil next.nutanix.com, réponse communautaire next.nutanix.com
- Expérience directe de l’auteur, en production (versions ci-dessus)
