Dans le premier article, on a monté Proxmox VE 9 dans une machine virtuelle Azure et installé un Windows 11 dedans, en choisissant volontairement du matériel virtuel que Windows reconnaît tout seul : un disque SATA et une carte Intel E1000. Ça marche, c’est reposant, et c’est lent. Cette fois, on refait la même VM en VirtIO de bout en bout, pilotes chargés pendant l’installation, et on termine par le QEMU guest agent.

Si vous n’avez pas encore de nœud Proxmox sous la main, commencez par le premier article, celui-ci reprend exactement là où il s’arrête. Mais vous trouverez également une grande quantité de vidéos sur YouTube qui vous aideront à en savoir un peu plus sur Proxmox et comment le mettre en place :

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

• 1. VirtIO, pourquoi Windows ne le voit pas tout seul
• 2. Étape 1 : récupérer et uploader l’ISO virtio-win
• 3. Étape 2 : créer la VM en VirtIO intégral
• 4. Étape 3 : vérifier l’ordre de démarrage
• 5. Étape 4 : charger le pilote vioscsi pendant l’installation
• 6. Étape 5 : charger NetKVM pendant l’OOBE
• 7. Étape 6 : installer le QEMU guest agent
• 8. Étape 7 : vérifier que tout est bien en VirtIO
• 9. Les pièges à retenir

1. VirtIO, pourquoi Windows ne le voit pas tout seul

Quand un hyperviseur présente un disque ou une carte réseau à un invité, il a deux façons de faire. La première est l’émulation : QEMU imite au bit près un vrai contrôleur qui a existé, un SATA AHCI ou une carte Intel E1000. L’invité croit voir du matériel qu’il connaît depuis quinze ans, il charge son pilote habituel, tout fonctionne. Le prix à payer, c’est que chaque accès disque et chaque paquet réseau doit être traduit par l’hôte, instruction par instruction.

La seconde façon est la paravirtualisation, et c’est ce qu’est VirtIO : plutôt que d’imiter un matériel existant, l’hyperviseur expose une interface conçue pour la virtualisation, avec des files de requêtes partagées entre l’invité et l’hôte. L’invité sait qu’il est virtualisé et parle directement à l’hyperviseur. Beaucoup moins de traduction, beaucoup moins de CPU consommé, nettement plus d’IOPS et de débit.

Le revers est évident : il faut que l’invité connaisse cette interface. Le noyau Linux embarque les pilotes VirtIO depuis des années, donc une VM Debian ou Ubuntu démarre en VirtIO sans que vous ayez rien à faire. Windows non. Le programme d’installation ne contient que des pilotes pour du matériel émulé classique, et c’est précisément pour ça que l’écran de sélection du disque reste désespérément vide quand on lui présente un disque VirtIO SCSI.

Les pilotes existent, ils sont développés dans le cadre du projet virtio-win, distribués sous forme d’une ISO, et signés. Toute la manipulation consiste à les rendre disponibles au bon moment.

Le rôle	Le dossier sur l’ISO	Quand on le charge
Contrôleur de disque VirtIO SCSI	vioscsi	Pendant l’installation, à l’écran de sélection du disque
Contrôleur de disque bus VirtIO simple	viostor	Même moment, si le disque est déclaré en bus virtio et non scsi
Carte réseau VirtIO	NetKVM	Pendant l’OOBE, ou après le premier démarrage
Ballon de mémoire	Balloon	Après installation, facultatif
Agent invité QEMU	guest-agent	Une fois sur le bureau

2. Étape 1 : récupérer et uploader l’ISO virtio-win

L’ISO se télécharge depuis le dépôt du projet Fedora, qui héberge les binaires signés. Deux versions y cohabitent, la stable et la latest. Prenez la stable.

Une fois le fichier récupéré, on l’envoie sur le nœud, exactement comme l’ISO Windows dans le premier article.

1. Dans l’arborescence, sélectionnez le stockage local du nœud, puis ISO Images.
2. Cliquez sur Upload, choisissez le fichier virtio-win.iso, puis Upload.

Vous pouvez aussi passer par Download from URL si vous préférez que le nœud télécharge lui-même, ou par la ligne de commande dans le répertoire des images.

3. Étape 2 : créer la VM en VirtIO intégral

On relance Create VM. Les onglets sont les mêmes que dans le premier article, seuls trois écrans changent.

Dans General, nommez la machine, puis cliquer sur Suivant :

