Proxmox : Windows ne voit pas le disque — installer correctement les pilotes VirtIO

novembre 25, 2025 • février 3, 2026 • Lecture : 26 min • Views: 6

Cet article vous a aidé ?

L’installation de Windows fonctionne, la VM démarre bien depuis l’ISO, puis : « Où voulez-vous installer Windows ? » affiche une liste vide. Ou bien votre VM Windows déjà installée signale soudainement qu’il n’y a aucun périphérique de démarrage après que vous ayez « juste » basculé sur VirtIO parce que quelqu’un a dit que c’est plus rapide. C’est le moment où les gens paniquent, redémarrent trois fois et commencent à accuser ZFS, la carte RAID ou la lune.

La vérité est généralement ennuyeuse : Windows ne sait pas communiquer avec le contrôleur de stockage virtuel que vous avez présenté. On corrige cela en présentant le bon contrôleur et en installant le bon pilote VirtIO au bon moment, dans le bon environnement Windows (Setup vs OS installé). Faites-le proprement et vous obtiendrez un stockage rapide, moins d’interruptions étranges et un comportement prévisible sous charge.

Procédure de diagnostic rapide

Si vous voulez l’essentiel (80/20), le voilà. Exécutez ce guide du haut vers le bas. Arrêtez-vous dès que vous trouvez le mauvais réglage.

Première question : êtes-vous dans Windows Setup ou dans un Windows déjà installé ?

Windows Setup (installateur) : vous devez cliquer sur « Charger le pilote » et pointer vers l’ISO VirtIO, ou utiliser temporairement un contrôleur que Windows connaît déjà (SATA).
Windows déjà installé : il faut que les pilotes VirtIO soient installés avant de changer le disque/le contrôleur, sinon vous risquez INACCESSIBLE_BOOT_DEVICE.

Deuxième question : quel contrôleur avez-vous choisi dans Proxmox ?

VirtIO SCSI (recommandé) avec virtio-scsi-single dans Proxmox : nécessite le pilote vioscsi.
VirtIO Block : nécessite le pilote viostor.
SATA : Windows le voit sans pilotes VirtIO ; c’est plus lent et moins « cloud-native », mais parfait pour un bootstrap temporaire.

Troisième question : l’ISO VirtIO est-elle montée et visible par la VM ?

Montez virtio-win.iso comme lecteur CD/DVD secondaire dans Proxmox.
Dans « Charger le pilote » de Setup, naviguez vers le dossier correct pour votre version de Windows (généralement \vioscsi\w11\amd64, \vioscsi\w10\amd64 ou équivalents Serveur).

Quatrième point : Secure Boot et problèmes de signature des pilotes

Windows 11 + Secure Boot : les pilotes VirtIO récents sont signés, mais les ISO plus anciennes peuvent poser problème. Utilisez une ISO VirtIO récente et évitez « l’ISO trouvée dans un partage poussiéreux ».
Si vous utilisez UEFI/OVMF, restez cohérent. Changer le type de BIOS en cours de route modifie la mécanique de démarrage.

Cinquième point : confirmez que Proxmox présente réellement un disque

Oui, cela semble évident. Vérifiez quand même la config VM et l’état du stockage Proxmox. Un volume manquant ou verrouillé ressemble exactement à un « pas de disque » du point de vue de l’invité.

Blague #1 : L’installateur Windows est comme un videur : si votre pilote de stockage n’est pas sur la liste, votre disque ne rentre pas.

Faits et contexte utiles (pourquoi ça revient)

VirtIO est né à l’époque KVM/QEMU : modèle de périphérique paravirtualisé conçu pour éviter le coût élevé de l’émulation.
Windows n’inclut pas les pilotes de stockage VirtIO par défaut, d’où le « Linux marche tout seul » et le Windows qui demande des drivers.
IDE existe encore surtout pour compatibilité : lent, limité, utile principalement pour démarrer d’anciens installateurs ou comme bus CD-ROM de secours.
VirtIO SCSI existe pour de bonnes raisons : il fournit une abstraction SCSI au-dessus de VirtIO et supporte des fonctionnalités comme TRIM/UNMAP dans les piles virtualisées correctement configurées.
« VirtIO Block » vs « VirtIO SCSI » n’est pas qu’un nom : ce sont des pilotes Windows différents (viostor vs vioscsi) et des comportements opérationnels distincts selon les charges.
Les pilotes inclus chez Microsoft privilégient la compatibilité large, c’est pourquoi SATA/AHCI marche partout et VirtIO non.
Windows Setup est un petit OS à part entière : charger un pilote dans Setup ne garantit pas automatiquement que votre Windows installé l’aura correctement préparé (et inversement).
Les changements de contrôleur sont critiques pour le démarrage sous Windows : les pilotes de stockage doivent être présents et configurés pour démarrer tôt, sinon vous aurez des échecs de démarrage.
Les paramètres par défaut de Proxmox se sont améliorés, mais beaucoup de billets restent coincés sur d’anciennes recommandations (modèles legacy, BIOS étranges).

