11. Templates et clones — déploiement en série

11.1 Convertir une VM en template

Une VM préparée (OS installé, cloud-init configuré, agent QEMU actif) se convertit en template en un clic. Si elle a démarré pendant sa préparation, ne serait-ce que pour un test, elle doit d'abord être nettoyée et éteinte (§10.2).

La commande cloud-init clean --logs --machine-id efface l'état de cloud-init et remet l'identifiant système à uninitialized. Sans cela, tous les clones partagent le même machine-id, vérifié sur le lab. Un template n'est plus démarrable directement — il sert uniquement de source de clonage.

Via l'interface graphique :

VM → More → Convert to Template

Une boîte de confirmation s'ouvre. Après validation, l'icône de la VM dans le panneau de gauche change pour indiquer qu'il s'agit d'un template.

Via CLI :

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Convertir la VM 100 en template
qm template 100

# Vérifier que la conversion a réussi
qm config 100 | grep template
# → template: 1

Résultat attendu de qm config 100 | grep template :

template: 1

Deux points de départ pour un template. Le plus courant actuellement est une image cloud préparée par cloud-init (§10) : chaque clone reçoit au premier démarrage son nom, son adresse, son compte et ses clés.

Mais n'importe quelle VM installée peut devenir un template, par exemple la VM 105 installée depuis l'ISO. La différence porte sur ce qui reste à faire, avant la conversion puis sur chaque clone.

Deux constats du lab justifient le nettoyage manuel. Sans suppression de /var/lib/dbus/machine-id, le clone a repris le machine-id de la VM d'origine : systemd recrée /etc/machine-id à partir de cette copie. Et le clone démarre avec l'adresse fixe du modèle : branché tel quel, il entre en conflit avec la VM d'origine.

Le template d'une VM installée convient pour quelques machines, ou pour un système qui n'a pas d'image cloud. Dès qu'on déploie en série, cloud-init fait ce travail à la place de l'administrateur.

11.2 Cloner un template — clone lié vs clone intégral

Proxmox propose deux types de clones avec des compromis différents :

Clone lié (Linked Clone) : le clone partage les blocs de données du template grâce au mécanisme CoW (Copy-on-Write). Le disque du clone n'occupe que l'espace des données modifiées par rapport au template.

Très rapide à créer (quelques secondes), mais le clone dépend du template : ses blocs non modifiés sont lus dans le disque base- du template. Proxmox refuse d'ailleurs de supprimer un template tant qu'un clone lié en dépend.

Clone intégral (Full Clone) : copie complète et indépendante du disque. Prend plus de temps et d'espace, mais le clone est totalement autonome — le template peut être supprimé sans impact.

Via l'interface graphique :

Template → More → Clone

Via CLI :

Dans le Shell du nœud (interface web → votre nœud → Shell) :

# Clone lié (rapide — dépend du template 9000)
qm clone 9000 101 --name debian-prod-01 --linked 1

# Clone intégral (indépendant)
qm clone 9000 102 --name debian-prod-02 --full 1 --storage local-lvm

# Personnaliser le clone avant démarrage
qm set 101 --ipconfig0 ip=10.44.1.56/24,gw=10.44.1.1
qm set 101 --ciuser devops --sshkeys ~/.ssh/authorized_keys   # utilisateur et clé SSH du clone
qm cloudinit update 101   # régénérer le lecteur cloud-init

# Démarrer le clone
qm start 101

Résultat attendu de qm clone 9000 101 --name debian-prod-01 --linked 1 :

create linked clone of drive scsi0 (local-lvm:base-9000-disk-0)
  Logical volume "vm-101-disk-0" created.

Le clone est créé en quelques secondes : son disque vm-101-disk-0 n'est qu'un instantané du disque base-9000-disk-0, qui ne contiendra que ce que le clone écrira. Après qm start 101, cloud-init applique les paramètres spécifiques au clone (hostname, IP, clé SSH) au premier démarrage.

Ce que chaque type de clone fait du disque du template. Le clone lié n'écrit que ses différences et lit le reste dans base-9000-disk-0 : il en dépend.

Le clone intégral en a une copie complète : il est autonome. Cliquez sur un élément pour le détail.

Revenons à la définition de base : cloner, c'est fabriquer une nouvelle VM à partir d'une autre. La question est : le clone a-t-il besoin de l'original pour vivre ?

Un clone lié lit ses blocs non modifiés dans le disque du template : c'est pourquoi Proxmox refuse de supprimer un template tant qu'un clone lié en dépend. Un clone intégral, lui, survit à la suppression du template.

Où les voir sur votre nœud :

Résultat attendu (pxe211, Proxmox VE 9, stockage local-lvm) : un modèle d'essai 990, puis un clone lié 991.

root@pxe211:~# qm template 990
  Renamed "vm-990-disk-0" to "base-990-disk-0" in volume group "pve"
root@pxe211:~# qm clone 990 991 --name essai-lie
creating a clone of VM 990 with ID 991
create linked clone of drive scsi0 (local-lvm:base-990-disk-0)
  Logical volume "vm-991-disk-0" created.
root@pxe211:~# qm config 991 | grep scsi0
boot: order=scsi0
scsi0: local-lvm:vm-991-disk-0,size=1G

Sans --full, qm clone d'un template fait un clone lié : le journal le dit (create linked clone) et nomme le disque du modèle qui sert de base. La configuration du clone, elle, ne cite que son propre disque. Pour savoir si une VM est un clone lié, on lit le journal de la tâche de clonage.