# Créer plusieurs VM avec ce dépôt

Une VM = un fichier `vms/<nom>.tfvars` + un espace de travail Terraform du même nom.
Chaque VM a donc **son propre état** : en détruire une ne touche pas aux autres, et un
plan raté sur l'une n'a aucun effet sur l'autre.

```
vms/
├── centreon.tfvars           VM 120, Debian 12, 10.0.5.20
└── exemple-debian13.tfvars   VM 121, Debian 13, 10.0.5.21
```

Dans le bucket S3, les états se rangent sous `env:/<nom>/backend/…`, automatiquement.

## Ajouter une VM

Copier un fichier existant, le renommer, puis adapter. Trois valeurs doivent être
uniques sur l'infrastructure, et **rien ne le vérifie** — deux VM avec le même `vm_id`
provoquent un échec à la création, deux avec la même IP un conflit silencieux :

- `vm_id`
- `vm_hostname`
- `vm_ipv4_address`

Un `git push` déclenche le plan de **toutes** les VM déclarées : c'est le filet qui
attrape une erreur de syntaxe ou un fichier de clé manquant avant tout déploiement.

Pour créer la VM, lancer `deploy` en saisissant son nom dans le champ `vm`. Le workflow
refuse un nom sans fichier correspondant et liste les VM connues.

## Changer de version de Debian

Deux lignes, dans le fichier de la VM concernée :

```hcl
debian_image_url       = "https://cloud.debian.org/images/cloud/trixie/latest/debian-13-genericcloud-amd64.qcow2"
debian_image_file_name = "debian-13-genericcloud-amd64.qcow2"
```

Le reste du code n'en dépend pas : comptes, durcissement SSH, nftables, agent invité et
mises à jour automatiques sont identiques d'une version à l'autre. Le nom du fichier
doit garder une extension `.qcow2`, `.raw` ou `.vmdk`, seules acceptées par le contenu
`import` de Proxmox.

Une limite à connaître : **Centreon 25.10 n'existe que pour Debian 12**. Le dépôt
`ansible-centreon` refuse d'ailleurs de s'exécuter sur autre chose. Une VM Debian 13
convient pour tout le reste.

## Migration de l'existant

La VM `centreon` a été créée avant ce découpage, son état vit donc dans l'espace
`default`. Le workflow **migrer-espaces** le recopie une fois pour toutes dans l'espace
`centreon`, sans rien détruire : confirmation `MIGRER`, puis il vérifie qu'aucune
modification n'est proposée ensuite.

À lancer **avant** tout autre workflow. Sans cette migration, un `deploy` sur la VM
`centreon` la verrait comme inexistante et tenterait de la recréer — avec un VMID déjà
pris, donc un échec, mais autant l'éviter.

L'espace `default` conservera une copie de l'état après migration. Terraform interdit de
le supprimer, et plus aucun workflow ne l'utilise : il devient inerte.

## Commandes hors CI

Pour un essai ponctuel, par conteneur :

```bash
docker run --rm -it -v "$PWD":/work -w /work \
  -e TF_VAR_pve_api_token -e TF_VAR_pve_ssh_password \
  -e AWS_ACCESS_KEY_ID -e AWS_SECRET_ACCESS_KEY \
  hashicorp/terraform:latest workspace list
```

`workspace list` montre les espaces existants, `workspace select <nom>` bascule, et
chaque commande doit ensuite recevoir `-var-file=vms/<nom>.tfvars`. Se tromper de
couple espace/fichier est la seule vraie façon de se faire mal ici : Terraform
comparerait l'état d'une VM à la définition d'une autre et proposerait de tout recréer.
C'est la raison pour laquelle les workflows sélectionnent toujours les deux ensemble, à
partir du même nom.