Créer la machine virtuelle

Dans le guide précédent, vous avez renforcé la sécurité de ce nœud Proxmox unique, notamment en configurant un compte non-root avec une authentification à deux facteurs, un pare-feu et un jeton API dédié à l'automatisation. Ce guide utilise ces trois éléments pour créer la première machine virtuelle que la plateforme hébergera effectivement, depuis le téléchargement d'une image d'installation jusqu'à la mise en place d'un système invité fonctionnel équipé d'un système d'exploitation.

Télécharger une image d'installation

Une nouvelle installation de Proxmox ne comprend aucun support d'installation ; ainsi, avant qu'une machine virtuelle puisse pointer vers un système d'exploitation, le programme d'installation de ce dernier doit se trouver à un emplacement accessible à Proxmox. C'est dans le panneau « Images ISO », situé sur la page dédiée à chaque périphérique de stockage, que se trouve ce support, et il est initialement complètement vide.

Proxmox peut récupérer ce fichier multimédia lui-même, directement sur le nœud, au lieu de télécharger un fichier depuis un ordinateur local via une connexion lente. Le bouton « Télécharger depuis une URL », situé sur le même panneau, ouvre une petite boîte de dialogue qui ne demande rien d’autre qu’une URL.

Ce guide explique comment installer Debian au sein de la machine virtuelle, la même distribution que celle sur laquelle Proxmox fonctionne, en utilisant la petite image « netinst » plutôt qu'un DVD complet : quelques centaines de mégaoctets qui téléchargent via le réseau, au fur et à mesure de l'installation, le reste des paquets dont celle-ci a réellement besoin.

En effet, le système d'exploitation de l'hyperviseur et tout ce qui s'exécute au sein de ses machines virtuelles relèvent de domaines totalement distincts. La base Debian propre à Proxmox n'existe que pour faire fonctionner la pile de l'hyperviseur, tandis qu'une machine virtuelle invitée est libre d'exécuter tout ce dont une charge de travail donnée a réellement besoin ; or, sur une plateforme réelle, il est rare que ce soit deux fois la même distribution.

En collant l'URL réelle de la version « netinst » de Debian et en cliquant sur « Query URL », le fichier est vérifié avant tout téléchargement, ce qui permet de confirmer à la fois sa taille réelle et son type de contenu réel.

En cliquant sur « Télécharger », le téléchargement s'effectue sur le nœud lui-même, en arrière-plan, avec son propre journal des tâches en temps réel, plutôt que via une barre de progression du navigateur liée à cet onglet.

Cette redirection mérite qu'on s'y attarde plutôt que de la passer sous silence : cdimage.debian.org Il ne sert jamais le fichier lui-même ; il se contente de déterminer, requête par requête, quel miroir réel est le plus proche ou le moins sollicité, et redirige le téléchargement vers celui-ci. Une autre tentative, provenant d'un réseau différent, peut aboutir sur un miroir totalement différent sans que rien ne change du côté de Proxmox.

Une fois la tâche terminée, la liste des images ISO, identique à celle d'auparavant, n'affiche désormais qu'un seul fichier, avec une taille réelle et une date-heure réelle au lieu d'un espace réservé.

Le bouton « Télécharger depuis l'URL » est en soi une simple interface autour d'un appel d'API ; il est utile de le connaître directement dès lors que cette étape doit s'exécuter de manière automatisée dans le cadre du déploiement d'une plateforme complète, plutôt que de devoir cliquer à chaque fois sur une boîte de dialogue :

curl -k -X POST "https://pve.example.com:8006/api2/json/nodes/pve/storage/local/download-url" \
  -H "Authorization: PVEAPIToken=opsadmin@pve!automation=<token-secret>" \
  --data-urlencode "content=iso" \
  --data-urlencode "filename=debian-13.7.0-amd64-netinst.iso" \
  --data-urlencode "url=https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-13.7.0-amd64-netinst.iso"

Le jeton est ici le même opsadmin@pve!automation jeton créé dans le guide précédent, dont le champ d'application reste limité aux autorisations dont il a réellement besoin.

Suivez les étapes de l'assistant de création de machine virtuelle

La fonction « Créer une machine virtuelle », située dans le coin supérieur droit de n’importe quelle page Proxmox, ouvre un assistant comportant huit onglets. Il n’y a là rien de mystérieux : tous les champs des huit onglets sont regroupés en un seul ensemble de paramètres, qui sont envoyés en une seule fois, à la toute fin, sous la forme d’un seul appel API. En observant comment chaque onglet façonne cet appel, pièce par pièce, l’API elle-même perd beaucoup de son mystère lorsqu’elle apparaît dans le dernier onglet.