Ce que signifie réellement « ne voit pas le disque » sur Proxmox

« Windows ne voit pas le disque » est un symptôme. Sous le capot, l’une de ces situations se produit :

Aucun disque n’est réellement attaché (problème de config VM, stockage, mauvais ID VM, volume supprimé, volume verrouillé, ou le disque est attaché sur un bus que votre firmware ne démarre pas).
Un disque est attaché, mais Windows n’a pas de pilote pour le contrôleur (situation classique VirtIO pendant Setup).
Un disque est attaché et un pilote existe, mais Windows ne peut pas encore l’utiliser (pilote non chargé dans WinPE/Setup, dossier d’architecture incorrect, problème de signature).
Le disque est visible mais inutilisable (politique de disque hors ligne, incompatibilité GPT/MBR selon les réglages de démarrage, Storage Spaces, ou métadonnées obsolètes).
Le disque est visible mais les performances sont catastrophiques (mauvais mode cache, pas d’iothread, mauvaise config QEMU, ou saturation du stockage hôte).

Le plan est simple : prouvez ce que Proxmox présente, prouvez ce que Windows charge, puis reliez les deux avec le bon package VirtIO.

Choisir le bon modèle de stockage virtuel (arrêtez d’improviser)

Voici ce que je recommande pour la plupart des VMs Windows en production sur Proxmox :

Bus/contrôleur : VirtIO SCSI avec virtio-scsi-single (GUI Proxmox : SCSI Controller → « VirtIO SCSI single »).
Type de disque : disque SCSI (par ex. scsi0).
Cache : généralement « Write back » uniquement si vous comprenez le risque ; sinon « None » par défaut (souvent le plus sûr). Si vous êtes sur ZFS, soyez particulièrement prudent avec le double-caching et les sémantiques d’échec.
IO thread : activez I/O thread pour les disques très sollicités. Cela réduit souvent les pics de latence sous charge mixte.
Trim/Discard : activez le discard pour le provisionnement thin ou les pools SSD quand vous voulez la libération d’espace (après vérification du support du stockage sous-jacent).

Quand ne pas utiliser VirtIO SCSI ?

Bootstrap d’installateur : si vous ne voulez pas charger de pilotes pendant Setup, utilisez SATA pour l’installation puis basculez ensuite (mais faites-le en sécurité).
Versions très anciennes de Windows : le support existe, mais le risque opérationnel augmente. Si votre OS est suffisamment ancien pour être qualifié de « legacy », vous faites déjà des choix.

VirtIO Block peut convenir, mais VirtIO SCSI a tendance à être le « bon choix par défaut » dans l’univers Proxmox car il gère mieux les disques multiples, le queueing et les schémas opérationnels courants.

Nouvelle installation : charger les pilotes VirtIO pendant Windows Setup

C’est la voie la plus propre : présentez un disque VirtIO dès le départ, puis chargez le pilote dans Setup afin que Windows puisse le voir et s’installer correctement.

Étape 1 : Attachez les deux ISO

Montez votre ISO Windows comme CD/DVD 1. Montez virtio-win.iso comme CD/DVD 2. Si vous ne montez que VirtIO et oubliez Windows, vous aurez un moment calme pour réfléchir à vos choix de vie.

Étape 2 : Utilisez VirtIO SCSI single et un disque SCSI

Dans le matériel de la VM Proxmox :

Contrôleur SCSI : VirtIO SCSI single
Disque dur : SCSI (scsi0)

Étape 3 : Dans Windows Setup, cliquez sur « Charger le pilote »

Quand vous arrivez à la sélection du disque et que vous ne voyez rien :

Cliquez sur Charger le pilote.
Parcourez le lecteur CD VirtIO.
Choisissez le dossier de pilote correspondant à votre OS et architecture. Exemples :
- \vioscsi\w11\amd64
- \vioscsi\w10\amd64
- \vioscsi\2k22\amd64 (pour Windows Server 2022)
Sélectionnez le pilote et continuez. Votre disque devrait apparaître.

