Un template Proxmox VE associé à Cloud-Init permet de déployer des machines virtuelles cohérentes sans répéter l’installation et la configuration de base à chaque création. L’image sert de référence, le template protège cette référence, puis les clones reçoivent leur réseau, leurs clés SSH et leurs paramètres propres au premier démarrage.

Cette approche ne transforme pas automatiquement toute image en VM prête à exploiter. Cloud-Init doit être présent et fonctionnel dans l’invité, un lecteur Cloud-Init doit être attaché, et les choix de stockage déterminent si les clones liés seront réellement utilisables.

Partir d’une image que l’on maîtrise

Cloud-Init est le paquet multi-distributions de référence pour l’initialisation précoce d’une machine virtuelle. Proxmox VE prépare les informations destinées à l’invité, notamment les interfaces réseau et les clés SSH. Au premier démarrage, Cloud-Init lit ces données et applique la configuration dans le système installé.

De nombreuses distributions publient des images Cloud-Init prêtes à l’emploi. Elles sont principalement conçues pour OpenStack, mais fonctionnent également avec Proxmox VE. C’est une base pratique pour un homelab ou un environnement de test, à condition de choisir une image d’une version encore prise en charge par sa distribution.

La documentation recommande néanmoins de préparer soi-même les images lorsque c’est possible. L’intérêt n’est pas théorique : on sait précisément quels paquets sont installés, quel comportement a été configuré, et quelles adaptations ont été introduites avant de figer le modèle. Une image inconnue ou trop générique devient vite une source d’écarts entre les VM.

Cette préparation constitue aussi le point de départ d’un déploiement piloté par code. Lorsqu’un environnement crée régulièrement des VM, il devient pertinent d’automatiser le déploiement du homelab en s’appuyant sur des modèles stables, plutôt que de reproduire manuellement une installation pour chaque besoin.

Préparer le modèle pas à pas

Deux chemins sont prévus. Le premier consiste à installer Cloud-Init dans une VM existante. Sur Debian ou Ubuntu, cette commande doit impérativement être exécutée dans l’invité, et non sur l’hôte Proxmox VE.

apt-get install cloud-init

Le second chemin consiste à importer une image cloud fournie par une distribution. Pour l’exemple Ubuntu retenu par la documentation, le contrôleur virtio-scsi-pci est requis pour les disques SCSI. L’ordre des opérations compte : la VM est créée, l’image est importée comme disque, puis les éléments nécessaires à Cloud-Init sont ajoutés.

  1. Créez la VM avec la mémoire, l’interface réseau VirtIO et le contrôleur SCSI approprié, puis importez l’image cloud sur le stockage prévu.
qm create 9000 --memory 2048 --net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-pci
qm set 9000 --scsi0 local-lvm:0,import-from=/chemin/vers/image.img
  1. Attachez le lecteur Cloud-Init, définissez le disque importé comme périphérique de démarrage et, si l’image le permet, activez une console série.
qm set 9000 --ide2 local-lvm:cloudinit
qm set 9000 --boot order=scsi0
qm set 9000 --serial0 socket --vga serial0
  1. Convertissez la VM préparée en template lorsqu’elle représente bien l’état de référence voulu.
qm template 9000

Le lecteur en ide2 n’est pas facultatif pour une VM Cloud-Init : Proxmox VE génère une image ISO pour transporter les informations de configuration. Une image contenant Cloud-Init mais dépourvue de ce lecteur ne recevra pas les données attendues. C’est une cause simple d’une VM qui démarre sans réseau configuré ni clé SSH injectée.

Technicienne avec une tablette à côté d'une rangée de petits serveurs identiques
Le modèle sert de référence : tout ce que l'on y installe se retrouve dans chaque clone.

La console série mérite aussi une vérification lors de la création du modèle. Beaucoup d’images Cloud-Init en dépendent, car il s’agit d’une exigence dans le contexte OpenStack. L’affichage série est donc généralement conseillé. Si une image ne se comporte pas correctement avec ce réglage, il faut revenir à l’affichage par défaut plutôt que de conserver une console qui masque les messages utiles.

Définir --boot order=scsi0 évite au BIOS de rechercher un support CD-ROM amorçable avant de démarrer sur le disque importé. Le lecteur Cloud-Init reste présent pour les données d’initialisation, mais n’est pas recherché comme support de démarrage. Ce réglage ne remplace pas la configuration du lecteur, il la complète.

Avant la conversion, il faut traiter le modèle comme une image de référence durable. Toute modification ultérieure de son contenu devra passer par un clone lié. Cette contrainte peut sembler stricte, mais elle évite qu’un démarrage ou une modification discrète dégrade la base utilisée par d’autres VM.

