Set-OPS-Public/docs/config-proxmox.md

make config — référence des paramètres Proxmox

make config lance scripts/config_proxmox.py, l'assistant interactif qui écrit la connexion au cluster Proxmox et les valeurs de clonage par défaut. Il pose 16 paramètres non sensibles puis propose de saisir les secrets API.

• Non sensibles → instance/inventories/lab/group_vars/proxmox.yml
• Secrets → voûte unique instance/inventories/lab/group_vars/all/vault.yml (chiffrée par ansible-vault), qui contient tous les secrets de l'instance (token Proxmox + vault_*). Voir §4.

À chaque invite, la valeur courante (ou le défaut) est affichée entre crochets : appuyer sur Entrée conserve cette valeur. On peut donc relancer make config sans tout retaper.

Ces paramètres sont des intrants communs de l'écosystème (cf. intrants-communs.md §C). L'accès au cluster et le golden template sont des constantes ; le placement par défaut est surchargeable par hôte dans instance/plan/serveurs.yml.

---

1. Accès au cluster Proxmox (constantes — un seul cluster)

Invite	Variable	Défaut	Sens / quoi saisir
Hôte API Proxmox	proxmox_api_host	(vide)	Nom DNS ou IP du nœud qui répond à l'API. Ex. asgard.
Utilisateur API Proxmox	proxmox_api_user	(vide)	Utilisateur avec le realm. Ex. ansible@pve (realm PVE) ou root@pam.
Port API Proxmox	proxmox_api_port	(vide)	Port HTTPS de l'API. Quasi toujours 8006.
Valider les certificats TLS	proxmox_validate_certs	non	oui si le cluster a un certificat de confiance ; non pour un certificat auto-signé (cas usuel en lab).

2. Golden template (constantes — le modèle cloné)

Invite	Variable	Défaut	Sens / quoi saisir
VMID du modèle Debian 13	proxmox_clone_vmid_modele	9000	VMID de la VM-modèle existante à cloner pour chaque nouvelle VM.
Nom logique du modèle	proxmox_clone_source_nom	modele-debian13	Nom de référence du template (lisibilité ; doit correspondre au modèle).

Le golden template est l'actif central : il est cloné pour chaque VM, jamais jeté ni reconstruit à la légère.

3. Placement par défaut des clones (défauts surchargeables par hôte)

Ces valeurs s'appliquent à toute VM clonée, sauf si l'hôte les surcharge dans instance/plan/serveurs.yml.

Invite	Variable	Défaut	Sens / quoi saisir
Nœud Proxmox par défaut	proxmox_clone_noeud	(vide)	Nœud du cluster où créer la VM. Ex. asgard.
Stockage Proxmox par défaut	proxmox_clone_stockage	(vide)	Datastore qui héberge le disque. Ex. local-zfs, TrueNAS.
Pont Proxmox	proxmox_clone_pont	vmbr0	Bridge réseau de la NIC. Ex. vmbr0, vmbr1.
Format disque par défaut	proxmox_clone_format	(vide)	qcow2, raw, … ou vide pour laisser le stockage décider (recommandé : ZFS/LVM imposent leur format).
Clone complet	proxmox_clone_complet	oui	oui = clone indépendant (autonome) ; non = clone lié (dépend du modèle, plus léger mais fragile). Garder oui.
Timeout opérations Proxmox	proxmox_clone_timeout	600	Secondes avant d'abandonner une opération longue (clone, redimensionnement).
Disque principal	proxmox_clone_disque	scsi0	Bus + index du disque système. scsi0 est le standard Set-OPS.
Interface réseau	proxmox_clone_interface	net0	Identifiant de la NIC virtuelle.
Pare-feu interface Proxmox	proxmox_clone_parefeu_interface	non	Active le pare-feu Proxmox au niveau de la NIC. Laisser non : le filtrage se fait dans l'invité (nftables), pas chez l'hyperviseur.
Démarrer le clone après création	proxmox_clone_demarrer	oui	oui = booter la VM dès la création (nécessaire pour qu'Ansible la joigne ensuite).

4. Secrets de l'instance 🔒 (voûte unique)

Tous les secrets de l'instance vivent dans une seule voûte chiffrée par environnement : instance/inventories/<env>/group_vars/all/vault.yml. Un seul fichier, un seul mot de passe — fini les voûtes éparpillées. Gabarit committé : exemples/vault.exemple.yml (token Proxmox + 17 clés vault_* pour PKI, LDAP/SSO, bases, forge, observabilité).

L'assistant demande « Configurer la voûte de secrets maintenant ». Si oui :

Invite	Variable	Défaut	Sens / quoi saisir
Token ID Proxmox	proxmox_api_token_id	set-ops	Identifiant du token API créé côté Proxmox.
Token secret Proxmox	proxmox_api_token_secret	(aucun)	Secret du token. Saisie masquée, écrit dans la voûte chiffrée.

• Si la voûte existe déjà, l'assistant ouvre directement ansible-vault edit (aucune re-saisie en clair).
• Si elle n'existe pas, l'assistant la sème depuis le gabarit (toutes les clés présentes, vides), y place le token, puis la chiffre. On renseigne ensuite les autres secrets avec ansible-vault edit …/all/vault.yml.
• Ces secrets ne transitent jamais par le GUI ni par aucun fichier en clair ; le GUI n'en affiche que les noms (panneau « Intrants »).

Migration depuis l'ancienne proxmox.vault.yml

Si tu as déjà une proxmox.vault.yml, déplace son contenu dans la voûte unique :

cd instance/inventories/lab/group_vars
cp ../../../../exemples/vault.exemple.yml all/vault.yml
ansible-vault view proxmox.vault.yml        # relève token_id + secret
ansible-vault edit all/vault.yml            # colle-les, renseigne le reste
ansible-vault encrypt all/vault.yml         # si pas déjà chiffrée
git rm --cached --ignore-unmatch proxmox.vault.yml 2>/dev/null; rm proxmox.vault.yml proxmox.vault.yml.example

---

Comment créer le token API côté Proxmox

Dans l'interface Proxmox (ou en CLI pveum) :

1. Créer l'utilisateur API (ex. ansible@pve) et lui donner les droits requis (rôle avec VM.Allocate, VM.Clone, VM.Config.*, Datastore.AllocateSpace, SDN.Use/réseau selon le cluster).
2. Créer un token API pour cet utilisateur → noter le Token ID et le secret (affiché une seule fois).
3. Renseigner Token ID + secret dans make config.

Voir aussi

• intrants-communs.md — tous les intrants communs de l'écosystème.
• nomenclature-vm.md — réseau, VLAN, fonctions.
• vm-lifecycle.md — cycle de vie d'une VM (création → conformité).
• make help — liste des cibles.