Proxmox, vous en entendez parler partout depuis quelques mois, vous savez vaguement que c’est un hyperviseur open source qui monte, mais vous n’avez jamais mis les mains dedans ? Cet article est fait pour vous. On part d’un abonnement Azure et d’un portail vide, et on va dérouler, capture après capture, jusqu’à un bureau Windows 11 qui tourne dans Proxmox VE, lui-même hébergé dans une machine virtuelle Azure.

Je suis MVP Microsoft depuis 2024, je passe mes journées dans Azure, AVD/Windows 365 ou Copilot, mais regarder ce que fait le reste du monde m’a jamais fait de mal. Azure est d’ailleurs le lab le plus rapide à monter pour ça : pas de serveur à acheter, pas de clé USB à graver, pas de machine à démonter dans le garage. Une VM, une soirée devant vous, et vous supprimez le groupe de ressources à la fin.

Il existe déjà beaucoup de vidéos YouTube qui vous montrent Proxmox :

Ce que je voulais avoir pour tester de mon côté, c’était un premier-à-pas complet sur Azure, avec les vrais pièges du réseau imbriqué et les écrans que vous allez réellement voir. C’est ce que vous trouverez ci-dessous, avec en prime les concepts Proxmox expliqués avec des mots d’admin Azure.

Pour vous guider plus facilement dans cet article, voici des liens rapides :

• 1. Proxmox VE, c’est quoi au juste ?
• 2. Pourquoi le tester sur Azure, et ce que ça implique
• 3. Étape 0 : les pré-requis
• 4. Étape 1 : créer la machine virtuelle Azure
• 5. Étape 2 : ouvrir le port 8006 dans le NSG
• 6. Étape 3 : vérifier la virtualisation imbriquée et préparer Debian
• 7. Étape 4 : installer Proxmox VE 9
• 8. Étape 5 : vérifier que les services répondent
• 9. Étape 6 : préparer le disque de 1 To
• 10. Étape 7 : le réseau, la partie qui change tout sur Azure
• 11. Étape 8 : première connexion à l’interface web
• 12. Étape 9 : déclarer le stockage local-1TB
• 13. Étape 10 : voir vmbr0 dans l’interface et appliquer la configuration
• 14. Étape 11 : uploader l’ISO Windows 11
• 15. Étape 12 : créer la machine virtuelle Windows 11
• 16. Étape 13 : installer Windows 11 jusqu’au bureau
• 17. Étape 14 : activer le QEMU guest agent
• 18. Les pièges à retenir

1. Proxmox VE, c’est quoi au juste ?

Proxmox VE, c’est une distribution Debian sur laquelle l’éditeur autrichien Proxmox Server Solutions a posé trois choses : KVM pour les machines virtuelles complètes, LXC pour les conteneurs système, et une interface web qui pilote le tout sur le port 8006. Pas d’agent à installer sur un poste d’administration, pas de console lourde : un navigateur suffit.

Proxmox

Le vocabulaire est la première marche à franchir, parce qu’il ressemble à celui que vous connaissez sans vouloir dire exactement la même chose.

• Le nœud est un serveur qui exécute Proxmox VE. Dans cet article, il s’appelle proxmox-ve et il n’y en a qu’un.
• Le datacenter n’est pas un bâtiment, c’est le niveau logique au-dessus des nœuds. C’est là que l’on déclare les stockages, les utilisateurs, les permissions, les sauvegardes et les règles de pare-feu communes.
• Le cluster réunit plusieurs nœuds qui partagent leur configuration à travers un système de fichiers répliqué, pmxcfs, monté sur /etc/pve. Sur un nœud isolé comme ici, le service tourne quand même : c’est pour ça que pve-cluster doit être actif même sans cluster.
• Le stockage se déclare au niveau du datacenter, avec un type (Directory, LVM, ZFS, NFS, Ceph, et d’autres) et une liste de contenus autorisés (ISO, disques de VM, sauvegardes, modèles de conteneurs).
• Le bridge, nommé vmbr0, vmbr1 et ainsi de suite, est un commutateur Linux auquel on raccorde les cartes réseau des invités.

Proxmox VE est un outil open source gratuit, mais qui proposera également différentes formules de souscriptions payantes selon vos souhaits et vos besoins de support :