Donnez un nom à la machine virtuelle et choisissez un identifiant de machine virtuelle

L'onglet « Général » vous demande d'abord les informations les moins intéressantes : un identifiant de machine virtuelle (VM ID), que Proxmox remplit déjà avec le prochain numéro disponible sur ce nœud, et un nom, qui reste purement esthétique et n'a aucune incidence sur le système d'exploitation invité lui-même, à moins qu'il ne soit saisi manuellement par la suite.

Pointez-le vers l'image d'installation

C'est dans l'onglet « Système d'exploitation » que l'image ISO récupérée précédemment est effectivement utilisée. Si vous ne modifiez pas le champ « Image ISO » et que vous essayez de passer à l'étape suivante, une véritable erreur de validation s'affiche, au lieu de laisser l'assistant poursuivre son exécution en silence.

La sélection de ce fichier permet également de définir le « Type de système d'exploitation invité » sur « Linux » et la « Version » via un menu déroulant plus restreint qu'il n'y paraît : Proxmox ne distingue en effet que deux générations de Linux dans ce cas.

Cela ne modifie en rien le comportement. « 7.x - 2.6 Kernel » est l’abréviation utilisée par Proxmox pour désigner tout noyau Linux moderne de la série 2.6 et au-delà, ce qui couvre désormais pratiquement toutes les distributions bénéficiant encore de mises à jour ; le « noyau 2.4 » n'existe que pour les machines invitées véritablement anciennes, antérieures à cette version. Debian 13 relève clairement de la première catégorie, malgré le « 7 » figurant littéralement dans son nom.

Conservez les paramètres par défaut du système, cochez une case

Les paramètres par défaut de l'onglet « Système » sont déjà adaptés à une première machine virtuelle : « VirtIO SCSI single » comme contrôleur de disque, « Par défaut (i440fx) » comme type de machine, et « SeaBIOS » plutôt que « UEFI ». La seule case qu'il convient de cocher délibérément est celle intitulée « Qemu Agent », qui n'est pas cochée par défaut.

Cochez cette case n'entraîne pas d'installation en soi ; cela indique simplement à Proxmox de s'attendre à ce qu'un agent invité communique via un canal série virtuel. La question de savoir si cet agent s'exécute réellement au sein de l'invité sera abordée plus en détail dans ce guide une fois le système d'exploitation installé.

Définir la taille du disque virtuel

L'onglet « Disques » affiche par défaut un disque de 32 Gio sur « local-lvm », ce qui est supérieur aux besoins de cette première machine virtuelle et dépasse la capacité que le pool « thin » défini dans le guide précédent devrait avoir à supporter à lui seul. En le réduisant à 16 Gio, on dispose de suffisamment d'espace pour une installation Debian de base et ses journaux, sans mobiliser davantage de ce pool que ne le justifie une première machine virtuelle de test.

Attribuer des cœurs de processeur

Par défaut, l'onglet « CPU » indique un seul socket, un seul cœur et un type de processeur « x86-64-v2-AES » au lieu du modèle exact de l'hôte. En portant le nombre de cœurs à 2, cette machine virtuelle dispose de ressources suffisantes pour effectuer des tâches simultanées.

Ce choix s'oppose délibérément à celui opéré dans le guide précédent, qui avait opté pour -cpu host pour l'exécution de Proxmox lui-même dans un environnement de test : une machine virtuelle invitée sur une plateforme réelle pourrait un jour devoir être migrée vers un matériel physique différent, et un type de processeur lié aux caractéristiques exactes de cet hôte précis entraînerait l'échec pur et simple de cette migration. Un type de référence portable sacrifie une petite partie de ses performances brutes au profit de la portabilité, ce qui constitue généralement le bon compromis pour tout ce qui est destiné à servir des clients.

Définir la limite maximale de mémoire

L'onglet « Mémoire » est réglé par défaut sur 2 048 Mio. En activant l'onglet « Avancé », vous accédez aux mêmes options « Ballooning Device » et « Allow KSM » que celles abordées dans le guide précédent ; ces deux options sont cochées par défaut sur toute nouvelle machine virtuelle.

