Créer une machine virtuelle à partir d'un modèle

Dans le guide précédent, vous avez configuré un tunnel IPv4 routé et un tunnel WireGuard : cinq adresses sont désormais accessibles via l'hôte Proxmox et acheminées vers sa première machine virtuelle. Pour mettre une deuxième machine virtuelle en ligne sans avoir à refaire toute la procédure d'installation, vous allez d'abord transformer la machine virtuelle déjà en cours d'exécution en un modèle réutilisable.

Convertir la machine virtuelle en modèle

Un modèle commence par être une machine virtuelle ordinaire, déjà installée, configurée et dont le bon fonctionnement a été vérifié : il s'agit de la même machine virtuelle que celle créée il y a deux guides. Sa conversion permet de figer cet état précis. Une fois qu'une machine virtuelle devient un modèle, Proxmox ne lui permet plus de démarrer de manière autonome ; elle n'existe plus que pour servir de base de clonage.

La machine virtuelle doit d'abord être arrêtée, car un modèle capture une image disque plutôt qu'un état d'exécution en temps réel. Le panneau de configuration de Proxmox propose cette opération en une seule étape : sélectionnez la machine virtuelle arrêtée dans l'arborescence de gauche, ouvrez « Plus » en haut à droite de sa page « Résumé », et l'option « Convertir en modèle » se trouve tout en haut de ce menu, le même menu auquel on accède directement en cliquant avec le bouton droit sur la machine virtuelle dans l'arborescence. La ligne de commande correspondante mérite également d’être connue, car c’est celle que tout script de provisionnement appelle en réalité dès lors que cette opération n’est plus ponctuelle :

qm template 100

Ce changement de nom est le mécanisme même qui sous-tend un modèle : le volume de disque lui-même devient base-100-disk-0, un support en lecture seule à partir duquel chaque clone futur effectue ses lectures, au lieu de le copier intégralement par défaut.

Non. Proxmox supprime complètement l'option « Démarrer » du menu propre au modèle, et le panneau affiche exactement ce qui reste à la place une fois que web01 a été modélisé :

L'option « Convertir en modèle » reste visible mais grisée : c'est la manière dont Proxmox indique que la machine virtuelle est déjà un modèle, plutôt que de masquer complètement l'option. L'arborescence de gauche illustre visuellement ce même fait : « web01 » conserve une simple icône en forme de boîte, tandis que « web02 » et « web03 », qui sont toutes deux des machines virtuelles ordinaires, affichent à la place une petite icône représentant un écran d'ordinateur. Le fichier de configuration confirme ce que le menu indique déjà : une nouvelle ligne, template: 1, figure dans /etc/pve/qemu-server/100.conf en plus de tout ce qui s'y trouve déjà.

Cloner le modèle

Le clonage est justement la raison d’être de la création d’un modèle de machine virtuelle. Au lieu de devoir passer par toutes les étapes de l’installateur (langue, clavier, partitionnement et tous les autres écrans décrits dans les deux guides précédents), un clone permet d’obtenir en quelques secondes une machine virtuelle opérationnelle et configurée de manière identique.

Choisissez entre un clone complet et un clone lié

En cliquant sur « Clone » dans ce même menu « More », on ouvre une petite boîte de dialogue plutôt qu’un nouvel assistant à huit onglets : un nœud cible, l’ID de la prochaine machine virtuelle disponible renseigné automatiquement, un champ « Nom » et un menu déroulant « Mode » qui propose un choix plus important qu’il n’y paraît.

Les options « Stockage cible » et « Format », toutes deux grises sur cette capture d'écran, ne s'activent que lorsque le mode passe en « Clonage complet » : un clone lié ne nécessite aucune décision indépendante en matière de stockage, il est toujours hébergé sur le même disque que celui du modèle.

• Clonage complet : une copie entièrement indépendante de chaque bloc présent sur le disque du modèle, allouée à partir de zéro sur le support de stockage de destination du clone. Une fois la copie terminée, aucune modification apportée au modèle ne peut plus l'affecter, au prix du temps nécessaire à la réalisation de cette copie : le clonage d'un disque de 16 Gio de cette manière a pris plus d'une minute.
• Clone lié : un instantané « léger » qui ne stocke que les modifications apportées au clone, en lisant directement depuis les blocs du modèle tout ce qui n'a pas été modifié. Le clonage de ce même disque de 16 GiB a pris moins de deux secondes, car rien n'avait encore été copié.

Lancer le clonage

Départ --full est activé par défaut sous forme de clone lié dès lors que le backend de stockage le prend en charge, ce qui local-lvm c'est ce qu'il fait ici. En nommant la nouvelle machine virtuelle « web02 », conformément au modèle déjà établi par « web01 », on assure la cohérence entre les deux :

qm clone 100 101 --name web02

Ces deux lignes d'AVERTISSEMENT méritent d'être lues plutôt que d'être ignorées : le pool de mémoire de ce laboratoire est réellement si restreint que Proxmox a raison de le signaler ; il s'agit du même avertissement que celui affiché par un nœud de production dès lors qu'il existe suffisamment de clones liés pour dépasser théoriquement sa propre capacité physique si chacun d'entre eux écrivait simultanément sur chaque bloc. Il s’agit d’une remarque relative à la planification de la capacité, décrivant ce qui se passerait dans le pire des cas, dont l’innocuité est ici confirmée par le temps réel écoulé indiqué juste en dessous.

