Créer un template Ubuntu Server sur Proxmox : cloner en quelques secondes

Ton Proxmox tourne. Tu as envie d’essayer un truc : un serveur de fichiers, un outil que tu as vu passer, un bout de code que tu préfères ne pas lancer sur ta machine principale. Alors tu repars pour un tour. Télécharger l’ISO, créer la VM, enchaîner les écrans de l’installateur, attendre, faire les mises à jour, réinstaller l’agent invité, reconfigurer SSH. Une demi-heure plus tard, tu peux enfin commencer ce que tu voulais faire.

Une demi-heure, ce n’est pas dramatique. Le problème n’est pas le temps que ça prend, c’est ce que ça t’enlève : l’envie d’essayer. Quand chaque test coûte trente minutes de mise en place, tu testes moins. Tu bricoles sur une VM existante au lieu d’en créer une propre. Tu gardes des machines sales parce que les refaire est pénible. Et petit à petit, ton homelab devient un endroit où tu as peur de casser quelque chose.

Un modèle inverse cette logique. Tu prépares une base propre une seule fois, et ensuite une nouvelle machine se crée en quelques secondes, déjà à jour, déjà accessible en SSH, avec son nom et son adresse. Une VM qui coûte dix secondes, c’est une VM que tu détruis sans hésiter. C’est là que ça devient intéressant : tu peux te tromper. Essayer un truc idiot, tout casser, recommencer. C’est exactement ce qui te rend autonome sur ta propre infrastructure, au lieu de dépendre d’une image toute faite téléchargée chez quelqu’un d’autre.

Dans cet article, on installe Ubuntu Server 26.04.1 dans une machine virtuelle, on la prépare, on la nettoie, puis on la transforme en modèle Proxmox. Et on finit par le vrai test : le premier clone, qui démarre avec son propre nom, sa propre identité et ta clé SSH déjà en place, sans jamais repasser par l’installateur.

Une précision avant de commencer : Ubuntu n’est pas un choix neutre. Derrière, il y a Canonical, une entreprise, avec Snap, Ubuntu Pro et quelques zones grises que je ne vais pas te cacher. On les regardera en face, et je te dirai dans quels cas Debian serait le meilleur choix. Ici on ne vend pas une distribution, on t’explique ce que tu installes.

Ce que cet article suppose

Que Proxmox tourne déjà chez toi, et que tu sais y créer une VM. Si ce n’est pas encore le cas, commence par l’article sur l’installation de Proxmox VE 9 , puis reviens ici : on part de ton tableau de bord et de rien d’autre. Pas besoin de connaître Ubuntu, ni la ligne de commande au-delà du copier-coller. On fera le maximum dans l’interface web, et le terminal ne servira que là où il n’y a pas d’autre chemin.

1. Pourquoi une VM serveur, pourquoi Ubuntu

Un serveur, ce n’est pas un ordinateur avec un écran

Sur ce blog, on a déjà installé Linux Mint dans une VM. Le but était différent : tu voulais un poste de travail, avec un bureau, des fenêtres, un navigateur. Une machine où tu passes du temps.

Un serveur, c’est l’inverse. Tu ne t’assieds jamais devant. Il tourne dans un coin, il rend un service, et tu t’y connectes à distance quand tu as besoin de lui. Alors on enlève tout ce qui ne sert qu’à un humain assis devant un écran : le bureau, les icônes, le son, les applications graphiques.

Ce qu’on y gagne est concret. Ubuntu Desktop réclame 6 Go de RAM pour être confortable ; la version serveur démarre à 1,5 Go. Sur un homelab où tu fais tourner plusieurs machines sur le même matériel, c’est ce qui fait la différence entre trois VM et huit. Et moins de logiciels installés, ça veut dire moins de choses à mettre à jour, moins de bugs possibles, moins de portes d’entrée.

En échange, tu perds le confort : plus de souris, plus de fenêtre, un écran noir avec du texte. C’est déstabilisant les premières fois. Mais tu vas t’apercevoir d’une chose : une fois la machine en route, tu n’ouvres presque plus jamais sa console. Tu t’y connectes en SSH depuis ton PC, dans ton terminal habituel, et c’est tout.

Pourquoi Ubuntu Server

Ubuntu Server 26.04.1, sortie en avril 2026 et rafraîchie en août, est une version LTS : maintenance de sécurité assurée pendant cinq ans. Tu l’installes aujourd’hui, elle reste sûre jusqu’en 2031 sans rien réinstaller. Pour une machine que tu veux oublier, c’est exactement ce qu’il faut.

Mais la vraie raison est ailleurs, et elle est moins noble : Ubuntu est la distribution la plus documentée du monde. Quand un projet t’affiche une seule ligne d’installation, elle est écrite pour Ubuntu. Quand tu colles ton message d’erreur dans un moteur de recherche, les réponses parlent d’Ubuntu. Quand un tuto suppose quelque chose, il suppose Ubuntu.

Ça n’a l’air de rien. En pratique, quand tu débutes, c’est ce qui décide si tu t’en sors seul ou si tu abandonnes à la première erreur. Choisir la distribution la plus entourée n’est pas un manque d’ambition, c’est une façon de mettre les chances de ton côté pendant que tu apprends.

Ce qu’on te dit rarement

