Création d'une VM sur Proxmox

Contexte et besoins

Sur mon homelab personnel, j’ai un serveur dédié sur lequel tourne Proxmox VE 8. C’est ma plateforme pour tester des services à la maison sans encombrer mon poste principal : outils auto-hébergés, labs réseau, dépannage. Cet atelier porte sur le geste de base mais essentiel : créer proprement une nouvelle VM Debian 13 sur cet hyperviseur, prête à accueillir un service derrière.

Trois objectifs concrets :

• découvrir l’interface web de Proxmox et comprendre l’architecture (storage, bridge, VMID) ;
• comparer la démarche avec celle d’ESXi vue plus tôt dans la formation, pour bien identifier les points communs et les différences ;
• ressortir avec une VM Debian 13 fonctionnelle, intégrée à l’hyperviseur, sur laquelle je pourrai monter un service plus tard.

Rappel théorique sur Proxmox VE

Proxmox Virtual Environment (Proxmox VE) est un hyperviseur libre développé par Proxmox Server Solutions, basé sur Debian et la combinaison KVM/QEMU pour la virtualisation matérielle, plus LXC pour les conteneurs. C’est un hyperviseur de type 1, dit bare metal : il s’installe directement sur le serveur physique, sans système d’exploitation hôte en dessous. Il pilote lui-même le CPU, la RAM, les disques et les cartes réseau, puis distribue ces ressources aux machines virtuelles invitées.

À l’inverse, un hyperviseur de type 2 (VirtualBox, VMware Workstation) tourne comme une application au-dessus d’un OS classique. Pratique pour un poste de travail, mais coûteux en performances : chaque accès au matériel doit traverser l’OS hôte. Proxmox VE, lui, vise les serveurs de production et les homelabs un peu sérieux.

Quelques différences notables avec ESXi :

Composants à connaître

• Node : un hôte Proxmox. Plusieurs nodes peuvent former un cluster.
• Storage : emplacement où sont stockés les disques de VM, les ISO, les snapshots. Types courants : local (LVM-thin), local-lvm, NFS, Ceph.
• VMID : numéro unique d’une VM ou d’un conteneur sur le cluster. À partir de 100 par convention.
• Bridge réseau (vmbr0) : commutateur virtuel auquel sont rattachées les cartes réseau des VM.
• qemu-guest-agent : équivalent d’open-vm-tools côté ESXi : agent qui tourne dans la VM pour communiquer avec l’hyperviseur (arrêt propre, remontée d’IP, snapshots cohérents).

Topologie de laboratoire

Sur mon homelab, l’hôte Proxmox est branché en filaire à la box internet, et j’administre depuis mon poste connecté en Wi-Fi à la même box.

Prérequis

• Un serveur compatible Proxmox VE 8 (CPU 64 bits avec virtualisation matérielle Intel VT-x / AMD-V activée dans le BIOS).
• Proxmox VE 8 déjà installé sur le serveur, avec le storage par défaut local-lvm configuré.
• Une ISO de Debian 13 téléchargée et déposée dans le storage local de Proxmox (/var/lib/vz/template/iso/).
• Un poste d’administration avec un navigateur récent sur le même réseau que l’hôte.
• Mes identifiants root@pam ou un compte d’administration dédié.

Connexion à l’interface web

J’ouvre Firefox sur mon poste et je tape l’URL de l’interface Proxmox :

https://192.168.1.253:8006

Le navigateur affiche un avertissement de certificat : Proxmox installe un certificat auto-signé par défaut. J’accepte pour la durée du TP, en sachant qu’on peut le remplacer par un certificat Let’s Encrypt via l’ACME intégré (utile dès qu’on commence à exposer l’interface en dehors du LAN).

Le formulaire de login demande quatre champs :

• User name : mon identifiant (root ou un compte dédié, masqué ici en MONUSERNAME).
• Password : le mot de passe associé.
• Realm : le domaine d’authentification. Je laisse Linux PAM standard authentication, qui s’appuie sur les comptes système Linux de l’hôte. Les autres realms (pam, pve, ou un LDAP/AD branché) servent quand on veut séparer comptes système et comptes Proxmox.
• Language : je laisse en anglais, plus pratique pour suivre la doc officielle qui est elle aussi en anglais.