Étape 4 : Installer les pilotes VirtIO supplémentaires après le premier démarrage

Le stockage est l’élément critique, mais ne vous arrêtez pas là. Installez :

Réseau (NetKVM) si vous avez utilisé une carte VirtIO NIC
Balloon si vous utilisez des concepts de mémoire dynamique (certains le font, d’autres non)
QEMU Guest Agent pour des arrêts propres, le reporting IP et une meilleure orchestration

VM Windows existante : passer en toute sécurité de SATA/IDE à VirtIO/SCSI

C’est là que les gens cassent des choses. Le mode d’échec est prévisible : Windows démarre bien sur SATA, vous basculez le disque sur VirtIO SCSI, Windows plante avec INACCESSIBLE_BOOT_DEVICE parce que le pilote critique au démarrage n’est pas installé/actif.

L’approche sûre est tout aussi prévisible : faites apprendre à Windows le nouveau contrôleur tant qu’il démarre encore sur l’ancien.

Méthode A (recommandée) : ajouter un second disque VirtIO, installer les pilotes, puis migrer

Conservez votre disque de démarrage actuel sur SATA (ou ce qui fonctionne actuellement).
Ajoutez un second disque sur VirtIO SCSI (scsi1) ou VirtIO Block, selon ce que vous prévoyez d’utiliser.
Démarrez Windows. Il détectera le nouveau matériel et vous pourrez lui indiquer les pilotes VirtIO (ou installer le package VirtIO).
Confirmez que le pilote est installé et que le nouveau disque est visible dans Gestion des disques.
Puis migrez le disque de démarrage/le contrôleur, ou clonez les données si nécessaire.

Méthode B : préparer le pilote puis basculer le contrôleur (rapide, plus risqué)

Si vous devez le faire en une seule fois :

Montez l’ISO VirtIO dans la VM.
Installez le package de pilotes VirtIO dans Windows.
Éteignez, changez le bus/contrôleur du disque dans Proxmox, démarrez, et priez un peu moins que d’habitude.

Cela fonctionne souvent. « Souvent » n’est pas une stratégie de fiabilité. Utilisez la méthode A quand vous êtes responsable de la disponibilité.

Blague #2 : Changer les contrôleurs de stockage Windows sans préparer les pilotes, c’est comme remplacer un volant de voiture à grande vitesse — techniquement possible, socialement déconseillé.

Tâches pratiques avec commandes (et décisions)

Voici des tâches opérationnelles réelles à exécuter sur l’hôte Proxmox. Chacune indique ce que la sortie vous dit et quelle décision en tirer ensuite. Si vous les faites dans l’ordre, vous résoudrez généralement le problème avant que votre café ne refroidisse.

Tâche 1 : Confirmer la configuration matérielle de la VM (quel bus de disque avez-vous réellement présenté ?)

cr0x@server:~$ qm config 104
boot: order=scsi0;ide2;net0
cores: 4
memory: 8192
name: win11-prod
net0: virtio=DE:AD:BE:EF:10:40,bridge=vmbr0
scsihw: virtio-scsi-single
scsi0: rpool:vm-104-disk-0,discard=on,iothread=1,size=120G
ide2: local:iso/Win11_23H2.iso,media=cdrom
ide3: local:iso/virtio-win.iso,media=cdrom

Ce que cela signifie : Cette VM utilise VirtIO SCSI single et le disque de démarrage est sur scsi0. Windows Setup aura besoin de vioscsi.

Décision : Si le disque est virtio0, prévoyez de charger viostor à la place. Si le disque est sata0, vous n’aurez pas besoin des pilotes VirtIO pour le voir.

Tâche 2 : Confirmer que le volume disque existe dans le stockage Proxmox

cr0x@server:~$ pvesm list rpool | grep vm-104-disk-0
rpool:vm-104-disk-0  raw  128849018880  0

Ce que cela signifie : Le volume existe et est visible par Proxmox.

Décision : S’il manque, vous n’avez pas un problème de pilotes VirtIO — vous avez un problème de mappage de stockage, de suppression ou de mauvais ID VM.

Tâche 3 : Vérifier si un snapshot ou un verrou de sauvegarde bloque les opérations disque

cr0x@server:~$ qm status 104
status: stopped

Ce que cela signifie : La VM est arrêtée ; aucun verrou actif indiqué ici.