Ubuntu n’est pas un projet communautaire pur. Derrière, il y a Canonical, une entreprise britannique qui doit gagner de l’argent. Ça se voit à trois endroits.

Snap. Canonical a créé son propre format de paquets, concurrent de ce qui existait déjà. Snap est installé d’office et ne se retire pas d’un clic. Sur ta VM fraîchement installée, des snaps tournent déjà sans que tu aies rien demandé. Rien de dramatique, mais c’est un choix fait à ta place.

La couverture réelle des mises à jour. Les cinq ans de sécurité annoncés ne couvrent que le dépôt principal, celui du système de base. Tout ce que tu installeras ensuite vient souvent d’un second dépôt, Universe, qui n’a aucune garantie de sécurité. Pour l’étendre, il faut Ubuntu Pro.

Ubuntu Pro. C’est gratuit pour un usage personnel, jusqu’à cinq machines physiques avec autant de VM que tu veux dessus. Mais gratuit ne veut pas dire sans contrepartie : il faut créer un compte Ubuntu One et rattacher chaque machine. Tu échanges de la sécurité contre de l’identification. Chaque fois que tu te connecteras à ta VM, un message te le rappellera :

La maintenance de sécurité étendue pour Applications n'est pas activée.
Activez ESM Apps pour recevoir des futures mises à jour de sécurité supplémentaires.
Visitez https://ubuntu.com/esm ou executez : sudo pro status

Ce n’est pas un scandale, c’est un modèle économique. Mais tu le sais maintenant, et c’est toi qui décides.

Dans quels cas Debian vaut mieux

Ce tableau ne désigne pas de gagnant, il t’aide à choisir. Prends Debian si tu veux zéro compte, zéro entreprise dans la boucle et un système minimal. Prends Ubuntu si tu veux que la moindre recherche te donne une réponse applicable.

Et si Debian te tente, tu en as déjà un sous les yeux : Proxmox lui-même est construit dessus. L’interface web que tu utilises tourne sur un Debian.

Ce qu’on fait ici

On prend Ubuntu Server, sans Ubuntu Pro. C’est le chemin le plus court vers une machine qui marche et sur laquelle tu trouveras de l’aide.

Et la méthode qui suit ne dépend pas de ce choix. Le modèle, le nettoyage, le clonage : tout fonctionne à l’identique avec Debian. Si tu changes d’avis dans six mois, tu ne repartiras pas de zéro.

2. Créer la VM dans Proxmox

On va créer une machine vide, puis lui faire installer Ubuntu. Deux étapes séparées : d’abord la coquille, ensuite le système.

Récupérer l’image d’installation

Proxmox sait télécharger l’ISO tout seul, tu n’as pas besoin de passer par ton PC.

Tout ce qui concerne Ubuntu 26.04 vit dans un seul dossier, chez Ubuntu :

https://releases.ubuntu.com/resolute/

resolute est le nom de code de la 26.04. Cette adresse ne bouge pas pendant toute la vie de la version. Ce qui change, c’est le contenu : à chaque mise à jour de l’image, le numéro du fichier avance, 26.04, puis 26.04.1, et ainsi de suite. Tu y prends deux choses.

L’image. Celle qui s’appelle live-server-amd64, la version serveur, sans interface graphique. Au moment où j’écris, c’est ubuntu-26.04.1-live-server-amd64.iso. Copie son adresse depuis la page, ne recopie pas la mienne : clic droit sur le lien, Copier le lien.

Son empreinte. Dans le même dossier, en haut de la liste des fichiers, tu trouves SHA256SUMS.

Ce fichier s’ouvre directement dans ton navigateur. C’est du texte brut, une ligne par image, sous la forme empreinte *nom-du-fichier.iso. Repère la ligne dont le nom correspond exactement à ton image, attention aux versions desktop et aux anciennes, et copie uniquement la longue suite de caractères, sans l’astérisque ni le nom du fichier.

Juste à côté, tu verras un fichier SHA256SUMS.gpg. C’est la signature de la liste d’empreintes : elle prouve que cette liste vient bien de Canonical et n’a pas été remplacée en cours de route. La vérifier demande de manipuler des clés de signature, un sujet à part entière qu’on ne fera pas ici. Sache simplement que cette étape existe, et qu’elle est le cran au-dessus.

Ensuite, dans Proxmox : arborescence de gauche, déplie ton nœud, stockage local, puis ISO Images. Bouton Download from URL, colle l’adresse de l’image, puis Query URL : Proxmox interroge le serveur et remplit le nom du fichier.

Déplie Advanced avant de lancer : algorithme SHA-256, et l’empreinte que tu viens de relever dans le champ Checksum. Prends-la toujours chez l’éditeur, jamais dans un tuto, le mien compris.

Ce n’est pas décoratif. Une empreinte est la signature du fichier : si un seul octet diffère de l’original, elle ne correspond plus. Tu vérifies ainsi que rien n’a été altéré en route ni corrompu par un transfert qui a mal tourné. Sur une machine à qui tu vas confier des données, c’est le minimum.

Puis Download. Le téléchargement se fait de serveur à serveur, sans passer deux fois par ta connexion domestique. À la fin, Proxmox te dit lui-même si le compte est bon.

L’image apparaît alors dans la liste des ISO du stockage local.

Créer la machine

Bouton Create VM en haut à droite. Six onglets, et je ne commente que ce qui compte.