La mémoire minimale est initialement égale à la mémoire totale, ce qui signifie qu'il n'existe pas encore de plage de « ballooning » à proprement parler ; celle-ci ne devient utile qu'une fois que cette valeur minimale est abaissée, permettant ainsi à Proxmox de récupérer la différence auprès d'une machine virtuelle inactive en cas de pression réelle sur la mémoire.

Fixez-le au pont

L'onglet « Réseau » associe la machine virtuelle à vmbr0, le même pont que celui présenté dans le guide précédent, en utilisant le modèle VirtIO afin de bénéficier des meilleures performances qu'un pilote paravirtualisé puisse offrir. Le pare-feu est coché par défaut sur l'interface réseau elle-même.

Cette case à cocher est un commutateur distinct de l’activation du pare-feu au niveau du centre de données évoquée précédemment, qui reste désactivée sur ce nœud. Le cocher ici n'a pour l'instant aucun effet visible, mais cela signifie que lorsque le commutateur principal sera activé ultérieurement, le trafic de cette machine virtuelle sera déjà couvert par les règles qui s'y appliquent, plutôt que de devoir être réexaminé interface par interface.

Consulter et créer

L'onglet « Confirmer » présente toutes les valeurs issues des onglets précédents sous la forme d'un tableau plat de clés et de valeurs ; ce tableau n'est pas un récapitulatif destiné aux utilisateurs, mais le corps de la requête tel quel que l'assistant s'apprête à envoyer.

En cochant la case « Démarrer après la création » puis en cliquant sur « Terminer », on envoie exactement cette table sous la forme d'une seule requête API réelle, reproduite ici dans son intégralité plutôt que supposée :

curl -k -X POST "https://pve.example.com:8006/api2/json/nodes/pve/qemu" \
  -H "Authorization: PVEAPIToken=opsadmin@pve!automation=<token-secret>" \
  --data-urlencode "vmid=100" \
  --data-urlencode "name=web01" \
  --data-urlencode "ostype=l26" \
  --data-urlencode "ide2=local:iso/debian-13.7.0-amd64-netinst.iso,media=cdrom" \
  --data-urlencode "scsihw=virtio-scsi-single" \
  --data-urlencode "scsi0=local-lvm:16,iothread=on" \
  --data-urlencode "agent=1" \
  --data-urlencode "sockets=1" \
  --data-urlencode "cores=2" \
  --data-urlencode "cpu=x86-64-v2-AES" \
  --data-urlencode "memory=2048" \
  --data-urlencode "net0=virtio,bridge=vmbr0,firewall=1" \
  --data-urlencode "start=1"

Cet appel unique crée et démarre la machine virtuelle, comme le confirment deux tâches réelles distinctes dans le journal, et non une seule : « VM 100 - Create », immédiatement suivie de « VM 100 - Start ».

Démarrer dans le programme d'installation

En ouvrant l’onglet « Console » de cette machine virtuelle, vous accédez directement au même menu de démarrage du programme d’installation de Debian que celui déjà présenté en détail dans le guide précédent sur l’hôte physique, sauf que cette fois-ci, il s’exécute dans la console d’une machine virtuelle plutôt que sur un serveur physique. Les écrans suivants sont identiques dans les deux cas ; ce guide les passe donc plus rapidement en revue la deuxième fois, en ne soulignant que ce qui est véritablement nouveau ou différent pour une installation en tant qu'invité.

Ce compte à rebours en bas de l'écran mérite d'être lu plutôt qu'ignoré : si vous ne modifiez pas le menu, cela ne se contente pas de sélectionner l'option par défaut mise en surbrillance, mais lance finalement le parcours d'installation de la synthèse vocale accessible, un processus nettement différent, articulé autour d'instructions audio plutôt que des fenêtres de dialogue habituelles. Appuyer sur n'importe quelle touche fléchée annule le compte à rebours et permet de sélectionner délibérément l'entrée « Installer » habituelle.

Installer le système d'exploitation invité

La langue, l'emplacement et la disposition du clavier reprennent les choix effectués lors de l'installation de Proxmox. La première étape véritablement nouvelle concerne le nom d'hôte : il est préférable de le définir de manière à ce qu'il corresponde au nom de la machine virtuelle dans Proxmox plutôt que de conserver le nom par défaut de Debian.

La création d'un compte utilisateur non-root se heurte à une véritable erreur de validation qu'il est utile de connaître à l'avance : certains noms d'utilisateur sont réservés par le système lui-même et sont systématiquement rejetés, même s'ils semblent tout à fait raisonnables.