Décision : Si vous voyez un verrou dans l’interface ou le journal des tâches, corrigez la cause racine avant d’attendre un attachement cohérent du disque.

Tâche 4 : Vérifier que l’ISO VirtIO est présent sur l’hôte

cr0x@server:~$ ls -lh /var/lib/vz/template/iso/virtio-win.iso
-rw-r--r-- 1 root root 705M Dec  2 11:40 /var/lib/vz/template/iso/virtio-win.iso

Ce que cela signifie : L’ISO existe sur le stockage local dans le chemin ISO standard de Proxmox.

Décision : S’il manque, téléversez-la correctement ; ne montez pas un fichier aléatoire et appelez ça une solution.

Tâche 5 : Confirmer que la VM monte réellement l’ISO VirtIO comme CD-ROM

cr0x@server:~$ qm config 104 | egrep 'ide2|ide3|sata2'
ide2: local:iso/Win11_23H2.iso,media=cdrom
ide3: local:iso/virtio-win.iso,media=cdrom

Ce que cela signifie : L’ISO VirtIO est attachée comme lecteur CD-ROM.

Décision : Si elle n’est pas attachée, Windows Setup ne trouvera jamais le pilote. Attachez-la, redémarrez la VM en Setup et réessayez.

Tâche 6 : Vérifier les paramètres du processus QEMU pour la VM (Proxmox a-t-il appliqué ce que vous pensez ?)

cr0x@server:~$ ps -ef | grep -E 'kvm.*-id 104' | head -n 1
root     22188     1 12 11:52 ?        00:01:44 /usr/bin/kvm -id 104 -name win11-prod -machine type=pc-q35-8.1 ... -device virtio-scsi-pci,id=scsihw0 ...

Ce que cela signifie : QEMU tourne avec un périphérique VirtIO SCSI.

Décision : Si vous attendiez SATA mais voyez des périphériques VirtIO, votre config n’est pas celle que vous croyez — corrigez la divergence avant de toucher Windows.

Tâche 7 : Vérifier les logs kernel de l’hôte pour erreurs disque/stockage autour du démarrage de la VM

cr0x@server:~$ journalctl -k --since "30 min ago" | egrep -i 'zfs|scsi|blk|i/o error|qemu' | tail -n 15
Dec 26 11:51:10 server kernel: zfs: spa_sync: doing sync pass
Dec 26 11:51:12 server kernel: blk_update_request: I/O error, dev zd16, sector 123456 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Dec 26 11:51:12 server kernel: Buffer I/O error on dev zd16, logical block 15432, async page read

Ce que cela signifie : L’hôte signale des erreurs d’I/O. Cela peut se manifester dans l’invité comme « pas de disque » ou des installations corrompues.

Décision : Arrêtez d’accuser les pilotes VirtIO et investiguez la santé du stockage hôte (état du pool, disques sous-jacents, contrôleur) avant de continuer.

Tâche 8 : Vérifier la santé du pool ZFS (si vous êtes sur ZFS)

cr0x@server:~$ zpool status -x
all pools are healthy

Ce que cela signifie : Pas de problèmes ZFS connus.

Décision : S’il reporte degraded/faulted, corrigez cela d’abord. L’échec de Windows Setup à voir un disque n’est pas toujours une histoire de pilote.

Tâche 9 : Confirmer le firmware/mode de démarrage de la VM (UEFI vs SeaBIOS)

cr0x@server:~$ qm config 104 | egrep 'bios|efidisk0|machine'
bios: ovmf
efidisk0: rpool:vm-104-disk-1,size=4M
machine: q35

Ce que cela signifie : La VM utilise UEFI (OVMF) avec un disque EFI et le type machine Q35.

Décision : Restez cohérent. Si vous avez installé Windows en UEFI, ne passez pas à SeaBIOS plus tard sauf si vous aimez l’archéologie du chargeur de démarrage.

Tâche 10 : Valider le modèle de carte réseau (parce que vous aurez besoin du réseau pour finir)

cr0x@server:~$ qm config 104 | grep '^net0'
net0: virtio=DE:AD:BE:EF:10:40,bridge=vmbr0

Ce que cela signifie : Une carte VirtIO NIC est utilisée. Windows Setup peut ne pas avoir le pilote réseau non plus.

Décision : Si vous avez besoin du réseau pendant Setup (pour joindre un domaine, récupérer des pilotes, des mises à jour), soyez prêt à charger NetKVM depuis l’ISO VirtIO aussi — ou utilisez temporairement une NIC émulée Intel E1000.