General. Donne un nom court, sans point ni espace. Ici, ce sera Ubuntu-serveur. Retiens ce détail du point, on verra plus loin qu’il a des conséquences inattendues. Note aussi le numéro de VM proposé, tu en auras besoin.

OS. Sélectionne l’ISO que tu viens de télécharger. Type : Linux. La version proposée par défaut convient.

System. Deux réglages ici.

• SCSI Controller : laisse VirtIO SCSI single, le contrôleur de disque le plus performant pour un invité Linux.
• Qemu Agent : coche la case. Elle prépare le canal de communication entre Proxmox et la machine. On installera le logiciel correspondant à l’intérieur plus tard ; sans cette case, il ne servirait à rien.

Le BIOS reste sur Default (SeaBIOS). L’UEFI fonctionne aussi mais demande un disque supplémentaire, sans bénéfice ici.

Disks. 32 Go suffisent largement pour un système sans bureau. Coche Discard : quand tu supprimes des fichiers dans la VM, l’espace est réellement rendu au stockage de l’hôte. Sans ça, le disque virtuel ne fait que grossir.

CPU. 2 cœurs suffisent pour commencer.

Memory. 2048 Mo. On pourra ajuster plus tard, et surtout chaque clone pourra avoir sa propre taille.

Network. Laisse le modèle VirtIO. Si tu as segmenté ton réseau en VLAN, c’est ici que tu indiques le numéro de la zone où la machine doit vivre, au champ VLAN Tag, sur le bon pont. Sinon, laisse le champ vide.

Dernier écran, Confirm, qui récapitule tout. Clique sur Finish, sans cocher « Start after created ». On regarde d’abord.

Vérifier avant de démarrer

Sélectionne ta nouvelle VM, onglet Hardware. Tu dois voir le disque, la carte réseau, le lecteur CD/DVD pointant sur l’ISO, et rien d’autre d’inattendu. C’est le bon moment pour corriger, ça devient plus pénible ensuite.

Onglet Options, ligne Boot Order : le disque doit être présent et le lecteur CD aussi, puisqu’on va démarrer dessus.

Démarre la machine avec Start, puis ouvre Console. L’installateur se lance sur le menu de démarrage.

Le piège de la console

La console web de Proxmox capture ton clavier et ta souris. Certaines combinaisons de touches vont à la VM, d’autres à ton navigateur, et le copier-coller ne traverse pas. C’est normal. Dès qu’on aura SSH, on abandonnera cette console pour de bon.

3. Installer Ubuntu Server

L’installateur est en mode texte, sans souris. Tu navigues entièrement au clavier :

• Flèches : se déplacer dans les champs et les listes
• Tab : passer d’un champ à l’autre
• Espace : cocher une case
• Entrée : valider

Compte une quinzaine de minutes, dont la moitié à attendre.

Langue et clavier

Premier écran, la langue de l’installateur. Prends Français si tu veux, mais garde en tête un détail : la quasi-totalité de la documentation et des messages d’erreur que tu croiseras ensuite sont en anglais. Un système en anglais te donne des messages qu’on peut chercher tels quels dans un moteur de recherche. C’est mon choix sur les machines serveur, et ce n’est pas une coquetterie.

Écran suivant, le clavier. Là, en revanche, prends bien French et la variante qui correspond à ton matériel. Sinon tu taperas des q en croyant faire des a, et ton mot de passe ne passera jamais.

L’installateur te demande ensuite quel type d’installation tu veux. Prends Ubuntu Server, pas la version minimisée. Cette dernière retire des outils que tu utiliserais plus tard sans savoir pourquoi ils manquent.

Le réseau, et le piège de la traduction

L’écran réseau affiche ta carte, nommée ens18, et tente une configuration automatique. Deux cas.

Si un serveur DHCP répond sur ce réseau, une adresse s’affiche, tu n’as rien à faire.

Si tu utilises des adresses fixes, comme dans mes zones Admin et Serveurs, sélectionne la carte, puis Edit IPv4, et passe la méthode sur Manuel.

Si tu as segmenté ton réseau en VLAN

Le numéro de VLAN, tu l’as déjà donné dans Proxmox, au champ VLAN Tag de la carte réseau de la VM. Ça, c’est fait, et ça ne se refait pas ici : l’installateur ne connaît rien aux VLAN, il voit juste un réseau.

Ce que tu dois vérifier ici, c’est que l’adresse corresponde à la zone. Ta machine est taguée dans une zone précise, elle doit donc recevoir une adresse de cette zone-là. Une VM taguée en 192.168.20.0/24 à qui tu donnes une adresse en 192.168.1.0/24 reste muette, sans le moindre avertissement de l’installateur. Si ta machine ne répond à rien, commence par là.

Avant de valider cet écran, retourne donc voir le VLAN Tag de ta VM dans Proxmox, et assure-toi que l’adresse, le réseau en CIDR, la passerelle et le DNS appartiennent tous à cette zone. Trente secondes de vérification contre une demi-heure de recherche à l’aveugle.

Et là, un piège que je n’ai vu signalé nulle part.

« Masque de sous-réseau » ne veut pas dire masque