Dans OS, sélectionnez l’ISO Windows 11, le type Microsoft Windows et la version 11/2022/2025. Cette fois, cochez bien Add additional drive for VirtIO drivers, et surtout choisissez l’ISO virtio-win dans le champ du dessous.

Dans System, rien ne change par rapport au premier article, les pré-requis Windows 11 restent les mêmes.

1. Machine : q35.
2. BIOS : OVMF (UEFI), avec Add EFI Disk sur local-1TB et Pre-Enroll keys coché.
3. Add TPM coché, stockage local-1TB, version v2.0.
4. SCSI Controller : VirtIO SCSI single.
5. Cochez Qemu Agent dès maintenant, ça vous évitera d’y revenir plus tard.

Dans Disks, on garde cette fois le disque en SCSI, sur le contrôleur VirtIO SCSI single. Taille 64 Gio, format qcow2, stockage local-1TB. Activez IO thread, qui donne au disque son propre thread d’entrées et sorties, ce qui n’a d’intérêt qu’avec un contrôleur de type single, précisément celui qu’on a choisi.

Les onglets CPU et Memory ne changent pas : un socket, deux cœurs, 8192 Mio.

Dans Network, on garde le modèle VirtIO (paravirtualized) proposé par défaut, sur le bridge vmbr0.

L’écran Confirm permet de tout relire avant de valider. Vérifiez ces lignes.

• ide0 pointe sur virtio-win-0.1.302.iso en media=cdrom, donc les pilotes sont bien montés
• ide2 porte l’ISO Windows 11
• scsi0 est sur local-1TB avec iothread=on
• scsihw vaut virtio-scsi-single
• net0 commence par virtio
• bios vaut ovmf, machine vaut q35, ostype vaut win11
• tpmstate0 est en version=v2.0 et efidisk0 en pre-enrolled-keys=1
• cores vaut au moins 2, exigence de Windows 11

4. Étape 3 : vérifier l’ordre de démarrage

Avec deux lecteurs CD sur la même machine, un détail peut vous coûter un quart d’heure : si ide0, le lecteur des pilotes, passe devant ide2 dans l’ordre de démarrage, la VM tente de démarrer sur une ISO qui n’est pas bootable et vous atterrissez dans un shell UEFI sans comprendre pourquoi.

1. Sélectionnez la VM, puis Options.
2. Double-cliquez sur Boot Order.
3. Placez ide2 en premier, scsi0 en second, et décochez ide0.

Décocher ide0 ne le démonte pas, le lecteur reste accessible depuis Windows. Il n’est simplement plus candidat au démarrage.

5. Étape 4 : charger le pilote vioscsi pendant l’installation

Ouvrez la Console de la VM et démarrez-la. L’installation de Windows 11 commence normalement : langue, clavier, acceptation des conditions.

Puis arrive le moment qu’on attendait. L’écran de sélection de l’emplacement d’installation est vide, et Windows affiche « Install driver to show hardware ». Rien d’anormal : il ne sait pas parler à un contrôleur VirtIO SCSI.

1. Cliquez sur Browse.
2. Dans l’arborescence, descendez jusqu’au dossier vioscsi. Il est plus bas que les premiers dossiers affichés, après viorng.
3. Dépliez vioscsi, puis w11, puis amd64, et validez par OK.
4. Windows propose alors le pilote « Red Hat VirtIO SCSI controller ». Sélectionnez-le et installez-le :

L’écran se recharge, et le disque de 64 Go apparaît.

Le reste de l’installation se déroule sans intervention.

6. Étape 5 : charger NetKVM pendant l’OOBE

Après les redémarrages, l’expérience de première ouverture de session démarre, et un second mur vous attend. Windows affiche « Let’s connect you to a network » sans proposer la moindre connexion : même histoire que pour le disque, la carte VirtIO lui est inconnue.

Bonne nouvelle, Windows 11 propose désormais un bouton pour s’en sortir sans bricolage.

1. Cliquez sur Install driver.
2. Parcourez le lecteur virtio-win, remontez la liste jusqu’à NetKVM, tout en haut.
3. Ouvrez NetKVM, puis w11, puis amd64, et validez par Select Folder.

Windows installe « Red Hat VirtIO Ethernet Adapter », la carte apparaît, et elle reçoit son adresse du dnsmasq configuré dans le premier article, dans la plage 10.10.10.100 à 10.10.10.200. L’OOBE enchaîne alors sur la recherche de mises à jour.