Tâche 11 : Vérifier les logs d’activités Proxmox pour des changements matériels récents

cr0x@server:~$ tail -n 30 /var/log/pve/tasks/index
UPID:server:00005A1C:0002A9F4:676D8B6E:qmset:104:root@pam:
UPID:server:00005A9F:0002B0A1:676D8BAA:qmstart:104:root@pam:
UPID:server:00005B10:0002B733:676D8BE2:qmstop:104:root@pam:

Ce que cela signifie : Quelqu’un a changé les paramètres de la VM et l’a démarrée/arrêtée.

Décision : Si le bus/contrôleur du disque a été changé récemment, supposez d’abord un décalage de pilotes. Restaurez ou appliquez la procédure de migration correcte.

Tâche 12 : Inspecter les lignes de mappage effectif des disques (SCSI vs VirtIO vs SATA)

cr0x@server:~$ qm config 104 | egrep '^(scsi|virtio|sata|ide)[0-9]+:'
scsi0: rpool:vm-104-disk-0,discard=on,iothread=1,size=120G
ide2: local:iso/Win11_23H2.iso,media=cdrom
ide3: local:iso/virtio-win.iso,media=cdrom

Ce que cela signifie : Le seul disque dur est basé sur VirtIO SCSI (scsi0). Si Windows ne le voit pas, il manque vioscsi dans Setup.

Décision : Ne changez pas cinq choses en même temps. Chargez le pilote d’abord.

Tâche 13 : Si vous suspectez un bug « disque non attaché », comparez la config en cours avec les fichiers disques sur le stockage

cr0x@server:~$ ls -lh /rpool/images/104/
total 121G
-rw-r----- 1 root root 120G Dec 26 11:50 vm-104-disk-0
-rw-r----- 1 root root 4.0M Dec 26 11:45 vm-104-disk-1

Ce que cela signifie : Les fichiers disques existent aux emplacements attendus (exemple pour un montage dataset ZFS en mode répertoire). Le mappage Proxmox est probablement correct.

Décision : Si le fichier disque manque, n’installez plus Windows. Restaurez depuis sauvegarde ou corrigez le mappage de stockage.

Tâche 14 : Vérifier les flags de virtualisation CPU de l’hôte et la santé de KVM (rare, mais écarte une classe de problèmes)

cr0x@server:~$ egrep -m 1 '(vmx|svm)' /proc/cpuinfo
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ...

Ce que cela signifie : Les extensions de virtualisation matérielle sont présentes.

Décision : Si KVM est mal configuré, vous verrez des problèmes VM plus larges, pas seulement « pas de disque ». C’est un contrôle de bon sens, pas votre principal suspect.

Erreurs courantes : symptôme → cause → correctif

Cette section regroupe ce qui fait perdre des heures en production parce que tout le monde suppose le mauvais niveau.

1) Symptom : Windows Setup n’affiche aucun disque

Cause : Contrôleur de stockage VirtIO présenté, mais aucun pilote VirtIO chargé dans Setup.
Correctif : Montez l’ISO VirtIO, cliquez sur « Charger le pilote », choisissez vioscsi pour VirtIO SCSI ou viostor pour VirtIO Block, en correspondant à votre version de Windows et amd64.

2) Symptom : « Aucun pilote n’a été trouvé » en parcourant l’ISO VirtIO

Cause : Mauvais dossier (mauvaise version d’OS), mauvaise architecture, ou vous utilisez VirtIO Block mais parcourez vioscsi (ou l’inverse).
Correctif : Revérifiez le bus disque dans Proxmox. Puis sélectionnez le chemin de pilote correct. En cas de doute : VirtIO SCSI → \vioscsi\...\amd64 ; VirtIO Block → \viostor\...\amd64.

3) Symptom : VM Windows existante plante en bleu avec INACCESSIBLE_BOOT_DEVICE après changement de contrôleur

Cause : Pilote de stockage non installé/configuré pour démarrage avant le changement de contrôleur.
Correctif : Rétablissez l’ancien contrôleur pour démarrer. Puis préparez les pilotes en ajoutant un second disque VirtIO. Ne changez le bus de démarrage qu’après confirmation.

4) Symptom : Le disque apparaît dans Setup après chargement du pilote, mais l’installation échoue ou se corrompt plus tard