Une fois loggué, la page d’accueil affiche l’arborescence Datacenter à gauche (nodes, storages, VMs, conteneurs), les panneaux de contrôle au centre, et la liste des tâches en bas qui trace tout ce qui se passe sur l’hyperviseur.

Vérification de la bibliothèque d’ISOs

Avant de créer la VM, je passe par Datacenter → pve → local → ISO Images pour vérifier que l’ISO Debian 13 est bien présente. Sur mon homelab, j’y entrepose au fil du temps les images dont je me sers régulièrement :

debian-12.10.0-amd64-netinst.iso
debian-13.3.0-amd64-netinst.iso              ← celle que je vais utiliser
netgate-installer-v1.1.1-RELEASE-amd64.iso
OPNsense-25.7-dvd-amd64.iso
pfSense-CE-2.6.0-RELEASE-amd64.iso
virtio-win.iso
VMware-VMvisor-Installer-8.0U3e-x86_64.iso
vyos1.5-stream-Q2.iso
Win11_24H2_FRA.iso
WinServ2022-FRA.iso
WinServ2025-FRA.iso

Le bouton Upload ouvre une boîte de dialogue qui sert à téléverser une nouvelle ISO depuis le poste d’administration. Sur la capture, je suis en train d’ajouter un Windows_Server2022_FR.iso (4.71 GiB) en parallèle, pour une autre VM. À noter trois détails utiles :

• le champ Hash algorithm permet de vérifier l’intégrité de l’ISO (SHA256 par exemple) en collant le checksum officiel, bonne pratique pour s’assurer qu’on ne pousse pas une image corrompue ou trafiquée ;
• les fichiers transitent par /var/tmp/ côté hôte avant d’arriver dans /var/lib/vz/template/iso/, donc il faut vérifier qu’on a bien la place sur le système racine ;
• le bouton Download from URL à côté permet à Proxmox de télécharger directement depuis une URL (HTTP, HTTPS), pratique quand on est connecté au serveur via VPN sans repasser par son poste.

Création de la VM

Je clique sur le bouton Create VM en haut à droite. L’assistant en sept onglets s’ouvre.

Onglet General

L’option Advanced est cochée en bas à droite : ça affiche les champs supplémentaires Start/Shutdown order, Startup delay, Shutdown timeout, et la zone Tags.

Node             : pve
VM ID            : 106
Name             : MAVMTEST
Resource Pool    : (vide)
Add to HA        : décoché
Start at boot    : décoché
Start/Shutdown   : any
Startup delay    : default
Shutdown timeout : default
Tags             : No Tags

Explications ligne par ligne :

• VM ID 106 : les VMs et conteneurs partagent le même espace d’identifiants sur Proxmox, à partir de 100 par convention. La VM précédente créée portait le 105, j’enchaîne donc avec 106.
• MAVMTEST : nom court pour signaler que c’est une VM de test, à renommer une fois l’usage cible validé.
• Resource Pool: vide : les pools servent à grouper plusieurs VMs pour leur appliquer collectivement des permissions ou des quotas. Inutile sur un homelab à une seule VM.
• Add to HA: décoché : pas de cluster ici, donc pas de besoin de gestion haute dispo.
• Start at boot: décoché : à activer plus tard quand la VM est en service. En phase de création, ça évite qu’elle redémarre toute seule pendant l’installation.
• Start/Shutdown order: any : pas de contrainte d’ordre de démarrage par rapport aux autres VMs. À ajuster (numéro entier) si certaines VMs doivent démarrer avant d’autres (par exemple un Active Directory avant les serveurs membres).
• Tags: No Tags : les tags servent à filtrer dans la vue d’ensemble (prod, lab, web, etc.). À enrichir une fois la VM en service.

Onglet OS

L’écran propose trois sources possibles pour l’installation :

• Use CD/DVD disc image file (iso) : sélectionnée, on pointe vers une ISO du storage. C’est ce que j’utilise.
• Use physical CD/DVD Drive : lecteur CD/DVD physique de l’hôte. Rare aujourd’hui.
• Do not use any media : aucun média de boot, utile pour une VM qu’on va remplir par PXE ou par cloud-init.