Le champ ainsi traduit n’attend pas 255.255.255.0. Il attend l’adresse de ton réseau en notation CIDR, celle de la zone où vit la machine : 192.168.20.0/24 dans mon cas. Si tu y mets un masque, l’installateur t’affiche en rouge que ton adresse n’est pas contenue dans le réseau, et tu peux y passer un moment avant de comprendre que c’est la traduction qui te ment.

Remplis donc ainsi : le réseau en CIDR dans le premier champ, l’adresse de ta machine dans Adresse, puis ta passerelle, celle de la zone concernée.

Serveurs DNS. Ne laisse pas ce champ vide, sinon l’installateur ne pourra pas joindre les dépôts et la suite échouera sans raison apparente. Si tu as monté un Pi-hole, c’est son adresse que tu mets ici, et rien d’autre : ta machine sera filtrée comme le reste de ton réseau, et tu verras ses requêtes remonter dans le tableau de bord. Sinon, mets l’adresse de ta passerelle, ou un résolveur public si tu n’en as pas encore.

Un point à garder en tête pour la suite : ce réglage DNS ne survivra pas non plus au passage en modèle. Les clones recevront le leur depuis Proxmox, et on verra ça en section 5.

Retiens le nom ens18. Il va changer plus tard, et ça surprend.

Proxy, miroir, disque

Le proxy, tu laisses vide. Le miroir de téléchargement, tu laisses ce qui est proposé, l’installateur choisit un serveur proche.

Pour le disque, laisse l’option par défaut, qui utilise le disque entier avec un découpage en LVM.

Et là, une remarque qui surprend tout le monde au premier passage. Sur mon disque de 32 Go, Ubuntu n’attribue que 15 Go à la racine et laisse le reste inutilisé dans le groupe LVM.

Ce n’est pas un bug, c’est une marge que LVM te réserve pour agrandir plus tard ou prendre des instantanés. Si tu veux tout l’espace tout de suite, sélectionne le volume ubuntu-lv dans cet écran et agrandis-le. Sinon, laisse : tu pourras le faire à chaud, plus tard, sans rien casser. Mais sache-le maintenant plutôt que de te demander dans six mois où est passée la moitié de ton disque.

L’écran suivant te demande de confirmer. À partir de là, le disque est écrit.

Ton compte

L’installateur demande ton nom, un nom pour la machine, un identifiant et un mot de passe. Ici, l’identifiant sera hmt et la machine s’appellera server-demo.

Ce compte a une particularité que je préfère t’annoncer maintenant plutôt que te laisser buter dessus : il ne survivra pas à la transformation en modèle. On verra pourquoi à la section 5. Choisis donc quelque chose de simple, tu n’auras pas à t’en souvenir longtemps.

Le nom de la machine, en revanche, tu peux le laisser générique. Chaque clone recevra le sien automatiquement.

L’écran suivant te propose d’activer Ubuntu Pro. On en a parlé en section 1 : ici, Skip for now. Tu pourras toujours l’activer plus tard si tu changes d’avis.

Le seul écran où il ne faut pas se tromper

Installer le serveur OpenSSH : coche la case. C’est ce qui te permettra de quitter la console de Proxmox et de travailler depuis ton terminal. Si tu l’oublies, tu devras l’installer ensuite à la main, dans une console inconfortable.

L’écran suivant propose des snaps prêts à l’emploi : Kubernetes, Nextcloud, des outils de supervision, des bases de données. N’en coche aucun. On veut une base propre, et ce qui s’installe ici s’installera dans tous tes futurs clones, que tu en aies besoin ou non.

Fin d’installation

L’installation se déroule, les journaux défilent. À la fin, un message propose de redémarrer.

Au redémarrage, la machine peut se bloquer sur un message demandant de retirer le média d’installation et d’appuyer sur Entrée. C’est normal. Retourne dans Hardware, ligne CD/DVD, Edit, et choisis Do not use any media. Puis appuie sur Entrée dans la console.

Au tout premier démarrage, tu verras défiler la génération des clés d’hôte SSH de la machine. Retiens cet écran, on en reparlera au moment du clonage.

Ta machine démarre et s’arrête sur une invite de connexion. Entre ton identifiant et ton mot de passe. Tu es dedans.

4. Premier accès SSH et mises à jour

Quitter la console

La console de Proxmox t’a dépanné pendant l’installation, mais on ne va pas y rester. Elle est lente, elle capture ton clavier, et le copier-coller n’y passe pas. Un serveur se pilote depuis ton terminal habituel, en SSH. C’est d’ailleurs pour ça qu’on a coché OpenSSH pendant l’installation.

Depuis ton PC, ouvre un terminal et connecte-toi :

ssh hmt@192.168.20.100

Ici, hmt est le compte créé pendant l’installation et 192.168.20.100 l’adresse de la machine. Chez toi, remplace par tes propres valeurs. Si tu as oublié l’adresse, tu la retrouves dans la console avec ip a.

La première fois, SSH affiche l’empreinte de la machine et te demande si tu l’acceptes. Tape yes en toutes lettres, puis ton mot de passe. Tu es connecté, et l’invite affiche désormais le nom de ta machine.

Cette empreinte, tu la reverras

SSH vient de mémoriser l’identité de ta machine dans le fichier ~/.ssh/known_hosts. À partir de maintenant, si cette identité change, SSH refusera la connexion en hurlant. C’est le comportement voulu : ça te protège d’une machine qui se ferait passer pour la tienne.