Cause : Instabilité du stockage hôte, erreurs I/O, ou mode cache dangereux en condition de perte de puissance.
Correctif : Vérifiez les logs de l’hôte et la santé du pool. Utilisez un cache conservateur jusqu’à ce que vous puissiez prouver la durabilité de bout en bout (et ayez une onduleur et des sémantiques d’écriture correctes dans la pile).

5) Symptom : Windows s’installe, mais pas de réseau pendant Setup ou après le premier démarrage

Cause : Une NIC VirtIO sélectionnée mais le pilote NetKVM non installé.
Correctif : Chargez le pilote NetKVM depuis l’ISO VirtIO pendant Setup, ou utilisez temporairement une NIC émulée pour aller en ligne et installer le package VirtIO ensuite.

6) Symptom : Windows voit le disque, mais les performances sont épouvantables (latence élevée, faible IOPS)

Cause : Mauvais réglages disque (pas d’iothread, mode cache sous-optimal), contention hôte, ou backend saturé.
Correctif : Activez iothread pour les disques très sollicités, revoyez le mode cache avec attention, et mesurez la latence du stockage hôte. N’« optimisez » pas à l’aveugle.

7) Symptom : Après l’installation du pilote, Windows ne voit toujours pas le disque jusqu’au redémarrage

Cause : Pilote chargé mais l’énumération du périphérique n’a pas été rafraîchie dans l’environnement.
Correctif : Dans Setup, rescannez ou revenez en arrière/avancez. Dans Windows installé, rescannez les disques dans Gestion des disques ou redémarrez. C’est normal ; ne réagissez pas excessivement.

Listes de contrôle / plan pas-à-pas

Checklist A : Nouvelle installation Windows sur VirtIO SCSI (chemin recommandé)

Créez la VM avec UEFI (OVMF) si vous voulez les paramètres modernes de Windows ; gardez le type machine Q35 cohérent.
Réglez le contrôleur SCSI sur VirtIO SCSI single.
Ajoutez le disque en SCSI (scsi0) ; activez iothread si vous attendez un I/O soutenu ; envisagez discard si thin-provisioned/SSD.
Montez l’ISO Windows en CD-ROM.
Montez l’ISO VirtIO en second CD-ROM.
Démarrez l’ISO Windows, atteignez la sélection de disque, cliquez sur « Charger le pilote ».
Chargez le pilote vioscsi correspondant à la version de l’OS et amd64.
Confirmez l’apparition du disque ; installez Windows.
Après le premier démarrage, installez le package complet VirtIO (storage, net, balloon, qemu-ga) depuis l’ISO VirtIO.
Redémarrez, puis vérifiez que le Gestionnaire de périphériques n’a plus de périphériques inconnus pour stockage/réseau.

Checklist B : Convertir une VM Windows existante de SATA à VirtIO SCSI sans drame

Snapshot ou sauvegarde de la VM. Ce n’est pas optionnel si vous êtes payé pour être responsable.
Montez l’ISO VirtIO dans la VM existante.
Ajoutez un petit disque test en SCSI sous VirtIO SCSI single (scsi1) en gardant le disque de démarrage inchangé.
Démarrez Windows ; installez les pilotes VirtIO (ou le package). Confirmez que Windows détecte le nouveau disque et le contrôleur.
Éteignez proprement la VM.
Changez le bus/contrôleur du disque de démarrage en SCSI (VirtIO SCSI single).
Démarrez et vérifiez que Windows démarre sans écran bleu lié au stockage.
Retirez le disque test si utilisé seulement pour la préparation.

Checklist C : Si vous êtes bloqué en cours d’installation et avez besoin d’un contournement tactique

Basculez temporairement le disque de démarrage en SATA (AHCI) pour que Windows Setup le voie sans pilotes.
Installez Windows.
Dans Windows, installez les pilotes VirtIO depuis l’ISO VirtIO.
Utilisez la méthode A pour migrer vers VirtIO SCSI plus tard.

Trois mini-histoires d’entreprise vécues

Mini-histoire 1 : L’incident causé par une mauvaise hypothèse

L’organisation avait un « template » standard pour les VMs Windows. Quelqu’un l’avait construit des mois plus tôt en utilisant des disques SATA parce que « ça marchait partout ». Avec le temps, l’équipe virtualisation a modernisé tout le reste : Q35, UEFI, NICs VirtIO. Le stockage est resté en SATA parce que personne ne voulait y toucher. Puis un nouvel ingénieur est arrivé et a fait ce que font les nouveaux ingénieurs : « corriger » ce qui semble manifestement sous-optimal.

