Dans Prism Central, une protection policy, une règle Flow, un droit d’accès ou un playbook vise rarement une VM par son nom : il vise une catégorie. Mal pensées, les catégories deviennent le point faible de tout ce qui s’appuie dessus.
Une paire clé:valeur, avec des règles de forme
La Nutanix Bible (chapitre Flow, basé sur PC 7.5 et AOS 7.5) pose le modèle : la clé est une classification large (AppType, Environment), la valeur une sous-classification (Exchange, Production), et chaque combinaison forme une catégorie distincte. Une VM peut en porter plusieurs. Selon le blog Nutanix de mai 2026, on étiquette aussi des images, des hôtes, des volume groups et des clusters.
Le modèle Category du SDK Prism v4.0 fixe la forme :
- clé et valeur : 64 caractères au plus, pas de
$en premier caractère, pas de/; - la valeur se met à jour sans changer l’
extId; la clé, elle, ne se met pas à jour (pour la changer quand même : renommer une clé) ; - le propriétaire est l’utilisateur connecté à la création ; le SDK précise qu’il sert au RBAC sur les catégories qu’on possède.
Trois types, dont deux intouchables
L’énumération CategoryType distingue :
- USER : créées par
createCategory, modifiables et supprimables ; - SYSTEM : prédéfinies, créées au démarrage de Prism Central pour les workflows de l’interface ; ni création, ni modification, ni suppression par l’API ;
- INTERNAL : prédéfinies pour les services internes, cachées de l’interface mais renvoyées par l’API et utilisables comme filtres ; non modifiables non plus.
La Bible ajoute qu’on peut compléter une clé intégrée (par exemple SharedService) avec ses propres valeurs, mais que les valeurs d’origine sont verrouillées.
Ce qui s’appuie dessus
L’énumération ResourceType liste les types de ressources associables à une catégorie. Côté entités : VM, image, subnet, cluster, hôte, volume group. Côté politiques :
- protection rule et recovery plan : les protection policies s’appliquent au niveau catégorie (Bible) ; voir PD ou protection policies ;
- network security policy : la base de Flow, détaillée dans la micro-segmentation en mode monitor ;
- access control policy, que le SDK définit comme les règles qui décident de l’autorisation d’un utilisateur à appeler une API : voir le RBAC dans Prism Central ;
- action rule, c’est-à-dire un playbook ; la Bible rappelle qu’un playbook peut aussi affecter automatiquement des VM à des catégories (exemple avec l’OS des VM) ;
- politiques NGT, QoS, storage, image placement, affinité VM-hôte et anti-affinité VM-VM (ce qu’en font HA et ADS).
Avant de modifier ou de supprimer une valeur, demandez ce qui la référence, avec un compte en lecture (RBAC Prism Central). Les associations ne sont renvoyées par la liste que sur demande :
curl -s -u "$PC_USER:$PC_PASS" \
'https://<pc_vip>:9440/api/prism/v4.0/config/categories?$expand=associations'$expand=associations donne des compteurs par type de ressource, $expand=detailedAssociations les UUID des entités et politiques concernées (modèles Category et AssociationSummary du SDK v4.0 ; le guide de workflows nutanix.dev de janvier 2025 demande PC 2024.3 et AOS 6.8 au minimum).
Catégories et projets
Le blog Nutanix de 2026 les sépare : la catégorie classe, le projet isole et porte le contrôle d’accès. Une catégorie peut figurer dans les conditions d’une politique IAM, mais ne donne aucun accès à elle seule. Depuis Prism Central pc.7.6 (annonce de juillet 2026), une catégorie peut être propre à un projet, sans conflit de nom entre projets.
Nommer pour durer
Les conseils de la Bible :
- des labels larges ; éviter de multiplier les catégories très spécifiques, difficiles à gérer ;
- plusieurs catégories par VM, souvent une bonne pratique : une clé commune aux VM sécurisées, puis
OS:WindowsouOS:Linux; - pour une VM précise, une clé
VMavec une valeur dédiée ; - des valeurs explicites plutôt qu’une absence : voir Flow en mode monitor.
Pour contrôler que le parc suit la convention : auditer la nomenclature des VM.
Ce qu’il faut retenir
- Clé et valeur : 64 caractères, ni
$en tête ni/; la clé ne se modifie pas. - SYSTEM et INTERNAL ne s’écrivent pas par l’API, mais les INTERNAL remontent dans les listes.
- DR, Flow, accès, playbooks, NGT et affinités s’appuient sur les catégories :
$expand=associationsavant toute modification. - Une catégorie classe, elle n’ouvre aucun droit à elle seule.
- Des labels larges, cumulables et explicites.
In English
A key:value pair that DR, Flow, access rights and playbooks target instead of VMs. Format rules, USER, SYSTEM and INTERNAL types, associations to check and a naming scheme that holds. Key and value are limited to 64 characters, the value can change without changing the extId but the key cannot, and a category grants no access on its own.
Sources & vérification
Relevé sur : Documentation publique Nutanix (Nutanix Bible, nutanix.dev, référence SDK Prism v4.0, nutanix.com, Nutanix Community), relevé 2026-10
- Nutanix Bible, Flow Network Security nutanixbible.com
- Nutanix Bible, DR Services nutanixbible.com
- Prism v4.0 Python SDK, modèle Category developers.nutanix.com
- Prism v4.0 Python SDK, modèle AssociationSummary developers.nutanix.com
- Prism v4.0 Python SDK, énumération CategoryType developers.nutanix.com
- Prism v4.0 Python SDK, énumération ResourceType developers.nutanix.com
- nutanix.dev, Nutanix Prism Categories V4 API Workflows Documentation (2025) nutanix.dev
- nutanix.com, Nutanix Categories and Projects (2026) nutanix.com
- Nutanix Community, Prism Central pc.7.6 (2026) next.nutanix.com