Source    : Use CD/DVD disc image file (iso)
Storage   : local
ISO image : debian-13.3.0-amd64-netinst.iso
Guest OS  : Linux
Version   : 6.x - 2.6 Kernel

Le storage local héberge les ISO. La distinction avec local-lvm est importante : local est utilisé pour les ISO et les sauvegardes, local-lvm pour les disques de VM. Le champ Version (6.x - 2.6 Kernel) sert à Proxmox pour activer les bonnes optimisations VirtIO côté noyau invité.

Onglet System

Graphic card     : Default
Machine          : Default (i440fx)
BIOS             : Default (SeaBIOS)
SCSI Controller  : VirtIO SCSI single
Qemu Agent       : coché

Explications ligne par ligne :

• Machine: Default (i440fx) : chipset par défaut, suffisant pour une VM Linux classique. Pour des cas plus exigeants (Windows 11, passthrough PCIe), on bascule sur q35.
• BIOS: Default (SeaBIOS) : firmware BIOS classique, plus simple et largement supporté. Pour activer Secure Boot ou démarrer un Windows 11, on choisirait OVMF (UEFI) à la place, auquel cas il faut aussi ajouter un disque EFI dédié.
• VirtIO SCSI single : contrôleur SCSI paravirtualisé, plus performant que IDE ou SATA émulés. Le suffixe « single » dédie un contrôleur par disque, ce qui améliore le débit en cas de plusieurs disques.
• Qemu Agent: coché : active la communication avec qemu-guest-agent dans la VM. À ne pas oublier : sans cette case cochée côté hyperviseur, l’agent installé dans la VM ne sera pas reconnu.

Onglet Disks

Bus/Device    : SCSI 0
Storage       : local-lvm
Disk size     : 32 GiB
Format        : raw (par défaut sur LVM-thin)
Cache         : Default (No cache)
Discard       : coché
SSD emulation : coché (si disque physique SSD)

Explications ligne par ligne :

• Disk size 32 GiB : suffisant pour Debian 13 + un service. Sur LVM-thin, l’espace n’est consommé qu’à mesure des écritures (équivalent du thin provisioning sur ESXi).
• Discard: coché : permet à la VM de signaler à l’hôte les blocs libérés (TRIM). L’hyperviseur peut alors récupérer cet espace au lieu de le garder « réservé ».
• SSD emulation: coché : indique au système invité que le disque est un SSD, ce qui active les optimisations adaptées (pas de défragmentation, gestion TRIM côté OS).

Onglet CPU

Sockets : 1
Cores   : 2
Type    : host

Type: host expose au système invité le modèle exact du CPU physique, ce qui maximise les performances mais empêche une migration à chaud vers un nœud avec un CPU différent. En cluster hétérogène, on choisirait plutôt un type générique (x86-64-v2-AES).

Onglet Memory

Memory (MiB)   : 4096
Minimum memory : 4096 (ballooning désactivé)

Pour une VM de service, je préfère désactiver le ballooning et fixer la RAM. C’est plus prévisible côté supervision.

Onglet Network

Bridge   : vmbr0
Model    : VirtIO (paravirtualized)
Firewall : coché

vmbr0 est le bridge par défaut, relié à l’interface physique de l’hôte. La VM se retrouve donc sur le même réseau LAN que la box. VirtIO est le pilote paravirtualisé recommandé pour les performances.

Confirmation

L’onglet Confirm récapitule tout. Je relis VMID, nom, ISO, storage, taille du disque, CPU, RAM et bridge, puis je clique sur Finish. Proxmox crée la VM en quelques secondes.

Installation du système invité

Je sélectionne 106 (MAVMTEST) dans l’arborescence, je clique sur Console puis sur Start. La console NoVNC s’ouvre dans le navigateur, et l’installeur Debian démarre depuis l’ISO. L’écran d’accueil annonce Debian GNU/Linux installer menu (BIOS mode), confirmation que la VM démarre bien sur SeaBIOS. Je choisis Graphical install.

Je suis ensuite l’installation pas à pas :

• langue : français ;
• nom de la machine : MAVMTEST ;
• domaine : laissé vide pour ce TP ;
• partitionnement guidé sur tout le disque, un seul système de fichiers ;
• pas d’environnement de bureau, juste serveur SSH et utilitaires standards du système.