Retiens-le, parce qu’on va justement provoquer ce changement en section 5 : chaque clone reçoit ses propres clés d’hôte. Quand ton premier clone te renverra cette alerte, tu sauras que tout fonctionne normalement.

Mettre le système à jour

Une image d’installation, même téléchargée hier, a du retard sur les correctifs de sécurité. On rattrape tout de suite :

sudo apt update && sudo apt full-upgrade -y

Deux commandes enchaînées. apt update rafraîchit la liste de ce qui est disponible dans les dépôts. apt full-upgrade applique réellement les mises à jour.

Le full n’est pas décoratif. Contrairement à un simple upgrade, il autorise l’installation de nouveaux paquets et le retrait d’anciens quand une mise à jour l’exige. C’est exactement ce qui se passe lors d’un changement de noyau, et un serveur qui refuse ses mises à jour de noyau est un serveur qui accumule des failles.

Si le noyau a été mis à jour, la machine a besoin d’un redémarrage pour l’utiliser. Le système te le signale. Dans ce cas :

sudo reboot

Ta session SSH se coupe, c’est normal. Attends une vingtaine de secondes et reconnecte-toi.

Installer l’agent invité

Souviens-toi : à la création de la VM, on a coché la case Qemu Agent dans l’onglet System. Côté Proxmox, cette case ouvre un canal de communication avec la machine. Mais le canal ne sert à rien tant que personne ne répond de l’autre côté. C’est le rôle de l’agent invité, qu’on installe maintenant :

sudo apt install qemu-guest-agent -y

Ce petit service permet à Proxmox de parler à la machine plutôt que de deviner ce qu’elle fait. Concrètement, tu y gagnes trois choses : l’adresse IP de la VM affichée dans son résumé, un arrêt propre quand tu cliques sur Shutdown, parce que l’agent demande au système de s’éteindre au lieu de couper le courant, et des sauvegardes cohérentes, parce que l’agent peut mettre les écritures disque en pause le temps de l’instantané.

L’erreur que tu vas lire partout

Beaucoup de tutoriels te font enchaîner avec sudo systemctl enable --now qemu-guest-agent. Essaie, et tu récupères un message d’erreur : le service est refusé à l’activation.

Ce n’est pas un bug, et tu n’as rien cassé. Cette unité est déclarée static : elle n’est pas prévue pour être activée à la main. Elle se déclenche toute seule dès que le système détecte le canal virtio que Proxmox a ouvert quand tu as coché la case. Autrement dit, si la case est cochée côté Proxmox, l’agent démarre. Si elle ne l’est pas, aucune commande ne le fera démarrer.

La vraie vérification n’est donc pas dans le terminal, elle est dans l’interface web. On y va tout de suite.

Pendant qu’on est là, un coup de balai sur les paquets devenus inutiles après les mises à jour, notamment les anciens noyaux :

sudo apt autoremove --purge -y

Vérifier que l’agent répond

Retourne dans l’interface web de Proxmox, sélectionne ta VM, onglet Summary. Regarde la ligne IPs.

Si l’adresse de ta machine s’affiche, l’agent fonctionne et le canal est opérationnel. Avant l’installation, Proxmox affichait un message indiquant qu’il n’avait aucune information, faute d’agent. Maintenant il voit l’intérieur de la machine.

Si rien ne s’affiche encore, vérifie dans l’ordre : l’onglet Options de la VM, ligne QEMU Guest Agent, doit être sur Enabled. Si tu viens seulement de l’activer, un simple redémarrage depuis l’interface ne suffit pas : il faut un arrêt complet puis un démarrage, parce que le matériel virtuel n’est recréé qu’au démarrage de la machine.

À ce stade, tu as une VM Ubuntu Server à jour, accessible depuis ton terminal, et visible de l’intérieur par Proxmox. C’est une machine utilisable. Le problème, c’est qu’elle est unique. En section 5, on en fait un moule.

5. Transformer la VM en modèle et cloner

Ta VM fonctionne. Le problème, c’est qu’elle est unique, et surtout qu’elle est pleine d’identifiants qui devaient rester uniques. Si tu la clonais tout de suite, tu obtiendrais deux machines qui se croient la même, et le résultat n’est pas « ça marche à peu près ». C’est deux serveurs qui se disputent la même adresse IP.

Cette section fait trois choses :

• Effacer l’identité de la machine.
• Lui greffer un mécanisme qui en fabriquera une neuve à chaque clone.
• La verrouiller en modèle.

Relever l’état actuel

Avant d’effacer, on prend une photo. Ça ne sert à rien techniquement, mais ça sert à te prouver que la suite fonctionne. Depuis ta session SSH :

cat /etc/machine-id
hostname
ip a | grep "inet "

Note ce que tu obtiens quelque part. Sur ma machine de démonstration, le machine-id commençait par 967e1588. On comparera tout à l’heure.

Effacer l’identité de la machine

Une commande, et elle mérite qu’on la découpe :

sudo cloud-init clean --logs --machine-id --seed

Cette commande fait le ménage que Proxmox ne fait pas. Elle vide les journaux, remet le machine-id dans un état non initialisé, et supprime les données locales qui feraient croire à la machine qu’elle a déjà été configurée.

Pourquoi le machine-id est le vrai piège

