Modèles, clones et cloud-init : déployer une VM en une minute

Un modèle (template) est une machine virtuelle préparée une fois pour toutes, figée, qui sert de base à de nouvelles VM : on la clone au lieu de réinstaller un système à chaque fois. Avec cloud-init, le clone reçoit à son premier démarrage son nom, son adresse IP, son compte et sa clé SSH, sans qu'on ouvre la console. Ce chapitre explique la différence entre clone complet et clone lié, construit un modèle Debian 13 avec cloud-init, prépare un modèle Windows avec Sysprep, et automatise le déploiement.

Pourquoi des modèles

Installer Debian à la main prend vingt minutes, Windows Server une heure avec les mises à jour. Et deux installations manuelles ne sont jamais tout à fait identiques. Un modèle apporte :

• la vitesse : un clone est prêt en une minute ;
• la standardisation : tous les serveurs partent de la même base, avec les mêmes réglages de sécurité, le même agent invité, la même configuration de l'heure ;
• la documentation : le modèle est décrit une fois, ses clones héritent de cette description.

Le piège, c'est la duplication des identifiants. Une VM copiée telle quelle garde ceux de l'original : le nom d'hôte, l'identifiant de machine Linux (/etc/machine-id), les clés d'hôte SSH, et sous Windows l'identifiant de sécurité (SID) de la machine. Deux machines du domaine avec le même SID, deux serveurs avec les mêmes clés SSH ou le même machine-id (et donc parfois le même bail DHCP) provoquent des pannes difficiles à comprendre. Un modèle doit donc être généralisé : débarrassé de tout ce qui doit être unique. Proxmox, lui, attribue toujours une nouvelle adresse MAC au clone.

Modèle, clone complet et clone lié

Dans Proxmox VE, une VM devient un modèle avec More > Convert to template (ou qm template <VMID>). Un modèle ne démarre plus ; son icône change, ses disques sont renommés base-<VMID>-disk-N et deviennent en lecture seule. On en tire des clones avec More > Clone :

Un modèle Debian 13 avec cloud-init

cloud-init est un programme présent dans les images « cloud » des distributions Linux. Au premier démarrage, il lit une configuration fournie par l'hyperviseur (sous Proxmox, un petit lecteur CD virtuel CloudInit Drive) et l'applique : nom d'hôte, compte utilisateur, clé SSH, adresse IP, DNS, mise à jour des paquets. Il régénère aussi les clés d'hôte SSH : le clone est unique sans rien faire.

Debian publie une image prête, debian-13-genericcloud-amd64.qcow2. Sur pve1, en root :

# 1. Télécharger l'image cloud de Debian 13
cd /root
wget https://cloud.debian.org/images/cloud/trixie/latest/debian-13-genericcloud-amd64.qcow2

# 2. Créer la VM 9000, sans disque pour l'instant
qm create 9000 --name modele-debian13 --ostype l26 \
  --cpu x86-64-v2-AES --cores 2 --memory 2048 \
  --scsihw virtio-scsi-pci --net0 virtio,bridge=vmbr0,tag=20 \
  --agent enabled=1

# 3. Importer l'image comme disque de la VM, sur le stockage partagé
qm set 9000 --scsi0 truenas-nfs:0,import-from=/root/debian-13-genericcloud-amd64.qcow2,format=qcow2

# 4. Ajouter le lecteur cloud-init, démarrer sur le disque, console série
qm set 9000 --ide2 truenas-nfs:cloudinit
qm set 9000 --boot order=scsi0
qm set 9000 --serial0 socket --vga serial0

# 5. Réglages communs à tous les clones
qm set 9000 --ciuser sorbier-admin --sshkeys /root/.ssh/id_ed25519.pub \
  --nameserver 192.168.10.177 --searchdomain ad.sorbier.example --ciupgrade 1

# 6. Figer le modèle
qm template 9000

Ce qu'il faut retenir de ces commandes :

• import-from copie l'image téléchargée dans un nouveau disque de la VM ; la taille 0 signifie « la taille de l'image » (environ 3 Go) ;
• truenas-nfs:cloudinit crée le lecteur qui portera la configuration cloud-init ; toute VM cloud-init doit en avoir un ;
• --serial0 socket --vga serial0 donne une console série : les images cloud n'affichent pas toujours d'écran graphique. On l'ouvre avec Console (xterm.js) ;
• --ciupgrade 1 demande à cloud-init de mettre à jour les paquets au premier démarrage.

Les mêmes réglages se trouvent dans l'onglet Cloud-Init de la VM : User, Password, DNS domain, DNS servers, SSH public key, Upgrade packages, IP Config (net0). Après une modification, le bouton Regenerate Image reconstruit le lecteur cloud-init.