Il a migré plusieurs VMs de SATA vers VirtIO SCSI, une par une, pendant une fenêtre de maintenance. Il a supposé que Windows détecterait le contrôleur au démarrage et installerait les pilotes automatiquement, parce que Linux le fait. La première VM a planté. La deuxième aussi. À ce stade, la fenêtre est devenue une série d’urgences et le canal de maintenance s’est rempli de langage créatif.

La cause racine n’était pas exotique. Le pilote VirtIO n’était pas préparé comme pilote de démarrage. Windows n’avait aucun moyen de parler au disque de démarrage, donc il ne pouvait pas charger l’OS pour installer le pilote nécessaire pour parler au disque nécessaire pour charger l’OS. Un parfait cercle infernal.

La récupération a été simple une fois qu’on a pris une respiration : repasser les disques en SATA pour démarrer, monter l’ISO VirtIO, installer le package de pilotes, ajouter un disque VirtIO SCSI factice pour forcer l’énumération, confirmer les pilotes, puis refaire la migration. Mais le downtime a eu lieu, parce que la mauvaise hypothèse a été faite au départ : « un pilote apparaîtra magiquement au démarrage. »

La solution pérenne n’a pas été un script héroïque. Ce fut une procédure de migration avec une étape non négociable : préparer le pilote tant que la VM est encore démarrable.

Mini-histoire 2 : L’optimisation qui a mal tourné

Une autre équipe était fière de son cluster Proxmox. Matériel solide, ZFS et assez de monitoring pour réveiller les morts. Ils ont remarqué que les benchmarks disque dans une VM Windows étaient « inférieurs aux attentes », et quelqu’un a décidé d’optimiser à tout prix. Ils ont changé le mode cache en writeback, activé discard partout et mis iothread sur chaque disque, rapidement.

Les performances ont effectivement progressé — à court terme. Puis un redémarrage de l’hôte suite à une mise à jour du kernel est arrivé. Un sous-ensemble de VMs est revenu avec des erreurs système de fichiers et des corruptions applicatives. Le postmortem a été douloureux car ce n’était pas un seul coupable ; c’était une pile d’hypothèses. Le cache writeback peut être sûr si vous comprenez d’où vient l’accusé de réception d’écriture et ce qui se passe en cas de perte d’alimentation ou de reboot brutal. Dans leur pile, cette histoire de sécurité n’était pas totalement prouvée.

Ils ont dû revenir sur les réglages de cache, restaurer des données depuis des sauvegardes et expliquer à la direction pourquoi une « optimisation de performances » avait causé un incident de fiabilité. La leçon : les ajustements de stockage ne sont pas gratuits. Si vous ne pouvez pas expliquer le modèle de durabilité à un SRE sceptique, ne le déployez pas.

La fin a été meilleure : ils ont gardé iothread pour des disques spécifiques à fort I/O, utilisé un cache conservateur par défaut et activé des caches agressifs seulement là où l’application pouvait tolérer le risque et l’infrastructure avait les protections adéquates contre la perte d’alimentation.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe gérait un petit cloud privé avec Proxmox et un mélange Linux/Windows. Rien d’extravagant. Leur « pratique ennuyeuse » était une checklist standardisée : toujours attacher l’ISO VirtIO, toujours installer le package VirtIO et l’agent QEMU, toujours vérifier que le Gestionnaire de périphériques est propre, toujours snapshotter avant de changer les contrôleurs disque.

Puis un projet de montée de version est arrivé : passer les VMs Windows à VirtIO SCSI single pour la performance et la cohérence opérationnelle. Ce n’était pas glamour. C’était beaucoup de répétitions : ajouter un second disque VirtIO, démarrer, confirmer le pilote, arrêter, changer le contrôleur, démarrer, valider, retirer le disque de préparation.

Au milieu du déploiement, une VM a refusé de démarrer après la bascule. Pas de drame. Ils ont revert avec le snapshot, démarré, découvert que l’ISO VirtIO montée était une ancienne build avec des problèmes de signature sous leurs réglages Secure Boot, mis à jour l’ISO, préparé les pilotes à nouveau et terminé la migration.

Pas de ticket incident, pas d’appel d’urgence, pas d’attention exécutive. L’ennuyeux a gagné. En production, l’ennuyeux est souvent le compliment le plus méritoire.

Une citation opérationnelle (idée paraphrasée)