Vérifier la relation dans LVM

La dépendance à laquelle cet avertissement fait référence est directement visible au niveau de la couche de stockage. Une requête sur les volumes logiques du groupe de volumes permet de l'afficher dans une seule colonne :

lvs -o lv_name,origin,lv_size pve

Cette colonne « Origin » constitue la preuve concrète, au niveau du stockage, de ce que signifie un clone lié : vm-101-disk-0 ne contient encore rien qui lui soit propre, hormis les modifications apportées par le système d'exploitation invité depuis la création du clone, et chaque bloc non modifié renvoie toujours vers base-100-disk-0.

Corriger ce que le clone partage encore avec le modèle

Proxmox ne génère aléatoirement que les éléments qu’il gère directement : une nouvelle adresse MAC sur net0, un nouvel UUID dans smbios1, un nouveau vmgenid. La comparaison côte à côte des deux fichiers de configuration montre exactement cela, et rien de plus :

web01 (100): net0 virtio=BC:24:11:40:09:E7   smbios1 uuid=8874d2ab-e9ec-4094-9b59-611829e70ccb
web02 (101): net0 virtio=BC:24:11:33:95:ED   smbios1 uuid=fd463a04-aa85-4015-9b6d-884d34db4b1c

En d'autres termes, tout ce que Proxmox suit en dehors du disque lui-même est déjà unique. Ce qui se trouve à l'intérieur de ce disque, c'est une autre histoire : le clone est une copie bit à bit du système de fichiers du modèle ; ainsi, tout ce que le système d'exploitation invité utilise pour s'identifier est transféré tel quel.

Oui, de deux manières concrètes. Le système systemd lui-même machine-id, censées être uniques à chaque installation, ainsi que toute clé d’hôte SSH générée lors de la configuration, restent intactes après un clonage, ce que confirment précisément le montage des deux disques en lecture seule et leur comparaison :

Un identifiant de machine partagé sème la confusion pour tout ce qui s'appuie dessus, du registre des machines de D-Bus lui-même à un client DHCP l'utilisant comme identifiant stable, tandis qu'un nom d'hôte partagé rend deux machines virtuelles indiscernables du point de vue d'un tableau de bord de surveillance. Dans les deux cas, il suffit de quelques commandes simples pour remédier au problème ; exécutez-les une seule fois dans le clone vierge avant même qu’il ne soit mis à la disposition d’un client :

rm -f /etc/machine-id
systemd-machine-id-setup
rm -f /etc/ssh/ssh_host_*
ssh-keygen -A
hostnamectl set-hostname web02

Cette dernière ligne doit également avoir son équivalent dans /etc/hosts, en associant le nouveau nom d'hôte à l'adresse de bouclage, de la même manière que le programme d'installation l'avait déjà configuré pour web01 il y a deux guides.

Automatiser le clonage dans le cadre d'un processus commercial

Aucune des étapes ci-dessus ne nécessite que l'utilisateur clique sur une boîte de dialogue, dès lors qu'il vaut la peine de les exécuter pour chaque machine virtuelle effectivement vendue par une plateforme. Il en va de même qm clone La commande accède directement à l'API Proxmox, la même API que celle déjà utilisée dans ce guide pour créer une machine virtuelle et récupérer une image ISO :

curl -k -X POST "https://pve.example.com:8006/api2/json/nodes/pve/qemu/100/clone" \
  -H "Authorization: PVEAPIToken=opsadmin@pve!automation=<token-secret>" \
  --data-urlencode "newid=102" \
  --data-urlencode "name=web03" \
  --data-urlencode "full=1"

Cet appel renvoie immédiatement un identifiant de tâche au lieu d'attendre la fin du clonage ; il s'agit du même modèle asynchrone qui sous-tend toutes les autres actions de longue durée dans Proxmox. Cet identifiant de tâche adopte un format fixe et reconnaissable :

UPID:pve:00002FD6:000590CA:6ABB8D48:qmclone:100:root@pam:

Sondage /nodes/pve/tasks/<that UPID>/status C'est d'ailleurs de cette manière qu'un script de provisionnement sait réellement qu'un clonage complet – qui prend plus d'une minute pour un disque de 16 GiB – est terminé, plutôt que de se baser sur un délai fixe.

Un script de provisionnement complet enchaîne ces quatre éléments dans l'ordre suivant : qm clone pour créer la machine virtuelle, le machine-id et une fois que les commandes relatives à la clé hôte SSH de la section précédente ont été exécutées à l'intérieur de celui-ci, une route est ajoutée pour l'adresse attribuée à ce client dans le pool du tunnel, et enfin qm start. Tout le processus, depuis le premier appel jusqu'à la réception par le client d'identifiants valides, se déroule de manière automatisée ; il s'agit de la même séquence que celle qu'un opérateur humain n'a effectuée manuellement que la première fois.