Proxmox change beaucoup de choses au clonage : nouvelle adresse MAC, nouvel identifiant matériel. Il ne touche pas au machine-id, qui vit à l’intérieur du système.

Or sur Ubuntu, c’est ce fichier qui sert d’identifiant au client DHCP. Deux clones avec le même machine-id demandent la même adresse au serveur DHCP, et l’obtiennent. Tu te retrouves avec deux machines sur la même IP, et un réseau qui se comporte de façon incompréhensible.

C’est la raison d’être de l’option --machine-id, recommandée par la documentation officielle de cloud-init. Sans elle, ton modèle fabrique des jumeaux qui se marchent dessus.

Il y a un second ménage que cette commande fait, et qu’il faut comprendre. L’installateur d’Ubuntu désactive délibérément Cloud-Init une fois l’installation terminée : il dépose un fichier cloud-init.disabled et des réglages qui neutralisent le système. Canonical assume ce choix, une machine installée à la main n’a rien à faire d’un outil de configuration automatique. La commande cloud-init clean retire ces verrous. C’est ce qui permet à Cloud-Init de reprendre du service au prochain démarrage, cette fois pour configurer les clones.

Autre chose part au passage : le fichier de configuration réseau que tu as rempli pendant l’installation. Adresse, passerelle, DNS, tout est effacé. C’est voulu. À partir de maintenant, c’est Cloud-Init qui décidera du réseau, clone par clone.

Éteindre, ne jamais redémarrer

Point critique :

sudo shutdown now

Éteindre, pas redémarrer. Si tu fais reboot, la machine se rallume, constate qu’elle n’a plus d’identité, et s’en fabrique une nouvelle sur-le-champ. Ton nettoyage est annulé, et tu ne t’en rendras compte que le jour où deux clones se battront pour la même IP. Tu devrais alors tout recommencer.

La machine est éteinte. Elle ne se rallumera plus jamais sous cette forme.

Détacher l’image d’installation

Dans l’interface web, sélectionne la VM, onglet Hardware, ligne CD/DVD Drive. Clique Edit, puis coche Do not use any media.

Si tu l’as déjà fait en fin d’installation, tant mieux, vérifie simplement. Un modèle qui traîne une ISO derrière lui la transmettra à tous ses clones.

Fabriquer ta paire de clés

Sur ce point précis, pas d’interface web possible : une clé se génère en local, sur ta propre machine, et elle ne doit jamais transiter par ailleurs. C’est une des rares fois où le terminal est le seul chemin.

Le principe d’abord, parce qu’il conditionne tout le reste. Une clé SSH n’est pas un fichier, c’est une paire de fichiers indissociables. La clé privée reste chez toi, pour toujours, et ne se copie nulle part. La clé publique se distribue librement : c’est elle que tu colles dans Proxmox, et elle sera déposée sur chaque clone. Le serveur pose une question que seul le détenteur de la clé privée peut résoudre. Personne n’a besoin de connaître ton secret pour vérifier que tu le possèdes.

Ouvre un terminal sur ton PC. Sous Linux ou macOS, c’est ton terminal habituel. Sous Windows, PowerShell suffit, le client OpenSSH y est installé d’office depuis Windows 10.

Vérifie d’abord si tu en as déjà une :

ls -l ~/.ssh/

Si tu vois un couple id_ed25519 et id_ed25519.pub, tu as déjà tout ce qu’il faut, saute la génération. Si le dossier n’existe pas ou qu’il est vide, on la crée :

ssh-keygen -t ed25519 -C "homelab"

L’option -t ed25519 choisit l’algorithme. C’est celui à utiliser aujourd’hui : plus court, plus rapide et plus solide que le RSA que tu croiseras encore dans de vieux tutoriels. L’option -C ajoute un simple commentaire en fin de clé publique, qui t’aidera à reconnaître ce qu’elle est le jour où tu en auras plusieurs.

Trois questions te sont posées.

L’emplacement du fichier. Appuie sur Entrée pour accepter la proposition, ~/.ssh/id_ed25519. Ne change ce chemin que si tu as déjà une clé que tu ne veux pas écraser.

Une phrase de passe. Elle chiffre ta clé privée sur ton disque. Sans elle, quiconque met la main sur ton fichier obtient l’accès à tous tes serveurs. Avec elle, il lui faut aussi la phrase. Mets-en une. Tu ne la retaperas pas à chaque connexion si ton système gère un agent SSH, ce qui est le cas par défaut sur les bureaux Linux et macOS.

Sa confirmation. Rien à ajouter.

Tu obtiens deux fichiers :

Sauvegarde-la maintenant

Ta clé privée est la seule porte d’entrée de tes futurs clones. Le compte d’installation n’aura plus de mot de passe, et la console locale ne te servira à rien. Perdre ce fichier, c’est perdre l’accès à toutes les machines qui en sortiront.

Copie le dossier ~/.ssh dans ton gestionnaire de mots de passe ou sur un support chiffré, avant d’aller plus loin. Pas après.

Affiche maintenant la clé publique :

cat ~/.ssh/id_ed25519.pub

C’est cette ligne entière que tu vas coller dans Proxmox. Elle commence par ssh-ed25519, elle finit par ton commentaire, et elle tient sur une seule ligne. Sélectionne-la du premier au dernier caractère, sans retour à la ligne, sans espace en trop.