#cloud-config
packages:
  - qemu-guest-agent
runcmd:
  - systemctl start qemu-guest-agent

Déployer un serveur depuis le modèle

Sorbier veut un serveur de recette, srv-recette, pour tester la prochaine version de son application de gestion avant de l'installer sur srv-gestion. Le VLAN 20 des serveurs est plein : il va dans le VLAN 21 APPLIS (192.168.21.0/24, passerelle 192.168.21.254), que Sorbier a ouvert pour les applications internes et la recette quand le VLAN 20 des serveurs a été plein, avec l'adresse 192.168.21.186. Le modèle est branché sur le VLAN 20 : on change donc l'étiquette de la carte du clone.

qm clone 9000 186 --name srv-recette --full --storage truenas-nfs
qm set 186 --cores 4 --memory 8192
qm set 186 --net0 virtio,bridge=vmbr0,tag=21,firewall=1
qm set 186 --ipconfig0 ip=192.168.21.186/24,gw=192.168.21.254
qm disk resize 186 scsi0 40G
qm start 186

Une minute plus tard, ssh sorbier-admin@192.168.21.186 fonctionne : le clone a son nom (celui de la VM, srv-recette), son adresse, le compte sorbier-admin avec ta clé, ses propres clés d'hôte SSH, et cloud-init a agrandi la partition pour occuper les 40 Go du disque. Sans --full, qm clone crée un clone lié à partir d'un modèle.

Pour un laboratoire, le même déploiement se scripte en boucle :

#!/usr/bin/env bash
# Déploie trois VM de TP, en clones liés du modèle 9000, dans le VLAN 10 (DHCP des postes)
set -euo pipefail
for i in 1 2 3; do
  vmid=$((300 + i))
  qm clone 9000 "$vmid" --name "tp-linux-$i"
  qm set "$vmid" --net0 virtio,bridge=vmbr0,tag=10 --ipconfig0 ip=dhcp
  qm start "$vmid"
done
qm list

Pour aller plus loin, on décrit les VM dans des fichiers et on laisse un outil les créer et les configurer : le cours Scripts PowerShell et Bash montre l'automatisation par scripts.

Un modèle Windows Server avec Sysprep

Windows n'a pas cloud-init en standard (l'équivalent existe avec Cloudbase-Init, à installer). La méthode classique est Sysprep, l'outil de Microsoft qui généralise une installation : il supprime le SID de la machine, son nom et ses pilotes spécifiques, puis éteint la machine. Au démarrage suivant, chaque clone repasse par l'écran de premier démarrage (OOBE) et reçoit un nouveau SID.

1. Crée la VM 9001 modele-ws2025 comme au chapitre 6, installe Windows Server 2025, les pilotes VirtIO et l'agent invité.
2. Installe les mises à jour et les réglages communs (fuseau horaire, Bureau à distance, pare-feu). Ne la joins pas au domaine et n'installe aucun rôle.
3. Lance Sysprep en tant qu'administrateur :

C:\Windows\System32\Sysprep\sysprep.exe /generalize /oobe /shutdown

4. Quand la VM s'est éteinte, ne la redémarre pas : convertis-la directement en modèle (qm template 9001).

Chaque clone démarre sur l'écran de premier démarrage : il reste à choisir la langue, le mot de passe administrateur, puis à le nommer, lui donner son adresse et le joindre au domaine. Un fichier de réponses (/unattend:C:\Windows\System32\Sysprep\unattend.xml), préparé avec l'outil Windows System Image Manager, automatise aussi ces étapes.

Généraliser un modèle Linux sans cloud-init

Si tu pars d'une installation Debian classique plutôt que d'une image cloud, généralise-la toi-même avant de la convertir en modèle :

apt clean
truncate -s 0 /etc/machine-id                 # régénéré au prochain démarrage
rm -f /var/lib/dbus/machine-id
rm -f /etc/ssh/ssh_host_*                     # clés d'hôte SSH supprimées
history -c
poweroff

Sur chaque clone, au premier démarrage, régénère les clés SSH avec dpkg-reconfigure openssh-server, puis change le nom d'hôte avec hostnamectl set-hostname. C'est exactement ce que cloud-init fait à ta place.

Exercices

qm clone 9000 189 --name srv-recette2 --full --storage truenas-nfs
qm set 189 --cores 2 --memory 4096
qm set 189 --net0 virtio,bridge=vmbr0,tag=21,firewall=1
qm set 189 --ipconfig0 ip=192.168.21.189/24,gw=192.168.21.254
qm disk resize 189 scsi0 30G
qm start 189