Enfi, si vous venez du monde Microsoft, la table de correspondance suivante vous évitera de traduire mentalement à chaque écran :

2. Pourquoi le tester sur Azure, et ce que ça implique

Pour faire tourner Proxmox, il faut un processeur qui expose ses extensions de virtualisation. Dans une VM Azure, cela s’appelle la virtualisation imbriquée, et toutes les tailles ne la proposent pas. La série que j’ai utilisée ici, la Dsv3, la prend en charge, tout comme le stockage Premium dont on a besoin pour le disque de données.

Virtualisation imbriquée : Soutenu

Source : Série de tailles Dsv3, Microsoft Learn

La même page documente la taille que j’ai prise, Standard_D16s_v3, avec ses 16 processeurs virtuels et ses 64 Gio de mémoire. C’est confortable, et c’est surtout ce qui permet de donner 8 Gio et 2 cœurs à une VM Windows 11 sans que la machine hôte ne s’écroule.

Pour rappel, jusqu’ici, monter un lab Proxmox voulait dire trouver une machine physique. Là, il vous faut un abonnement, une taille de VM correcte, et une heure.

Trois limites à connaître avant de commencer, pour ne pas les découvrir en cours de route : le réseau des invités ne pourra pas être ponté directement sur la carte Azure, il faudra passer par du NAT, on y revient en détail plus bas ; les performances resteront celles d’un hyperviseur dans un hyperviseur, donc correctes pour un lab et pas pour de la production ; et un cluster Proxmox multi-nœuds sur Azure demanderait un travail supplémentaire, la découverte du cluster reposant sur des mécanismes réseau que le cloud n’aime pas beaucoup.

3. Étape 0 : les pré-requis

Avant de continuer les étapes de cet article, assurez-vous que vous disposez bien d’une souscription Azure active.

4. Étape 1 : créer la machine virtuelle Azure

Rien d’exotique dans cet assistant, mais quatre champs méritent votre attention.

1. Dans Project details, créez un groupe de ressources dédié. Le mien s’appelle proxmox-rg : tout sera dedans, donc tout partira en une seule suppression.
2. Dans Instance details, nommez la VM proxmox-ve, choisissez votre région, laissez Security type sur Standard et prenez l’image Debian 13 « Trixie » x64 Gen1.
3. Dans Size, sélectionnez Standard_D16s_v3. C’est le champ le plus important de tout l’assistant.

1. Dans Administrator account, j’ai gardé l’authentification par mot de passe avec l’utilisateur. La clé SSH reste évidemment le bon choix si vous comptez garder la machine.
2. Dans Public inbound ports, choisissez Allow selected ports puis SSH (22). Le portail vous prévient que la règle sera ouverte à tout Internet : on la resserrera à l’étape suivante.

L’onglet Disks est celui qui prépare le stockage des futures VM. Le disque système de 30 Gio suffit largement pour Debian et les paquets Proxmox, mais il ne suffira pas pour les disques des invités.

1. Laissez le disque OS à Image default (30 GiB) en Premium SSD.
2. Cliquez sur Create and attach a new disk et créez un disque de 1024 Gio en Premium SSD LRS. C’est lui qui deviendra local-1TB dans Proxmox.

L’onglet Networking se contente des valeurs par défaut : un réseau virtuel neuf, un sous-réseau en 172.16.0.0/24, une adresse IP publique et un groupe de sécurité réseau en mode Basic. Retenez bien le plan d’adressage du sous-réseau, il ne devra surtout pas chevaucher le réseau interne que l’on créera dans Proxmox.

Lancez la création, prenez un café, et récupérez l’adresse IP publique dans la vue d’ensemble de la VM.

5. Étape 2 : ouvrir le port 8006 dans le NSG

L’interface web de Proxmox écoute en HTTPS sur le port 8006. Comme ce port n’existe dans aucun modèle du portail, il faut ajouter la règle à la main dans le groupe de sécurité réseau de la carte.

1. Ouvrez la VM, puis Networking et Network settings.
2. Cliquez sur Create port rule puis Inbound port rule.
3. Source : IP Addresses, et saisissez votre adresse IP publique. Destination : Any. Port de destination : 8006. Protocole : TCP. Action : Allow. Nommez la règle, la mienne s’appelle ProxmoxControlPlane.
4. Profitez-en pour resserrer la règle SSH sur la même source.

