Un outil de sauvegarde qui sélectionne ses VM par une catégorie os ne vaut que ce que vaut l’étiquette. Sans agent dans les VM, Prism Central ne remonte pas leur OS : il faut le chercher ailleurs, simuler, puis écrire.
Prism Central ne remonte pas l’OS invité sans NGT
Dans le SDK vmm v4.0, la version du système invité, guest_os_version, est un attribut du modèle GuestTools : elle remonte avec Nutanix Guest Tools. Sur le parc concerné, NGT n’était installé que sur quelques dizaines de VM sur plusieurs milliers. Les approches qui s’appuient sur NGT, dont un playbook communautaire de 2023, ne couvraient donc pas le parc (NGT en détail).
Une source de vérité hiérarchisée
L’OS se lit ailleurs, par ordre de confiance :
- la supervision : sous Zabbix, les templates d’agent liés à l’hôte ;
- la CMDB, alimentée par un agent d’inventaire, qui couvre aussi le hors-production ;
- une liste d’exceptions tenue à la main ;
- en dernier recours, une règle par cluster, quand un cluster est dédié à un OS.
Chaque VM reçoit un statut qui dit d’où vient la réponse :
ORDRE = ("supervision", "cmdb", "exception")
def resoudre(vm, sources, regle_cluster):
vu = {s: sources[s].get(vm["nom"]) for s in ORDRE}
if vu["supervision"] and vu["cmdb"] and vu["supervision"] != vu["cmdb"]:
return None, "CONFLIT_SOURCES" # rien ne sera écrit
for s in ORDRE:
if vu[s]:
return vu[s], "CONFIRME_" + s.upper()
par_cluster = regle_cluster(vm["cluster"])
if par_cluster:
return par_cluster, "CLUSTER_SEUL"
return None, "NON_RESOLU"Le rapprochement se fait ici par nom de VM : un nom présent deux fois doit donner un statut « à contrôler », jamais une écriture (ce billet).
La règle de cluster concordait à 99,1 % avec les sources externes. Mais les clusters de hors-production, organisés par propriétaire applicatif, sont mixtes : une vingtaine de VM y ont été corrigées par la CMDB, dont 14 VM Windows sur un cluster dont le nom annonce Linux. Ce n’est pas le script qui l’a remarqué, mais un humain, à la relecture du rapport.
Bilan de la vérification : 89 % des VM confirmées par une source externe, environ 11 % déduites du seul cluster, aucune VM non résolue, aucun conflit.
Le dry-run produit un rapport
La première étape ne fait que lire : un classeur à trois onglets (détail par VM, synthèse par cluster, « à contrôler ») et un export JSON. Rien n’est écrit avant sa relecture.
Appliquer : idempotent, par petits lots
L’écriture n’a lieu qu’avec --apply, d’abord sur 20 VM (--limit 20), avec un filtre par statut. Trois cas : valeur juste, on n’écrit rien ; absente, on l’ajoute ; divergente, on la remplace.
En v3, les catégories vivent dans metadata : categories associe une clé à une valeur, categories_mapping une clé à une liste. Le PUT complet est détaillé dans ce billet.
import os
import requests
PC = os.environ["PC_URL"] # https://<pc>:9440
AUTH = (os.environ["PC_USER"], os.environ["PC_PASSWORD"])
def poser_os(uuid, cible, apply=False):
url = f"{PC}/api/nutanix/v3/vms/{uuid}"
r = requests.get(url, auth=AUTH, timeout=30) # TLS vérifié par défaut
r.raise_for_status()
vm = r.json()
meta = vm["metadata"]
if meta.get("categories_mapping", {}).get("os") == [cible]:
return "deja_ok"
meta.setdefault("categories", {})["os"] = cible
meta.setdefault("categories_mapping", {})["os"] = [cible]
if not apply:
return "simule"
corps = {k: vm[k] for k in ("api_version", "metadata", "spec")}
requests.put(url, json=corps, auth=AUTH, timeout=30).raise_for_status()
return "soumis"Prudence sur use_categories_mapping : son rôle n’est pas décrit dans les pages officielles consultées, et un fil du forum Nutanix le cite parmi des essais restés sans réponse. Validez le comportement sur une VM de test avant tout --apply.
En v4, le SDK vmm v4.0 expose associate_categories et disassociate_categories, qui évitent de renvoyer toute la VM.
Contrôler par relecture
D’après nutanix.dev, le PUT répond par une tâche PENDING : acceptée ne veut pas dire faite. Le contrôle consiste à relancer la vérification ; les VM traitées doivent en ressortir conformes.
Tenir dans la durée
Un playbook déclenché à la création de la VM, avec une branche sur le nom du cluster source ({{trigger[0].cluster_name}}), pose le tag sans appel REST ni NGT, en moins de 20 s lors du test. Il a été abandonné : l’OS étant déclaré dans le formulaire de création, la chaîne de provisionnement est plus fiable qu’une déduction par cluster. C’est elle qui posera la catégorie, en remplacement.
Autre trou observé : une migration Move ne reporte pas les catégories sur la VM cible. Le tag est à ajouter au contrôle post-migration (sauvegarde après Move), et une vérification planifiée peut servir de filet.
Ce qu’il faut retenir
- Sans NGT, Prism Central ne remonte pas l’OS invité : la vérité est dans la supervision ou la CMDB.
- Hiérarchiser les sources, donner un statut à chaque VM, ne rien écrire en cas de conflit.
- La règle par cluster est un dernier recours : les clusters mixtes la mettent en défaut.
- Simulation par défaut, rapport relu, petits lots, écriture idempotente qui remplace la valeur.
- Une écriture soumise se contrôle en relançant la vérification.
In English
Without NGT, Prism Central does not report the guest OS. Look for it in monitoring and the CMDB, rank the sources, simulate, then set the category idempotently and read it back. A disagreement between sources yields a conflict status and no write, and the per-cluster rule is only a last resort that mixed clusters defeat.
Sources & vérification
Testé sur : Prism Central (version non relevée) ; vérification en lecture seule et playbook testés, écriture v3 non encore appliquée
- Nutanix vmm v4.0 Python SDK, modèle GuestTools developers.nutanix.com
- Nutanix vmm v4.0 Python SDK, VmApi developers.nutanix.com
- nutanix.dev, Update Existing VM (v3) nutanix.dev
- nutanix.dev, PUT that down! Updating a VM with Prism Central v3 API nutanix.dev
- Fil next.nutanix.com, assigner une catégorie par l'API v3 next.nutanix.com
- Fil next.nutanix.com, mise à jour des catégories en v3 next.nutanix.com
- Expérience directe de l’auteur, en production (versions ci-dessus)