Le nom « operator » entre en conflit avec un compte Unix existant, historiquement utilisé pour les opérations système, même s'il semble être un choix tout à fait raisonnable pour l'utilisateur administrateur d'une plateforme. « opsadmin », le même nom que celui déjà utilisé pour le compte administrateur Proxmox dans le guide précédent, fonctionne sans conflit et assure la cohérence de la nomenclature entre l'hyperviseur et les machines virtuelles qui y tournent.

Le partitionnement guidé utilisant l'intégralité du disque virtuel génère une table de partition réelle et fonctionnelle sans nécessiter aucun calcul manuel : un système de fichiers racine ext4 occupant la majeure partie du disque, et une partition swap dont la taille est déterminée en fonction de la mémoire vive de la machine virtuelle.

Récupérer les données à partir d'un miroir d'archive défectueux

Dès que l'installation du système de base est terminée, le programme d'installation tente de se connecter à un miroir de paquets Debian via le réseau afin de configurer apt pour la suite de l'installation. Cette vérification peut effectivement échouer, et il est utile de savoir à quoi ressemble réellement l'erreur plutôt que de supposer que le système est irrémédiablement endommagé.

Sur du matériel réel, cela renvoie généralement à un élément spécifique au chemin d’accès à Internet de cette machine virtuelle : un serveur DNS qui n’est pas encore accessible depuis l’intérieur de la machine invitée, une règle de pare-feu bloquant le trafic HTTPS sortant, ou simplement un miroir brièvement surchargé pour lequel il vaut mieux réessayer un peu plus tard. Pour cette raison précise, revenir en arrière et sélectionner à nouveau le même miroir permet parfois d’aboutir dès la deuxième tentative.

Lorsque l'installation échoue à plusieurs reprises, le programme d'installation lui-même propose une véritable solution plutôt qu'une impasse : terminer l'installation sans recourir à un miroir réseau.

Si vous choisissez « Oui » ici, vous privilégiez une installation fonctionnelle au détriment d’une installation complète : la sélection des logiciels proposée par la suite ne comprendra que les éléments déjà présents sur l’image netinst elle-même ; le serveur SSH et l’agent invité ne figureront pas parmi les options disponibles. Une fois que le système installé aura démarré avec un accès réseau réel et opérationnel, une procédure normale apt update devant un miroir convenable dans /etc/apt/sources.list repère tout ce que le programme d'installation a dû ignorer.

Terminez l'installation et redémarrez l'ordinateur

Sans miroir, l'option « Sélection des tâches » n'installe que les utilitaires système standard déjà présents sur l'image ISO, et le programme d'installation procède ensuite à l'écriture de GRUB sur le disque sur lequel il a effectivement été installé, plutôt que de deviner lequel il s'agit.

Un redémarrage effectué à ce stade vous amène sur le système réel, déjà installé, et non sur le programme d'installation ; l'apparition d'un écran de connexion prouve que l'ensemble du processus a bien permis de créer un système invité fonctionnel.

Vérifier que l'agent invité est en cours d'exécution

Le fait de cocher la case « Qemu Agent » dans l'onglet « Système » a simplement indiqué à Proxmox qu'il devait s'attendre à la présence d'un agent ; en l'absence de connexion réseau pendant l'installation, cet agent n'a en réalité jamais été installé dans la machine virtuelle, pas plus qu'un serveur SSH. Ces deux éléments peuvent être mis en place en une seule commande dès lors que la machine virtuelle dispose d'un véritable accès à Internet, qu'il s'agisse d'une configuration corrigée /etc/apt/sources.list après une panne de miroir ou une installation normale disposant d'un accès réseau opérationnel dès le départ :

apt update
apt install -y qemu-guest-agent openssh-server

Dès que cet agent démarre et se connecte, l'onglet « Résumé » de Proxmox n'affiche plus un champ « IP » vide, mais une adresse réelle, extraite de l'intérieur de la machine invitée plutôt que devinée à partir de la couche réseau extérieure.

Ces mêmes informations sont disponibles via l'API ; c'est d'ailleurs ce qu'un script de provisionnement interrogerait, plutôt que d'attendre que quelqu'un consulte l'onglet « Résumé » :

curl -k "https://pve.example.com:8006/api2/json/nodes/pve/qemu/100/agent/network-get-interfaces" \
  -H "Authorization: PVEAPIToken=opsadmin@pve!automation=<token-secret>"