Déroulez la fin de l’OOBE normalement :

Jusqu’au moment où le bureau s’affiche :

7. Étape 6 : installer le QEMU guest agent

Dernière brique. L’agent invité n’est pas un pilote de disque ni de carte réseau : c’est un petit service qui tourne dans Windows et dialogue avec l’hôte par un canal série virtuel dédié. Il fait remonter les adresses IP dans l’interface, permet un arrêt propre demandé au système invité, et autorise le gel des écritures pendant un instantané ou une sauvegarde.

Le canal côté hôte existe déjà, puisqu’on a coché Qemu Agent à la création. Reste la moitié invitée. D’ailleurs cela se voit ici car les adresses IP ne remontent pas encore :

On voit d’ailleurs également le pont de communication n’est pas encore correctement reconnu par Windows :

1. Dans Windows, ouvrez l’explorateur et le lecteur virtio-win.
2. Entrez dans le dossier guest-agent.
3. Lancez le paquet en version 64 bits et déroulez l’assistant.

Attendez la fin de l’installation de l’agent :

Vérifiez ensuite dans la console des services que QEMU Guest Agent est démarré et en mode automatique.

Enfin, il faut mettre à jour le pilote au niveau du gestionnaire de périphériques :

Sur l’ISO, choisissez l’arborescence corresponde à votre OS :

Profitez-en pour installer le reste des pilotes, ballon de mémoire compris, avec le programme virtio-win-guest-tools présent à la racine du lecteur. Il pose tout d’un coup.

8. Étape 7 : vérifier que tout est bien en VirtIO

Trois contrôles, deux côté Proxmox, un côté Windows.

D’abord, l’onglet Summary de la VM doit maintenant afficher les adresses IP de l’invité, ce qui prouve que l’agent répond.

Ensuite, depuis le shell du nœud, deux commandes confirment le dialogue. Remplacez 103 par votre VMID.

qm agent 103 ping
qm guest cmd 103 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 rend la configuration réseau vue de l’intérieur de Windows, au format JSON.

Vous pouvez aussi relire la configuration complète de la machine :

qm config 103

Enfin, côté Windows, le gestionnaire de périphériques doit montrer le contrôleur et la carte Red Hat VirtIO, et surtout aucun point d’exclamation jaune.

9. Les pièges à retenir

Le piège	Le symptôme	La parade
Second lecteur pointant sur l’ISO Windows	Aucun pilote disponible au moment de charger	Sélectionner explicitement virtio-win dans le champ ISO du lecteur supplémentaire
Mauvais dossier de pilote	Le pilote n’apparaît pas dans la liste	vioscsi pour un bus SCSI, viostor pour un bus VirtIO Block
Ordre de démarrage	Shell UEFI au lieu du programme d’installation	Placer ide2 devant, décocher ide0
Build latest des pilotes	Chargement refusé silencieusement avec le démarrage sécurisé	Prendre la build stable, signée
Dossier w11 absent	Rien à sélectionner dans l’arborescence	Utiliser w10 en amd64, c’est le même binaire
Pas de carte pendant l’OOBE	Impossible de terminer la configuration	Bouton Install driver, puis NetKVM, w11, amd64
Guest agent activé à chaud	Aucune adresse IP ne remonte	Arrêt complet puis démarrage depuis Proxmox, pas un redémarrage Windows
Bascule directe SATA vers SCSI	Écran bleu INACCESSIBLE_BOOT_DEVICE	Faire connaître le pilote avec un disque temporaire avant de changer le bus
Pas d’instantané avant conversion	Machine morte, rien pour revenir en arrière	Instantané systématique avant de toucher au bus du disque système

Conclusion

Voilà, en sept étapes, vous avez une machine Windows 11 entièrement paravirtualisée, disque et réseau, avec son agent invité qui dialogue avec l’hôte. La différence de confort à l’usage est immédiate : la console répond mieux, les adresses IP remontent dans l’interface, et l’arrêt depuis Proxmox devient un vrai arrêt propre.

Les trois points que je retiens : le lecteur de pilotes doit pointer sur la bonne ISO, sinon toute la suite est un mirage ; vioscsi pour le disque et NetKVM pour la carte, pas l’inverse ; et une conversion après coup se fait toujours avec un instantané et un disque temporaire, jamais en changeant le bus directement.