Gardez l’adresse IP publique sous la main, elle apparaît dans les propriétés de la machine.

6. Étape 3 : vérifier la virtualisation imbriquée et préparer Debian

Connectez-vous en SSH sur l’adresse publique, avec le compte azureuser. Première chose à faire, avant même de penser à installer quoi que ce soit : vérifier que le processeur expose bien ses extensions de virtualisation et que le périphérique KVM existe.

egrep -c '(vmx|svm)' /proc/cpuinfo
ls -l /dev/kvm

La première commande doit renvoyer un nombre supérieur à zéro, 32 dans mon cas, ce qui correspond aux cœurs logiques qui exposent vmx. La seconde doit afficher le périphérique /dev/kvm. Si l’une des deux échoue, inutile d’aller plus loin : votre taille de VM ne prend pas en charge la virtualisation imbriquée, changez-la.

On regarde ensuite dans quoi on met les pieds :

cat /etc/os-release
hostnamectl
ip addr

Trois informations à retenir de cet écran : la distribution est bien une Debian 13 « Trixie », hostnamectl annonce Virtualization: microsoft puisque nous sommes déjà invités d’un hyperviseur, et la carte eth0 porte l’adresse privée 172.16.0.4.

Vient ensuite la manipulation la plus discrète et la plus importante de tout l’article. Par défaut, le fichier /etc/hosts d’une image Azure ne contient pas de ligne associant le nom d’hôte à l’adresse IP privée.

cat /etc/hosts

Il faut ajouter cette ligne, avec votre adresse privée et votre nom d’hôte, avant d’installer Proxmox.

echo '172.16.0.4 proxmox-ve' | sudo tee -a /etc/hosts

7. Étape 4 : installer Proxmox VE 9

On commence par mettre la Debian à niveau. Les images Azure sont propres, mais rarement à jour au jour près.

sudo apt update

sudo apt full-upgrade -y

On ajoute ensuite la clé de signature du dépôt Proxmox pour Debian 13.

sudo wget https://enterprise.proxmox.com/debian/proxmox-release-trixie.gpg \
  -O /usr/share/keyrings/proxmox-release-trixie.gpg

Puis le dépôt lui-même. J’utilise ici pve-no-subscription, celui qui ne demande pas de clé d’abonnement.

echo "deb [signed-by=/usr/share/keyrings/proxmox-release-trixie.gpg] http://download.proxmox.com/debian/pve trixie pve-no-subscription" | sudo tee /etc/apt/sources.list.d/pve-install-repo.list

sudo apt update

Place à l’installation !

sudo apt install proxmox-ve

APT annonce la couleur : 603 paquets à installer, 829 Mo à télécharger, 3,6 Go d’espace disque. On valide et on laisse travailler.

En cours de route, deux écrans bleus de configuration de paquet vont vous interrompre. Ils méritent chacun une réponse réfléchie.

Le premier concerne /etc/default/grub, qu’Azure a modifié pour la console série. Choisissez keep the local version currently installed :

Le second demande sur quel périphérique installer GRUB. Cochez /dev/sda, le disque système, et rien d’autre.

La fin de l’installation défile ensuite toute seule, avec la génération de la configuration GRUB et la mise en place des services Proxmox.

8. Étape 5 : vérifier que les services répondent

Avant de toucher au stockage et au réseau, on vérifie que les trois services principaux sont bien démarrés. C’est aussi une bonne occasion de comprendre qui fait quoi.

pveproxy est le serveur d’API et le frontal web, celui qui écoute sur 8006.

systemctl status pveproxy --no-pager

pve-cluster porte le système de fichiers de configuration pmxcfs, monté sur /etc/pve. Même sur un nœud isolé, s’il ne tourne pas, rien ne fonctionne.

systemctl status pve-cluster --no-pager

pvedaemon exécute les tâches demandées par l’API, du démarrage d’une VM à la création d’un disque.

systemctl status pvedaemon --no-pager

Dernière vérification, l’écoute effective du port.

sudo ss -lntp | grep 8006

9. Étape 6 : préparer le disque de 1 To

Le disque de données attaché à l’étape 1 est là, mais il est vierge. Première commande, et surtout ne formatez rien avant de l’avoir lue.

lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS,MODEL