Idée paraphrasée (Werner Vogels) : « Tout échoue, tout le temps », donc concevez systèmes et procédures en supposant que l’échec est normal.

FAQ

1) Quel pilote VirtIO dois-je utiliser : vioscsi ou viostor ?

VirtIO SCSI (contrôleur SCSI Proxmox réglé sur VirtIO SCSI / VirtIO SCSI single) nécessite typiquement vioscsi. VirtIO Block (disque virtio0) nécessite viostor. Vérifiez qm config pour confirmer ce que vous avez réellement configuré.

2) Pourquoi Linux voit le disque mais Windows non ?

Les kernels Linux incluent généralement les pilotes VirtIO par défaut. Windows n’inclut pas les pilotes de stockage VirtIO dans l’environnement d’installation, vous devez donc les charger depuis l’ISO VirtIO.

3) Puis-je installer Windows sur SATA d’abord et passer à VirtIO plus tard ?

Oui, c’est un contournement tactique raisonnable. Ne changez pas à chaud le contrôleur du disque de démarrage sans préparer le pilote. Ajoutez un second disque VirtIO, installez les pilotes, confirmez la détection, puis basculez.

4) J’ai chargé un pilote dans Windows Setup mais le disque n’apparaît toujours pas. Et maintenant ?

Revérifiez le type de contrôleur (VirtIO SCSI vs VirtIO Block), le dossier du pilote (bonne version Windows + amd64) et confirmez que l’ISO VirtIO est effectivement montée. Si les logs hôte montrent des erreurs I/O, arrêtez et corrigez d’abord le stockage hôte.

5) Windows 11 Secure Boot bloque les pilotes VirtIO ?

Cela peut arriver si vous utilisez une ISO VirtIO obsolète avec des problèmes de signature par rapport à votre politique Secure Boot. Utilisez une ISO VirtIO récente et gardez cohérentes les options de firmware VM (UEFI reste UEFI).

6) Quel est le meilleur choix de contrôleur disque pour Windows sur Proxmox ?

Pour la majorité des charges en production : VirtIO SCSI single avec disques SCSI. Bon compromis entre performance, fonctionnalités et prévisibilité opérationnelle.

7) J’ai changé le contrôleur et la VM ne démarre plus. Récupération la plus rapide ?

Remettez le disque sur l’ancien contrôleur (SATA/IDE) pour que Windows démarre. Ensuite installez correctement les pilotes VirtIO (de préférence en ajoutant un disque VirtIO secondaire). Une fois les pilotes confirmés, retentez le changement de contrôleur.

8) Ai-je besoin du QEMU Guest Agent pour la visibilité disque ?

Non. Ce n’est pas un pilote de stockage. Mais vous le voulez pour des arrêts propres, une meilleure orchestration et moins de moments « pourquoi cette VM ne s’arrête pas ».

9) Dois-je activer discard (TRIM) sur le disque virtuel ?

Si votre backend bénéficie de la libération d’espace (thin provisioning, pools SSD) et que vous comprenez le comportement de la pile de stockage, oui. Si vous n’êtes pas sûr, commencez de façon conservatrice et mesurez. Un mauvais comportement de discard ne masquera généralement pas le disque, mais peut créer des surprises de performance.

10) Pourquoi l’ISO VirtIO a-t-elle autant de dossiers ?

Parce que les versions de Windows et les exigences de signature diffèrent, et les pilotes sont packagés par famille d’OS et architecture. L’installateur a besoin de l’ensemble exact inf/sys/cat. « À peu près » ne fonctionne pas avec les pilotes Windows.

Conclusion : étapes suivantes pour rester tranquille

Si Windows ne voit pas votre disque sur Proxmox, traitez cela comme un désaccord contractuel : Proxmox présente un contrôleur ; Windows a besoin du bon pilote pour lui parler. Corrigez le décalage, ne naviguez pas au hasard dans les paramètres.

Nouvelles installations : utilisez VirtIO SCSI single dès le départ et chargez vioscsi dans Setup depuis l’ISO VirtIO.
Installations existantes : préparez d’abord les pilotes (ajoutez un disque VirtIO secondaire), puis changez le disque/contrôleur de démarrage.
Quand ça ne marche toujours pas : validez la santé du stockage hôte et le mappage VM avec des commandes, pas avec des intuitions.

Faites cela de manière consistante et vous éviterez de répéter le rituel « Windows ne trouve pas le disque ». Vous dormirez aussi mieux — et c’est la vraie métrique de performance.