Un template n’est pas une VM ordinaire

Un template Proxmox VE est en lecture seule. Il ne peut pas être démarré, car un démarrage modifierait nécessairement ses disques. Cette propriété est précisément ce qui permet de l’utiliser comme origine fiable pour les clones liés.

Lorsqu’une correction doit être apportée au modèle, la méthode consiste à créer un clone lié, à modifier ce clone, puis à l’utiliser selon le besoin. Il faut donc prévoir la maintenance de l’image comme un cycle volontaire : image préparée, template figé, clone de travail pour les évolutions. Un template n’est pas un environnement de test que l’on démarre ponctuellement.

Deux modes de copie existent et ne répondent pas au même besoin.

Type de clone Relation avec l’original Stockage initial Conséquence principale
Clone complet Indépendant de l’original Copie de toutes les données Peut choisir le stockage cible et le format de disque, mais est généralement beaucoup plus lent à créer
Clone lié Référence l’image d’origine en copy-on-write Consommation initiale d’espace nulle Création quasi instantanée, mais dépendance durable au template et au pilote de stockage

Le clone complet ne partage aucune ressource de stockage avec la VM d’origine. Il est indépendant et permet de choisir un stockage cible ainsi que le format de disque. En contrepartie, il recopie toutes les données et sa création est généralement beaucoup plus lente qu’un clone lié.

Le clone lié est une copie inscriptible dont le contenu initial est identique à celui du template. Sa création est quasi instantanée et son besoin initial en espace est nul, car il référence encore l’image d’origine selon le principe du copy-on-write. Cette efficacité a une contrepartie directe : le template ne peut pas être supprimé tant que ces clones existent.

La fonction de clone lié dépend des pilotes de stockage modernes. Elle impose aussi que le volume d’origine soit en lecture seule, ce qui explique le rôle du template. Le stockage cible d’un clone lié ne peut pas être modifié : cette fonction est interne au stockage. Il ne faut donc pas considérer un clone lié comme une VM indépendante dont tous les déplacements seront possibles plus tard.

Réseau, identité et accès au premier démarrage

Une fois le template converti, le déploiement d’une nouvelle VM se limite à créer le clone, puis à lui attribuer les éléments qui l’identifient. Dans l’exemple documentaire, le clone reçoit un nom, une clé publique SSH et une configuration IPv4 avec passerelle.

qm clone 9000 123 --name ubuntu2
qm set 123 --sshkey ~/.ssh/id_rsa.pub
qm set 123 --ipconfig0 ip=10.0.10.123/24,gw=10.0.10.1

L’adressage de cet exemple doit évidemment être adapté à l’environnement réel. L’élément intéressant est la séparation entre le socle et l’identité : le template porte le système préparé, tandis que le clone reçoit ses paramètres d’accès et de réseau avant son premier démarrage.

Proxmox VE offre aussi un garde-fou lors de la duplication. Pour éviter les conflits de ressources, toutes les adresses MAC des interfaces sont rendues aléatoires lors du clonage. Un nouvel UUID est également généré pour le réglage BIOS smbios1. Le clone ne doit donc pas être vu comme une simple copie binaire de la VM source.

Cette distinction est utile lorsque l’on reprend une VM existante pour en faire une base. Une VM migrée depuis un autre hyperviseur peut servir de point de départ, mais elle doit d’abord devenir une image propre, avec Cloud-Init réellement opérationnel. Le guide pour migrer une VM VMware vers Proxmox VE traite la reprise des invités ; la transformation en template demande ensuite de vérifier les mécanismes propres à Proxmox VE.

Les options Cloud-Init à connaître

Les paramètres Cloud-Init sont attachés à la VM, donc au clone qui doit être démarré. Ils permettent de personnaliser une instance sans modifier l’image de référence. La liste suivante couvre les options documentées les plus utiles au quotidien.

L’authentification par clé SSH doit être privilégiée. Un mot de passe peut être défini, mais Proxmox VE doit alors stocker une version chiffrée du mot de passe dans les données Cloud-Init. L’option cipassword est généralement déconseillée, notamment parce que les anciennes versions de cloud-init ne gèrent pas les mots de passe hachés.

La conséquence pratique est simple : si l’objectif est un accès administrateur reproductible, une clé publique connue est plus cohérente qu’un mot de passe déposé dans la configuration de la VM. Le paramètre ciuser doit aussi correspondre à un compte que l’image et Cloud-Init peuvent effectivement traiter. Changer un nom dans Proxmox VE ne crée pas, à lui seul, une logique d’initialisation absente de l’image.

Des fichiers personnalisés, avec une contrainte de mobilité