Si ton terminal la coupe en plusieurs morceaux à l’affichage, ce n’est qu’un effet de la largeur de ta fenêtre, le fichier ne contient bien qu’une ligne.

Une erreur à ne pas commettre : ne colle jamais le contenu de id_ed25519, celui sans .pub. Il commence par -----BEGIN OPENSSH PRIVATE KEY-----. Si tu vois ça, tu es en train de diffuser ton secret. Recommence avec le bon fichier.

Ajouter le lecteur Cloud-Init

C’est la pièce qui manque. Toujours dans Hardware, clique Add, puis CloudInit Drive. Choisis ton stockage, valide.

Sur quel emplacement ?

Proxmox te propose un emplacement libre, et dans notre cas ce sera ide0. Ce n’est pas un choix arbitraire : ide2 est déjà occupé par le lecteur de CD virtuel, celui dans lequel on avait glissé l’ISO d’installation. Proxmox prend donc le premier créneau disponible.

Peu importe le numéro. Ce qui compte, c’est de comprendre ce que tu viens de brancher : un disque virtuel minuscule, sur lequel Proxmox écrira un fichier de configuration que la machine lira à chaque démarrage. Tout le mécanisme est là. Proxmox écrit dehors, le système lit dedans.

Un nouvel onglet est apparu dans le menu de gauche de la VM : Cloud-Init. C’est là qu’on renseigne ce que les clones devront appliquer.

Renseigner les paramètres Cloud-Init

Ouvre l’onglet Cloud-Init. Il est encore presque vide.

Remplis-le ainsi :

User : admin. C’est le compte qui sera créé sur chaque clone au premier démarrage.

SSH public key : colle la ligne obtenue plus haut. Proxmox propose également un bouton Load SSH Key File, qui charge directement ton fichier .pub depuis ton disque et évite tout risque de copier-coller approximatif.

Password : laisse vide. La documentation de Proxmox recommande explicitement l’authentification par clé. Un mot de passe stocké dans le modèle serait le même sur tous les clones, ce qui est exactement ce qu’on cherche à éviter.

Upgrade packages : laisse sur Yes, c’est la valeur par défaut. À chaque premier démarrage, le clone appliquera les mises à jour disponibles avant que tu t’y connectes. C’est une réponse partielle au vieillissement du modèle : même créé il y a six mois, un clone naît à jour. Compte simplement une ou deux minutes de plus au premier boot, le temps que le travail se fasse.

IP Config : laisse en DHCP pour l’instant. On le modifiera clone par clone.

Le compte d’installation vient de mourir

Le compte hmt que tu as créé pendant l’installation existe toujours sur le disque, mais le nettoyage lui a retiré son mot de passe. Concrètement : tu ne peux plus te connecter avec depuis la console de Proxmox. Tu n’as pas perdu la machine, mais tu as changé de porte d’entrée.

À partir de maintenant, l’accès se fait exclusivement en SSH, avec le compte admin et ta clé. Si tu perds cette clé, tu perds tes clones. Sauvegarde-la avant d’aller plus loin.

Si tu te retrouves quand même coincé devant une console qui ne veut pas de toi, il reste une porte de secours : renseigne un mot de passe temporaire dans l’onglet Cloud-Init du clone concerné, clique sur Regenerate Image, et redémarre la machine. Elle t’acceptera. Pense à retirer ce mot de passe du modèle ensuite.

Convertir en modèle

Clic droit sur la VM dans l’arborescence, Convert to template. Confirme.

L’icône change dans l’arborescence. La VM ne peut plus démarrer, et son disque passe en lecture seule. C’est précisément ce qui rend possible le clonage rapide : plus personne ne peut modifier l’original.

Profites-en pour renommer proprement, onglet Options, ligne Name. Ici, la machine devient Ubuntu-serveur-template.

Pas de point dans le nom

Un nom de VM contenant un point est tronqué au premier point quand Cloud-Init l’applique comme nom de machine. Une VM nommée serveur-1.23 produit un clone qui se croit appelé serveur-1. Tirets et chiffres uniquement.

Cloner

Clic droit sur le modèle, Clone.

Trois champs comptent :

Name : le nom du nouveau serveur, sans point.

Mode : Linked Clone ou Full Clone.

Le clone lié ne copie rien, il pointe vers le disque du modèle et n’écrit que ses propres différences. Il est créé en une poignée de secondes et occupe presque rien. La contrepartie : il dépend du modèle à vie, et tu ne pourras pas supprimer le modèle tant qu’un clone lié existe.

Le clone complet copie l’intégralité du disque. Plus long, plus volumineux, totalement indépendant.

Pour du test et du jetable, prends le clone lié : c’est tout l’intérêt de la manœuvre. Pour un service que tu comptes garder des années, prends le clone complet.

Avant de démarrer le clone, va dans son onglet Cloud-Init et ajuste. Pour une adresse fixe, clique IP Config, passe IPv4 en Static, et renseigne l’adresse avec son masque en notation CIDR, puis la passerelle.

Démarre. Au premier boot, Cloud-Init lit le lecteur, crée le compte, installe ta clé, applique le nom et le réseau, puis lance les mises à jour. Compte une minute environ.

Vérifier que le clonage a fonctionné