Trois disques apparaissent. sda de 30 Go porte le système, sdb de 128 Go est monté sur /mnt, et sdc de 1 To est notre disque de données, encore sans partition.

On vérifie une dernière fois que sdc ne contient aucune signature de système de fichiers, puis on le partitionne.

sudo wipefs -n /dev/sdc
sudo apt install -y parted
sudo parted /dev/sdc --script mklabel gpt mkpart primary ext4 0% 100%
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS /dev/sdc

Puis on formate la partition en ext4.

sudo mkfs.ext4 /dev/sdc1

Reste à créer le point de montage et à le rendre permanent. Relevez l’UUID affiché par blkid et reportez-le dans /etc/fstab, l’UUID ci-dessous est le mien.

sudo mkdir -p /mnt/pve-data
sudo blkid /dev/sdc1
echo 'UUID=111c8254-c5e6-43f1-811f-497fe6a1513c /mnt/pve-data ext4 defaults 0 2' | sudo tee -a /etc/fstab
sudo mount -a
df -h /mnt/pve-data

10. Étape 7 : le réseau, la partie qui change tout sur Azure

Voilà la section pour laquelle j’ai écrit cet article. Sur un Proxmox physique, la configuration réseau par défaut crée un bridge vmbr0 qui embarque la carte physique du serveur : les VM invitées se retrouvent directement sur le réseau de l’entreprise, avec une adresse du même plan que l’hôte. Sur Azure, cela ne fonctionne pas.

La raison est simple : une carte réseau Azure est associée à une configuration IP et à une adresse MAC connues de la plateforme. Une trame émise par une VM imbriquée, avec sa propre adresse MAC et sa propre adresse IP, n’est pas routée par le réseau virtuel. La documentation Microsoft sur la virtualisation imbriquée décrit d’ailleurs le même symptôme côté Hyper-V, avec le NAT comme réponse.

Network connectivity issues in nested VMs

Source : Troubleshooting guide: Hyper-V nested virtualization, Microsoft Learn

La réponse côté Proxmox tient en trois briques comme on pourrait faire tourner un serveur Hyper-V sur Azure : un bridge isolé sans port physique, du NAT pour la sortie, et un service DHCP et DNS interne pour que les invités reçoivent une configuration sans intervention.

On commence par regarder comment la VM est câblée aujourd’hui.

ip -br addr
cat /etc/network/interfaces
networkctl status eth0
which ifupdown2
sudo cat /etc/netplan/50-cloud-init.yaml

Constat : eth0 est piloté par netplan et systemd-networkd, avec une adresse obtenue en DHCP auprès d’Azure, et /etc/network/interfaces ne contient presque rien. Proxmox, lui, s’appuie sur ifupdown2 pour appliquer les changements réseau depuis l’interface web.

sudo apt install -y ifupdown2
sudo ifquery --list
sudo ifreload -a --dry-run

On déclare donc un bridge isolé, en 10.10.10.1/24, sans aucun port attaché. Ce sera la passerelle des VM invitées.

sudo tee /etc/network/interfaces > /dev/null <<'EOF'
# network interface settings; autogenerated

auto lo
iface lo inet loopback