cicustom permet de remplacer les fichiers que Proxmox VE génère automatiquement. Cela convient lorsqu’un fichier utilisateur, réseau, métadonnées ou fournisseur doit suivre une convention interne plus précise que les paramètres standard. Les types non remplacés continuent d’être générés automatiquement.

L’exemple documenté associe un fichier utilisateur stocké dans un espace de snippets :

qm set 9000 --cicustom "user=local:snippets/userconfig.yaml"

Avant d’écrire un fichier personnalisé, il est préférable de partir de la configuration que Proxmox VE produirait lui-même. La commande suivante permet d’exporter la partie utilisateur ; le même principe existe pour network et meta.

qm cloudinit dump 9000 user

Le piège est moins dans le contenu YAML que dans sa disponibilité. Le stockage contenant les snippets doit supporter ce type de contenu. Surtout, le fichier doit être disponible sur tous les nœuds vers lesquels la VM pourrait migrer. Un snippet présent sur le nœud d’origine mais absent du nœud de destination empêche la VM de démarrer.

Développeuse devant deux écrans affichant des fenêtres de code sombres
Les fichiers cicustom se versionnent comme du code, mais ils doivent exister sur chaque nœud.

Cette exigence relie directement Cloud-Init à la conception du cluster. La création d’un clone sur un autre nœud est possible avec l’option Target node, mais la VM doit être sur un stockage partagé également disponible sur le nœud cible. Ce n’est pas une simple question de confort d’administration : sans stockage accessible, le clonage ou le démarrage ne peut pas suivre le déplacement prévu.

Les contraintes à vérifier dans un environnement à plusieurs nœuds sont les suivantes :

Les mécanismes de quorum, de stockage partagé et de haute disponibilité ne sont donc pas séparés de la stratégie de templates. Le fonctionnement d’un cluster Proxmox VE avec quorum et haute disponibilité aide à poser le cadre, mais les fichiers Cloud-Init personnalisés doivent être intégrés à cette même réflexion.

Windows suit un chemin différent

Pour Windows, Proxmox VE s’appuie sur cloudbase-init, une réimplémentation de Cloud-Init. Toutes les fonctions disponibles côté Cloud-Init Linux ne sont pas nécessairement présentes. Il ne faut donc pas transposer mécaniquement un modèle Linux dans un invité Windows.

Il n’existe pas d’images cloud Windows gratuites prêtes à l’emploi dans ce cadre. L’invité doit être installé et configuré manuellement. La documentation précise de ne pas lancer Sysprep à la fin de l’installation avant d’avoir configuré cloudbase-init.

L’invité doit avoir un ostype Windows et utiliser citype=configdrive2, qui est le choix par défaut lorsque ostype correspond à Windows. L’ordre de configuration du mot de passe est sensible : ostype doit être réglé sur Windows avant de définir le mot de passe. Sinon, le mot de passe sera chiffré et cloudbase-init l’utilisera comme s’il s’agissait d’un mot de passe en clair.

Sans un réglage metadata_services adapté, la configuration du système peut prendre quelques minutes après le démarrage. Il faut intégrer ce comportement aux vérifications du modèle, plutôt que de conclure trop vite à une panne de l’invité ou du réseau.

Garder les modèles exploitables dans le temps

Un modèle est une dépendance de production dès lors qu’il alimente des clones liés. Le supprimer sans inventorier ses descendants est impossible, et modifier sa stratégie de stockage après coup peut devenir contraignant. Cette dépendance justifie une gestion distincte du template, de ses clones de travail et des images qui doivent rester disponibles.

La protection des modèles et des fichiers de configuration mérite la même attention que celle des VM déployées. Un plan de sauvegarde des machines virtuelles doit prendre en compte la valeur de la base de référence, mais aussi les éléments nécessaires à l’initialisation, notamment lorsque des snippets personnalisés sont employés.

Les incidents les plus concrets sont rarement liés à Cloud-Init lui-même. Une image peut ne pas contenir Cloud-Init, le lecteur cloudinit peut avoir été oublié, une console série peut ne pas convenir à l’image retenue, ou un snippet peut manquer sur un nœud de migration. Vérifier ces points avant de convertir en template évite de propager un défaut sur chaque clone.

Le bon template n’est donc pas l’image la plus chargée possible. C’est une base dont le contenu est compris, dont le démarrage est validé, dont les mécanismes Cloud-Init sont testés, et dont les dépendances de stockage restent compatibles avec les usages prévus. Les clones liés apportent alors leur principal avantage : déployer de nouvelles VM à partir d’une référence cohérente, tout en réservant les paramètres propres à chaque instance au premier démarrage.

Sources consultées