Connecte-toi au clone. Et cette fois, depuis n’importe où : n’importe quel terminal, sur n’importe quelle machine du même réseau que ton serveur. C’est tout l’intérêt d’un serveur accessible en SSH, il ne dépend plus de l’interface de Proxmox.

Une réserve : ta clé privée doit se trouver sur la machine d’où tu te connectes. Depuis un poste où elle n’est pas, tu n’entreras pas.

ssh admin@192.168.20.30

SSH t’avertit que l’identité de cet hôte lui est inconnue, ou qu’elle a changé si tu réutilises une adresse. C’est le comportement annoncé en section 4, et c’est une bonne nouvelle : le clone a bien généré ses propres clés. Accepte, ou supprime l’ancienne entrée avec la commande que SSH t’indique, puis reconnecte-toi.

Une fois dedans, les trois vérifications qui comptent :

cat /etc/machine-id
hostname
ip a

Le machine-id doit être différent de celui que tu avais noté. Le nom doit être celui du clone. L’adresse doit être celle que tu as demandée.

Ton interface a changé de nom

Pendant l’installation, ta carte réseau s’appelait ens18. Sur le clone, elle s’appelle eth0. Cloud-Init réécrit la configuration réseau en identifiant la carte par son adresse MAC et en lui imposant ce nom.

Ce n’est pas un problème, mais si tu as des scripts ou des règles de pare-feu qui mentionnent ens18, ils ne trouveront rien sur les clones.

Un second clone, cette fois en DHCP

Répète l’opération, mais change une chose : laisse l’onglet Cloud-Init en DHCP et ne touche pas à IP Config. Donne-lui simplement un autre nom.

Démarre, puis retourne dans l’onglet Summary du clone pour lire l’adresse que ton serveur DHCP lui a attribuée.

Connecte-toi dessus.

C’est la vérification qui compte : deux clones, deux adresses distinctes, l’une fixée à la main et l’autre obtenue automatiquement. Si le machine-id n’avait pas été effacé, ce second clone aurait réclamé la même adresse que le premier. Tu viens de prouver que le nettoyage a fonctionné.

Deux serveurs Ubuntu à jour, configurés, accessibles par clé, en moins d’une minute chacun.

Quand tu modifies un clone existant

Si tu changes un paramètre dans l’onglet Cloud-Init d’une machine déjà démarrée une fois, le changement n’est pas appliqué au redémarrage. Le bouton Regenerate Image réécrit le lecteur de configuration, mais certains réglages, le nom de machine en particulier, ne sont lus qu’au tout premier démarrage.

Pour un clone jetable, la réponse est simple : supprime-le et refais-en un. Il te coûte dix secondes.

Ce que tu peux détruire sans y penser

Tu es parti d’un hyperviseur vide. Tu repars avec un moule.

Ce qui a changé n’est pas la quantité de machines à ta disposition, c’est le coût de leur existence. Avant, tester un service voulait dire une heure d’installation, et cette heure te faisait renoncer neuf fois sur dix. Maintenant, une VM neuve te coûte dix secondes et un clic. Tu vas en créer pour tester, en détruire sans regret, en recréer le lendemain. C’est cette bascule qui compte : tu ne réfléchis plus avant d’essayer.

Au passage, tu as évité deux pièges que la plupart des tutoriels ignorent. Le machine-id non effacé, qui fabrique des clones se battant pour la même adresse. Et l’agent invité qu’on prétend activer à la main alors qu’il démarre tout seul. Tu sais maintenant pourquoi, pas seulement comment.

Un mot sur ce qu’on n’a pas fait. Ton modèle est figé au jour de sa création : dans trois mois, ses clones naîtront avec un système de base qui a trois mois de retard, même si l’option Upgrade packages rattrape les correctifs au premier démarrage. Tu le recréeras périodiquement. Et le choix d’Ubuntu reste ce qu’on a dit en ouverture : un compromis, avec Snap imposé et une couverture de sécurité limitée au dépôt principal. La méthode de cet article fonctionne à l’identique sous Debian. Le jour où Canonical te gêne, tu changes de base sans rien changer d’autre.

Ce que tu as construit n’est pas un tutoriel appliqué, c’est une capacité. Ton infrastructure ne dépend plus de personne, ni d’une image toute faite téléchargée quelque part, ni d’un fournisseur qui décide à ta place. Tu fabriques tes serveurs, tu sais ce qu’il y a dedans, et tu peux tout reconstruire demain.

La suite logique, c’est de faire tourner quelque chose sur ces machines. Docker est le candidat évident, et il mérite son propre article.

À très vite.

Ta tech, tes règles, ta liberté.

Sources

• Ubuntu, dossier de publication de la version 26.04 « Resolute Raccoon » : https://releases.ubuntu.com/resolute/
• Ubuntu, page de téléchargement d’Ubuntu Server : https://ubuntu.com/download/server
• Ubuntu, présentation et conditions d’Ubuntu Pro : https://ubuntu.com/pro
• Proxmox VE, documentation Cloud-Init : https://pve.proxmox.com/wiki/Cloud-Init_Support
• Proxmox VE, documentation d’administration, modèles et clones : https://pve.proxmox.com/pve-docs/pve-admin-guide.html
• Documentation officielle de cloud-init, commande clean : https://docs.cloud-init.io/
• Debian, politique de support et LTS : https://wiki.debian.org/LTS