source /etc/network/interfaces.d/*

iface eth0 inet manual

auto vmbr0
iface vmbr0 inet static
    address 10.10.10.1/24
    bridge-ports none
    bridge-stp off
    bridge-fd 0
EOF

Le paramètre qui compte ici est bridge-ports none : aucune carte physique n’est rattachée au commutateur. On active ensuite le bridge et le routage IPv4.

cat /etc/network/interfaces
sudo ifup vmbr0
ip -br addr show vmbr0
sudo sysctl -w net.ipv4.ip_forward=1

Pour que le routage survive au redémarrage, on l’écrit dans un fichier sysctl dédié, et on installe nftables.

sudo apt install -y nftables
sudo nft list ruleset
sudo tee /etc/sysctl.d/99-proxmox-nat.conf > /dev/null <<'EOF'
net.ipv4.ip_forward=1
EOF
sudo sysctl --system

Puis le cœur du sujet : la translation d’adresses. La table nat masque le réseau 10.10.10.0/24 derrière l’adresse de eth0, et la table filter n’autorise que ce qui doit l’être, à savoir les flux sortants des invités et les réponses associées.

sudo tee /etc/nftables.conf > /dev/null <<'EOF'
#!/usr/sbin/nft -f

flush ruleset

table ip nat {
    chain postrouting {
        type nat hook postrouting priority srcnat;
        oifname "eth0" ip saddr 10.10.10.0/24 masquerade
    }
}

table inet filter {
    chain forward {
        type filter hook forward priority filter; policy drop;

        iifname "vmbr0" oifname "eth0" ip saddr 10.10.10.0/24 accept
        iifname "eth0" oifname "vmbr0" ct state established,related accept
    }
}
EOF

sudo nft -c -f /etc/nftables.conf
sudo nft -f /etc/nftables.conf
sudo nft list ruleset
sudo systemctl enable --now nftables
sudo systemctl status nftables --no-pager

Dernière brique, le service DHCP et DNS des invités. Sans lui, il faudrait configurer une adresse IP fixe dans chaque VM créée, ce qui est vite pénible.

sudo apt install -y dnsmasq
sudo tee /etc/dnsmasq.d/proxmox-vmbr0.conf > /dev/null <<'EOF'
interface=vmbr0
bind-interfaces
no-resolv
server=168.63.129.16
dhcp-range=10.10.10.100,10.10.10.200,255.255.255.0,12h
dhcp-option=3,10.10.10.1
dhcp-option=6,10.10.10.1
EOF
sudo dnsmasq --test
sudo systemctl restart dnsmasq

Deux détails de cette configuration valent une explication. bind-interfaces limite l’écoute à vmbr0, donc votre DHCP ne partira jamais polluer le sous-réseau Azure. Et l’adresse 168.63.129.16 déclarée comme serveur amont n’est pas une adresse au hasard : c’est l’adresse IP virtuelle de la plateforme Azure, celle qui rend entre autres le service de résolution de noms aux machines virtuelles.

L’adresse IP Azure 168.63.129.16 est une adresse IP publique virtuelle qui facilite les canaux de communication vers les ressources de la plateforme Azure.

Source : Vue d’ensemble de l’adresse IP Azure 168.63.129.16, Microsoft Learn

11. Étape 8 : première connexion à l’interface web

Le moment de vérité. Ouvrez votre navigateur sur l’adresse publique de la VM, en HTTPS, port 8006.

https://VOTRE-IP-PUBLIQUE:8006

Le certificat est auto-signé, votre navigateur va râler, c’est normal. Connectez-vous avec l’utilisateur root, son mot de passe système, et le realm Linux PAM standard authentication.

Vous serez accueilli par la boîte de dialogue la plus célèbre de Proxmox. Elle vous rappelle simplement que vous utilisez le dépôt sans abonnement.

Et voilà l’interface, avec l’arborescence Datacenter puis nœud à gauche, et le résumé du nœud au centre.

12. Étape 9 : déclarer le stockage local-1TB

Le disque de 1 To est monté sur /mnt/pve-data, mais Proxmox ne le connaît pas encore. Un stockage se déclare au niveau du datacenter, pas du nœud, même quand il n’est physiquement présent que sur une seule machine.

1. Allez dans Datacenter, Storage, puis Add et choisissez Directory.

1. Renseignez l’ID local-1TB, le répertoire /mnt/pve-data, et le contenu Disk image.
2. Laissez Nodes sur All et cochez Enable, puis validez avec Add.

Vous vous retrouvez avec deux stockages. local, sur le disque système, garde les ISO, les sauvegardes et les modèles de conteneurs. local-1TB accueillera les disques des machines virtuelles.

13. Étape 10 : voir vmbr0 dans l’interface et appliquer la configuration

Le bridge créé en ligne de commande apparaît maintenant dans l’interface, avec un avertissement en bas de page signalant des modifications en attente. Proxmox n’applique pas la configuration réseau à chaud sans votre accord, il vous montre d’abord le différentiel entre /etc/network/interfaces et le fichier .new qu’il a préparé.

1. Sélectionnez le nœud, puis System et Network.
2. Relisez le bloc Pending changes en bas de la vue, ligne par ligne.
3. Cliquez sur Apply Configuration.

Après application, eth0 et le Linux Bridge vmbr0 en 10.10.10.1/24 cohabitent proprement.

14. Étape 11 : uploader l’ISO Windows 11

Pour installer un invité, il faut son image. Proxmox sait télécharger une ISO depuis une URL, mais pour Windows 11 vous passerez par l’upload depuis votre poste.

1. Dans l’arborescence, sélectionnez le stockage local du nœud, puis ISO Images.
2. Cliquez sur Upload, choisissez votre fichier, puis Upload à nouveau.

15. Étape 12 : créer la machine virtuelle Windows 11

Cliquez sur Create VM en haut à droite. L’assistant compte huit onglets, et trois d’entre eux conditionnent la réussite de l’installation.

Dans General, donnez un nom à la VM, le mien est vm-w11-test, et notez le VMID proposé, 101 dans mon cas. Ce numéro est l’identifiant que vous retrouverez partout : dans l’arborescence, dans les noms de fichiers de disques, dans les journaux.

Dans OS, sélectionnez l’ISO sur le stockage local, puis le type d’invité Microsoft Windows et la version 11/2022/2025. Proxmox propose de monter un second lecteur contenant les pilotes VirtIO, ce que je n’utiliserai pas pour ce premier article :

Dans System, on entre dans le dur. Windows 11 exige un démarrage UEFI, le démarrage sécurisé et un module de plateforme sécurisée.

1. Machine : q35, le jeu de puces moderne avec PCI Express.
2. BIOS : OVMF (UEFI), et cochez Add EFI Disk en le plaçant sur local-1TB.
3. Cochez Pre-Enroll keys pour que les clés Microsoft soient présentes dès le départ.
4. Cochez Add TPM, stockage local-1TB, version v2.0.
5. SCSI Controller : VirtIO SCSI single, la valeur par défaut, que l’on gardera même si notre disque sera en SATA.

Dans Disks, l’assistant propose par défaut un disque scsi0 sur le contrôleur VirtIO SCSI. Le piège classique : sans les pilotes VirtIO, le programme d’installation de Windows ne verra tout simplement aucun disque, et vous resterez bloqué sur un écran de sélection vide.

Je bascule donc le Bus/Device sur SATA, taille 64 Gio, format qcow2, stockage local-1TB :

Les onglets CPU et Memory sont sans surprise. Un socket, deux cœurs, ce qui est le minimum demandé par Windows 11.

Et 8192 Mio de mémoire, largement supportables sur une VM hôte qui en a 64 Gio.

Dans Network, même logique que pour le disque. Le modèle VirtIO (paravirtualized) proposé par défaut est le plus performant, mais Windows n’en a pas le pilote.

Je choisis donc Intel E1000, sur le bridge vmbr0, en laissant le pare-feu coché. Windows embarque ce pilote depuis toujours, la carte sera donc opérationnelle dès le premier démarrage, et elle recevra son adresse de notre dnsmasq :

L’onglet Confirm récapitule le tout. Vérifiez la présence de bios: ovmf, machine: q35, ostype: win11, du disque sata0 et de net0 en e1000, puis validez.

16. Étape 13 : installer Windows 11 jusqu’au bureau

Sélectionnez la VM 101 dans l’arborescence, ouvrez l’onglet Console et cliquez sur Start Now.

La console noVNC s’affiche dans votre navigateur, et le programme d’installation de Windows 11 démarre.

Déroulez l’installation normalement. L’écran de sélection du disque est celui qui valide tous les choix de l’étape précédente. Le disque de 64 Go apparaît sans avoir eu à charger le moindre pilote. Le pari est gagné :

Lancez l’installation de Windows 11 :

Attendez plusieurs minutes :

La VM redémarre plusieurs fois, puis enchaîne sur l’expérience de première ouverture de session.

La recherche de mises à jour est un excellent test réseau : si cet écran passe, c’est que votre chaîne bridge, NAT et DHCP fonctionne de bout en bout.

Nommez votre machine Windows 11 :

Définissez le type de compte Windows à créer :

Attendez la fin de configuration de Windows 11 :

Attendez encore la fin du téléchargement puis de l’installation des mises à jours OS :

Et au bout du compte, un bureau Windows 11 complet, qui tourne dans Proxmox VE, qui tourne dans une machine virtuelle Azure. La console fonctionne dans un simple onglet de navigateur, sans client RDP.

17. Étape 14 : activer le QEMU guest agent

Votre Windows tourne, mais Proxmox ne sait presque rien de lui. Dans l’onglet Summary de la VM, la ligne des adresses IP reste désespérément vide, et un clic sur Shutdown se contente d’envoyer un signal ACPI en espérant que l’invité l’écoute. Le QEMU guest agent règle ces deux points.

Concrètement, c’est un petit service qui tourne dans l’invité et qui dialogue avec l’hôte par un canal série virtuel dédié. Il ne remplace aucun pilote de disque ni de carte réseau : votre VM continue de démarrer sur son disque SATA et de communiquer par sa carte E1000. C’est justement ce qui le rend sans risque, et c’est pour ça que je le traite ici plutôt que dans un article dédié à VirtIO.

Ce qu’il apporte, une fois en place :

• les adresses IP de l’invité remontent dans l’interface, ce qui évite d’ouvrir la console pour savoir quelle adresse dnsmasq a distribuée
• l’arrêt et le redémarrage depuis Proxmox deviennent un arrêt propre demandé au système invité
• les instantanés et les sauvegardes peuvent geler les écritures le temps de la copie, donc obtenir un état cohérent du système de fichiers
• vous pouvez interroger l’invité depuis le shell du nœud, sans passer par le réseau

L’activation se fait en deux moitiés, et il faut les deux.

Côté Proxmox : ajouter le périphérique

Sur la capture de l’onglet System de l’étape 12, la case Qemu Agent était décochée, comme par défaut. On rattrape ça dans les options de la VM.

1. Sélectionnez la VM, puis Options.
2. Double-cliquez sur QEMU Guest Agent et cochez Use QEMU Guest Agent.
3. Validez.

Côté Windows : installer le service

Le programme d’installation de l’agent est livré sur l’ISO virtio-win, la même que celle des pilotes. Uploadez-la dans le stockage local comme vous l’avez fait pour Windows :

Puis montez-la dans la VM avec Hardware, Add, CD/DVD Drive :

Dans Windows, ouvrez le gestionnaire des périphériques afin de mettre à jour le driver suivant :

Choisissez le dossier correspondant à l’OS de votre VM :

Attendez le succès de l’installation :

ouvrez le lecteur et lancez le paquet du dossier guest-agent, en version 64 bits. Il installe uniquement le service QEMU Guest Agent, visible ensuite dans la console des services, et ne touche ni au contrôleur de disque ni à la carte réseau :

Vérifier que ça marche

Retournez sur l’onglet Summary de la VM : les adresses IP de l’invité doivent maintenant s’afficher, avec l’adresse distribuée par votre dnsmasq dans la plage 10.10.10.100 à 10.10.10.200 :

Depuis le shell du nœud, deux commandes confirment le dialogue.

qm agent 101 ping
qm guest cmd 101 network-get-interfaces

La première ne renvoie rien quand tout va bien, ce qui est la définition d’un bon silence :

La seconde vous rend la configuration réseau vue de l’intérieur de Windows, au format JSON :

18. Les pièges à retenir

Conclusion

Voilà, en quatorze étapes, vous avez un hyperviseur Proxmox VE 9 complet, avec son stockage dédié, son réseau interne routé, son interface web accessible, et une machine virtuelle Windows 11 qui tourne dedans, agent invité compris. Le tout sans acheter un seul serveur.

Concrètement, ça donne quoi ? Vous avez de quoi vous former sur Proxmox, tester des scénarios de migration, comparer honnêtement ce que fait la concurrence avec ce que vous connaissez déjà, et tout détruire d’un clic quand vous avez fini. Pour quelqu’un qui vit dans Azure toute la journée, c’est la façon la moins coûteuse de sortir de sa zone de confort.

Les trois points que je retiens de ce lab : la taille de la VM Azure décide de tout dès le premier écran, le réseau imbriqué se traite par du NAT et pas par du bridge, et le couple SATA plus E1000 fait gagner un temps fou sur l’installation d’un invité Windows.

Foncez tester, et n’oubliez pas de désallouer la VM en partant. Le prochain article sera consacré au passage en VirtIO d’un invité Windows déjà installé, disque et carte réseau : c’est le gain de performances évident de ce lab, mais c’est aussi la manipulation qui casse le plus de machines quand on la fait dans le mauvais ordre. On ira voir ensuite les instantanés et les sauvegardes.