GRUB s’installe et la VM redémarre. Je détache l’ISO depuis l’onglet Hardware de la VM (clic sur le lecteur CD/DVD → Edit → Do not use any media) pour qu’au prochain reboot la VM démarre directement sur le disque.

Installation de qemu-guest-agent

Côté Proxmox, j’ai déjà coché Qemu Agent à la création. Reste à installer l’agent dans la VM.

Je me connecte en SSH depuis le poste d’administration :

# Mise à jour de l'index des paquets
sudo apt update

# Installation de l'agent invité QEMU
sudo apt install -y qemu-guest-agent

# Démarrage immédiat du service
sudo systemctl enable --now qemu-guest-agent

Explications ligne par ligne :

• qemu-guest-agent : paquet officiel Debian, équivalent d’open-vm-tools pour ESXi. Fournit l’arrêt propre, le freeze/thaw du système de fichiers pour les snapshots cohérents, et la remontée des IPs vers Proxmox.
• systemctl enable --now : active le service au démarrage et le lance immédiatement, en une commande. Pas besoin de redémarrer la VM.

Une fois l’agent actif, l’onglet Summary de la VM dans l’interface Proxmox affiche les adresses IP de la VM dans le panneau IPs, ce qui prouve que la communication fonctionne.

Vérifications

Sur la VM, je vérifie que l’agent tourne bien et que l’interface réseau est correctement configurée :

# Statut du service qemu-guest-agent
systemctl is-active qemu-guest-agent

# Vérification de l'IP attribuée
ip -4 addr show

Du côté hyperviseur, dans la console web : l’icône de la VM passe en vert avec une indication running, et la section Summary affiche l’IP invitée, le nom d’hôte, la charge CPU/RAM en temps réel.

Tests

Trois scénarios pour valider le déploiement :

1. Connectivité réseau : depuis le poste d’administration, ping 192.168.1.252 puis ssh user@192.168.1.252. Réponse correcte, latence inférieure à 1 ms sur le LAN.
2. Persistance après redémarrage : sudo reboot sur la VM. Elle revient en moins de 30 secondes, l’IP est conservée, qemu-guest-agent redémarre automatiquement.
3. Arrêt propre depuis l’hyperviseur : dans Proxmox, Shutdown sur la VM. Grâce à l’agent, Proxmox envoie un signal ACPI au système invité qui s’éteint proprement, sans corruption du disque. Sans l’agent, seul un Stop brutal serait possible.

Problèmes rencontrés et solutions

Compétences du bloc 1 mobilisées

Bilan

À l’issue de l’atelier, ma VM MAVMTEST est en service sur l’hyperviseur Proxmox VE de mon homelab : elle répond au ping, accepte SSH, redémarre proprement et fait remonter ses informations à l’interface web.

Comparé à ESXi, j’ai trouvé Proxmox plus direct sur le clustering et la gestion native des conteneurs, et plus permissif côté licence (open source, pas de période d’essai à gérer). En contrepartie, l’interface est un peu moins léchée et certains réglages avancés se font à la CLI (qm, pct). Cela dit, pour un homelab qui doit grossir au fil des projets, c’est exactement ce qu’il faut : pas de mur de licence à 60 jours, et tout l’écosystème open source autour.

Trois pistes pour la suite :

• automatiser la création de VM avec cloud-init plutôt que de relancer l’assistant à chaque fois ;
• monter un deuxième nœud Proxmox pour expérimenter le cluster et la migration à chaud ;
• mettre en place un backup planifié vers un Proxmox Backup Server, pour ne pas garder l’unique exemplaire de mes VM sur le seul disque de l’hôte.

Sources

• Proxmox VE — Qm , Proxmox Server Solutions, doc officielle.
• Proxmox VE — qm(1) manual page , Proxmox Server Solutions, doc officielle.
• Proxmox VE — Cloud-Init Support , Proxmox Wiki.
• Debian Wiki — QEMU , Debian Project.
• ANSSI — Problématiques de sécurité associées à la virtualisation des systèmes d’information , note technique NP-Virtualisation v1.1.