VM Windows sur Proxmox sans réseau : correctifs de pilote VirtIO qui fonctionnent

Playbook de diagnostic rapide

Si vous n’avez que 10 minutes et un manager qui surveille, faites ceci dans l’ordre. L’objectif est de trouver le premier saut cassé : Windows ↔ pilote VirtIO ↔ tap QEMU ↔ pont Proxmox ↔ NIC physique ↔ réseau/DHCP en amont.

1) Prouvez si la VM émet du trafic du tout

• Sur l’hôte Proxmox, identifiez l’interface tap de la VM et reniflez l’ARP/DHCP.
• S’il n’y a aucun trafic, le problème est à l’intérieur du guest (pilote, adaptateur désactivé, pile IP, discordance d’étiquette VLAN dans la config VM).
• S’il y a du trafic mais pas de réponses, c’est à l’extérieur du guest (pont, pare-feu, VLAN, commutateur en amont, DHCP).

2) Validez le câblage du pont Proxmox

• La NIC de la VM est-elle attachée au pont prévu (généralement vmbr0) ?
• vmbr0 est-il réellement connecté à la NIC physique ou au bond que vous pensez ?
• Le pare-feu Proxmox bloque-t-il silencieusement l’egress ou le DHCP ?

3) Validez l’adaptateur et le pilote Windows

• Windows voit-il un périphérique NIC du tout ?
• S’il le voit, le pilote est-il chargé et signé ? (NetKVM)
• ipconfig /all montre-t-il une tentative DHCP ou seulement APIPA (169.254.x.x) ?

4) Ensuite seulement, poursuivez les causes « avancées »

• Étiquetage VLAN et configuration de trunk.
• Discordance MTU / trames jumbo partiellement supportées.
• Multi-queue / offloads interagissant mal avec certaines chaînes de commutation/filtrage virtuel.
• Profil réseau Windows et règles de pare-feu (moins fréquent qu’on le croit, mais réel).

Modèle mental : où les paquets meurent

Les pannes réseau sont plus faciles à résoudre si vous les traitez comme la latence de stockage : vous cartographiez le pipeline, puis measurez chaque étape. Une VM Windows sur Proxmox ressemble typiquement à :

1. Pile réseau Windows (IP/DHCP/ARP) parlant à…
2. Périphérique NIC VirtIO (virtio-net dans QEMU), utilisant…
3. Pilote NetKVM (pilote virtio-net Windows), alimentant des paquets vers…
4. Interface tap QEMU (par ex. tap100i0) sur l’hôte, connectée à…
5. Pont Linux (vmbr0) éventuellement avec filtrage VLAN, puis…
6. NIC/bond physique (par ex. eno1, bond0) vers…
7. Port du commutateur avec politique trunk/access, puis…
8. Amont : passerelle, DHCP et tous les appliances de sécurité qui veulent s’en mêler.

Votre travail est de décider quelle couche ment. Et quelque chose ment toujours.

Une citation qui reste collée dans beaucoup d’esprits ops : L’espoir n’est pas une stratégie. — idée paraphrasée couramment attribuée dans les cercles opérationnels/fiabilité.

Faits intéressants et contexte historique (pour comprendre l’étrangeté)

• VirtIO a été créé pour éviter le coût d’émulation. Les NIC émuleés comme Intel E1000 sont pratiques, mais elles consomment du CPU parce que l’hyperviseur fait semblant d’être du matériel d’une autre époque.
• Le mythe « E1000 fonctionne partout » coûte cher. Il fonctionne souvent « tout de suite » sur Windows sans pilotes additionnels, mais à haut débit il peut devenir votre goulot d’étranglement avant que vous ne le remarquiez.
• Windows n’incluait pas les pilotes VirtIO par défaut. Contrairement à beaucoup de distributions Linux, Windows nécessite typiquement l’ISO VirtIO (ou des pilotes pré-injectés) pour le stockage et le réseau.
• Le nom du pilote VirtIO compte. Le pilote Windows s’appelle typiquement NetKVM ; mélanger des versions peut provoquer des échecs étranges après des mises à jour Windows renforçant les politiques de pilotes.
• QEMU/Proxmox peut présenter plusieurs modèles NIC. VirtIO (paravirtualisé), E1000, RTL8139 (ancien), et d’autres. Choisir le mauvais est une décision de performance et de support.
• Le bridging sur Linux n’est pas magique. Un pont Linux est un switch logiciel. Si vous attachez mal un port (tap) ou mal configurez le filtrage VLAN, vos paquets n’iront nulle part avec un silence impressionnant.
• Le pare-feu Proxmox est stateful et en couches. Il existe Datacenter, Nœud et VM. Une règle permissive dans une couche n’aide pas si une autre couche droppe en premier.
• APIPA (169.254/16) est le badge « j’ai essayé » de Windows. Cela signifie que DHCP a échoué. Cela ne veut pas dire que la NIC est bonne ; cela signifie que Windows a expiré en attendant un bail.
• UEFI/Secure Boot change l’acceptation des pilotes. Certaines configurations Windows avec Secure Boot activé peuvent rejeter les pilotes non signés ou mal signés, y compris des builds VirtIO anciens.

D’abord, nommez précisément le symptôme

« Pas de réseau » est une plainte, pas un diagnostic. Choisissez le symptôme le plus proche ; il détermine le chemin le plus rapide.

Symptôme A : Windows n’affiche aucun adaptateur Ethernet

Généralement : mauvais modèle NIC, pilote VirtIO manquant, périphérique désactivé, ou Windows qui le cache à cause de périphériques fantômes.

Symptôme B : L’adaptateur existe, mais a 169.254.x.x (APIPA)

Généralement : le DHCP n’atteint pas la VM, les réponses DHCP n’atteignent pas Windows, ou la NIC est bloquée dans un état bizarre lié au pilote/offload.

Symptôme C : A une IP, mais ne peut pas pinger la passerelle

Généralement : discordance VLAN, mauvais pont, règle pare-feu qui droppe, sous-réseau/passerelle incorrecte, ou politique du commutateur en amont.

Symptôme D : Fonctionne brièvement, puis meurt (ou meurt après migration/reboot)

Généralement : conflit MAC, IP dupliquée, état du pare-feu Proxmox, régression de pilote Windows après mise à jour, ou offloads/queues interagissant mal.

Blague #1 : DHCP est comme une réceptionniste — si vous ne pouvez pas l’atteindre, vous resterez dans le hall pour toujours et blâmerez le bâtiment.

Vérifications côté hôte (Proxmox) : ponts, taps, pare-feu, VLAN

Ne commencez pas à l’intérieur de Windows. Commencez là où vous avez les meilleurs outils : l’hôte Proxmox. Vous pouvez y observer la réalité.

Task 1: Confirmez que la NIC de la VM est attachée au pont que vous pensez

cr0x@server:~$ qm config 100 | grep -E '^net[0-9]+:'
net0: virtio=DE:AD:BE:EF:10:00,bridge=vmbr0,firewall=1,tag=20

Ce que signifie la sortie : La VM 100 a une NIC VirtIO avec MAC DE:AD:BE:EF:10:00 attachée à vmbr0, avec le pare-feu Proxmox activé, VLAN tag 20.

Décision : Si bridge= est faux (par ex. vmbr1 alors que vous vouliez vmbr0), corrigez la config VM avant de toucher à Windows. Si tag= existe, vous devez confirmer que le VLAN 20 est correct de bout en bout.

Task 2: Vérifiez que le pont existe et a les ports attendus

cr0x@server:~$ bridge link show
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master vmbr0 state forwarding priority 32 cost 100
5: tap100i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master vmbr0 state forwarding priority 32 cost 100

Ce que signifie la sortie : La NIC physique eno1 et le tap VM tap100i0 sont tous deux esclaves de vmbr0. C’est le câblage de base.

Décision : Si vous ne voyez pas le tap sur le pont correct, la VM n’est pas connectée. Redémarrez la VM, ou inspectez la config réseau de Proxmox et l’affectation NIC de la VM.

Task 3: Confirmez que le pont et les NIC sont UP

cr0x@server:~$ ip -br link show vmbr0 eno1 tap100i0
vmbr0            UP             5a:9a:12:34:56:78 <BROADCAST,MULTICAST,UP,LOWER_UP>
eno1             UP             3c:fd:fe:aa:bb:cc <BROADCAST,MULTICAST,UP,LOWER_UP>
tap100i0         UP             fe:54:00:12:34:56 <BROADCAST,MULTICAST,UP,LOWER_UP>

Ce que signifie la sortie : Les liens sont administrativement up et le carrier est présent (LOWER_UP).

Décision : Si vmbr0 est DOWN, vous avez un problème réseau hôte. Si seul le tap est DOWN, regardez l’état runtime de la VM ou des problèmes de processus QEMU.

Task 4: Vérifiez la config réseau Proxmox pour des erreurs évidentes de câblage

cr0x@server:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.0.2.10/24
        gateway 192.0.2.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0

Ce que signifie la sortie : vmbr0 est un pont Linux avec eno1 comme port ; l’hôte a une IP sur le pont, pas sur eno1. C’est normal pour Proxmox.

Décision : Si l’IP hôte est sur la NIC physique au lieu du pont, les VMs n’atteindront pas le réseau via le pont comme prévu. Corrigez prudemment (idéalement via une fenêtre de maintenance ou un accès console).

Task 5: Confirmez que l’interface tap existe pour cette VM et mappe vers le bon processus QEMU

cr0x@server:~$ ps -ef | grep -E 'kvm.*-id 100\b' | head -n 1
root     21488     1 35 10:21 ?        00:14:12 /usr/bin/kvm -id 100 -name WIN-APP01 ...

Ce que signifie la sortie : QEMU/KVM tourne pour la VM 100.

Décision : Si QEMU ne tourne pas, vous déboguez une VM qui n’est pas réellement up. Résolvez le problème de boot de la VM d’abord.

Task 6: Vérifiez si l’hôte voit du trafic sur le tap de la VM (ARP/DHCP suffit)

cr0x@server:~$ tcpdump -ni tap100i0 -c 10 -vv
tcpdump: listening on tap100i0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:25:11.100001 ARP, Request who-has 192.0.2.1 tell 0.0.0.0, length 46
10:25:11.200002 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from de:ad:be:ef:10:00, length 300
10:25:12.200010 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from de:ad:be:ef:10:00, length 300

Ce que signifie la sortie : La VM émet des requêtes ARP et DHCP. Le périphérique VirtIO et la pile Windows essaient au moins.

Décision : Si vous voyez des requêtes mais pas de réponses, concentrez-vous sur le pont/pare-feu/VLAN/amont DHCP. Si vous ne voyez rien, concentrez-vous à l’intérieur de Windows (pilote ou adaptateur désactivé) ou sur l’attachement NIC VM dans Proxmox.

Task 7: Reniflez sur le pont ou la NIC physique pour voir si les paquets quittent l’hôte

cr0x@server:~$ tcpdump -ni eno1 -c 10 -vv 'port 67 or port 68 or arp'
tcpdump: listening on eno1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:25:11.200002 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from de:ad:be:ef:10:00, length 300
10:25:11.250123 IP 192.0.2.5.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 310

Ce que signifie la sortie : Les requêtes DHCP de la VM atteignent la NIC physique, et des réponses DHCP reviennent à l’hôte.

Décision : Si des réponses sont présentes sur eno1 mais que Windows a toujours APIPA, le chemin de retour hôte→VM est cassé (pare-feu, filtrage du pont, discordance d’étiquette VLAN, ou la VM ne reçoit pas réellement les trames).

Task 8: Vérifiez l’état du pare-feu Proxmox au niveau datacenter/nœud/VM

cr0x@server:~$ pve-firewall status
Status: enabled/running

Ce que signifie la sortie : Le service pare-feu Proxmox est activé et en cours. Cela ne veut pas dire qu’il bloque, mais il peut le faire.

Décision : Si vous dépannez une panne en production et que les règles sont incertaines, désactivez temporairement le pare-feu au niveau VM pour isoler (puis réactivez avec les règles correctes).

Task 9: Inspectez rapidement le réglage de pare-feu de la VM

cr0x@server:~$ qm config 100 | grep -E '^net0:'
net0: virtio=DE:AD:BE:EF:10:00,bridge=vmbr0,firewall=1,tag=20

Ce que signifie la sortie : firewall=1 veut dire que des règles de pare-feu au niveau VM s’appliquent.

Décision : Pour isoler, mettez firewall=0 (court terme) et retestez DHCP/ping. Si cela corrige le problème, vous savez où concentrer votre temps.

Task 10: Vérifiez le filtrage VLAN et l’appartenance VLAN sur le pont

cr0x@server:~$ bridge vlan show | sed -n '1,120p'
port              vlan-id
eno1              1 PVID Egress Untagged
eno1              20
tap100i0          20 PVID Egress Untagged

Ce que signifie la sortie : Le tap VM est en non-taggué sur le VLAN 20 (PVID 20), et l’uplink eno1 transporte le VLAN 20. C’est cohérent avec une VM configurée avec tag=20 selon votre mode de pont.

Décision : Si le VLAN 20 est absent sur l’uplink, la VM est piégée dans une île VLAN. Corrigez la config VLAN du pont ou le trunk du commutateur en amont.

Task 11: Vérifiez les drops ebtables/nftables (commun quand le pare-feu existe)

cr0x@server:~$ nft list ruleset | sed -n '1,120p'
table inet filter {
  chain forward {
    type filter hook forward priority filter; policy drop;
    ct state established,related accept
    iifname "tap100i0" oifname "vmbr0" accept
  }
}

Ce que signifie la sortie : La politique forward est drop, avec un chemin accept spécifique. Si votre ruleset ne permet pas correctement le DHCP (broadcast), vous aurez APIPA pour toujours.

Décision : Si la politique est drop et que vous n’êtes pas sûr que les règles couvrent votre cas, corrigez les règles ou ouvrez temporairement le forwarding pour cette VM pour valider l’hypothèse.

Task 12: Confirmez qu’il n’y a pas de bizarrerie d’apprentissage MAC ou de duplicata visibles

cr0x@server:~$ bridge fdb show br vmbr0 | grep -i 'de:ad:be:ef:10:00'
de:ad:be:ef:10:00 dev tap100i0 master vmbr0 permanent

Ce que signifie la sortie : Le pont sait que le MAC VM est sur tap100i0. C’est attendu.

Décision : Si vous voyez le même MAC sur plusieurs taps, vous avez cloné une VM sans régénérer les MAC. Corrigez les collisions MAC ; elles provoquent le symptôme « fonctionne parfois » qui est le plus coûteux.

Vérifications de la config VM : modèle NIC, MAC, queues, BIOS/UEFI

Choisissez le modèle NIC délibérément

Sur Proxmox, vous pouvez choisir le modèle NIC par VM. Voici les conseils pratiques :

• VirtIO : meilleure performance et moindre coût CPU. Nécessite des pilotes sous Windows.
• E1000/E1000e : bon pour « je veux que ça démarre et parle maintenant », mais la performance peut être médiocre sous charge.
• RTL8139 : ne pas utiliser. Il existe pour hanter les labos et environnements de formation.

Task 13: Vérifiez que le modèle NIC est VirtIO (si c’est l’objectif)

cr0x@server:~$ qm config 100 | grep -E '^net0:'
net0: virtio=DE:AD:BE:EF:10:00,bridge=vmbr0,firewall=1,tag=20

Ce que signifie la sortie : C’est VirtIO. Bien. Maintenant Windows doit avoir NetKVM.

Décision : S’il s’agit de e1000 et que vous visez la performance, basculez vers VirtIO après avoir préparé les pilotes (ou attachez une deuxième NIC temporairement pour migrer).

Task 14: Ajoutez temporairement une seconde NIC pour amorcer l’installation du pilote

C’est une astuce propre : ajoutez une NIC E1000 comme bouée de sauvetage, puis installez les pilotes VirtIO, ensuite retirez l’E1000. Ça réduit la chirurgie panique des pilotes.

cr0x@server:~$ qm set 100 -net1 e1000,bridge=vmbr0
update VM 100: -net1 e1000,bridge=vmbr0

Ce que signifie la sortie : La VM a maintenant une seconde NIC que Windows reconnaîtra probablement sans pilotes supplémentaires.

Décision : Si Windows revient en ligne via E1000, vous avez prouvé que le chemin réseau est OK et que le pilote VirtIO est le problème. Installez NetKVM, puis retirez l’E1000.

Multi-queue et offloads : ne devenez pas trop ingénieux pendant une panne

La NIC VirtIO supporte plusieurs queues pour le débit et le parallélisme. Génial quand c’est bien réglé. C’est aussi une source de problèmes fantômes quand vous combinez certaines versions Windows, pilotes anciens et filtrages de sécurité.

Task 15: Vérifiez la topologie CPU actuelle et considérez le nombre de queues NIC

cr0x@server:~$ qm config 100 | grep -E '^(sockets|cores|cpu):'
cores: 8
cpu: x86-64-v2-AES
sockets: 1

Ce que signifie la sortie : La VM a 8 vCPU. Le multi-queue peut aider, mais seulement si les pilotes et les charges en bénéficient.

Décision : Si vous êtes en mode récupération, conservez les valeurs par défaut. Tirez les réglages plus tard avec des mesures, pas des intuitions.

Vérifications sous Windows : état du pilote, adaptateurs cachés, DHCP, métriques

Maintenant vous entrez dans le guest. Utilisez l’accès console depuis Proxmox si le RDP est en panne (probablement). Si Windows ne voit pas l’adaptateur, aucune prière DHCP ne vous aidera.

Task 16: Listez les adaptateurs et vérifiez si Windows voit quelque chose

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Format-Table -Auto Name,Status,LinkSpeed,MacAddress"
Name            Status LinkSpeed MacAddress
----            ------ --------- ----------
Ethernet        Up     1 Gbps    DE-AD-BE-EF-10-00

Ce que signifie la sortie : Windows voit un adaptateur, il est up, et le MAC correspond. C’est un bon signe.

Décision : S’il n’y a aucun adaptateur listé (ou seulement « Disconnected » sans lien), passez à l’installation du pilote et aux vérifications du Gestionnaire de périphériques.

Task 17: Vérifiez la configuration IP et si DHCP a réussi

cr0x@server:~$ ipconfig /all
Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . : Red Hat VirtIO Ethernet Adapter
   Physical Address. . . . . . . . . : DE-AD-BE-EF-10-00
   DHCP Enabled. . . . . . . . . . : Yes
   Autoconfiguration IPv4 Address. . : 169.254.22.10(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.0.0
   Default Gateway . . . . . . . . . :
   DHCP Server . . . . . . . . . . . :

Ce que signifie la sortie : Adresse APIPA. Le DHCP n’a pas abouti. Soit les requêtes ne partent pas, soit les réponses n’arrivent pas, soit le DHCP est bloqué.

Décision : Corrélez avec les tâches tcpdump sur l’hôte. Si l’hôte voit des réponses DHCP mais que Windows n’obtient pas de bail, suspectez le pare-feu VM/filtrage du pont ou des problèmes de pilote.

Task 18: Forcez un renouvellement DHCP et regardez les erreurs

cr0x@server:~$ ipconfig /release
Windows IP Configuration

No operation can be performed on Ethernet while it has its media disconnected.

cr0x@server:~$ ipconfig /renew
Windows IP Configuration

An error occurred while renewing interface Ethernet : unable to contact your DHCP server. Request has timed out.

Ce que signifie la sortie : Soit Windows croit que le lien est down (« media disconnected »), soit les requêtes DHCP ne sont pas répondues.

Décision : Si « media disconnected », suspectez un problème de pilote/virtio ou d’attachement tap/bridge Proxmox. Si seulement timeout DHCP, suspectez l’amont ou le pare-feu/VLAN.

Task 19: Vérifiez l’état du pilote via PowerShell

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class Net | Format-Table -Auto Status,Problem,Class,FriendlyName"
Status Problem Class FriendlyName
------ ------- ----- ------------
OK     0       Net   Red Hat VirtIO Ethernet Adapter

Ce que signifie la sortie : Le périphérique est sain du point de vue PnP.

Décision : Si Status est Error ou Problem non nul, vous devez installer/mettre à jour le pilote ou réénumérer le périphérique.

Task 20: Cherchez des NIC cachées/ghost qui volent la config

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class Net -Status Unknown,Error | Format-Table -Auto FriendlyName,Status,Problem"
FriendlyName                         Status   Problem
------------                         ------   -------
Microsoft Kernel Debug Network Adapter Error    28

Ce que signifie la sortie : Vous pouvez avoir des adaptateurs obsolètes ou des adaptateurs de debug qui interfèrent, selon l’environnement.

Décision : Supprimez les adaptateurs obsolètes dans le Gestionnaire de périphériques (afficher les périphériques cachés) si vous avez des changements de MAC ou des créations répétées de NIC.

Task 21: Testez la pile locale vs externe avec ping + table de routage

cr0x@server:~$ route print
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.0.2.1       192.0.2.50     25
        192.0.2.0    255.255.255.0         On-link      192.0.2.50    281
===========================================================================

cr0x@server:~$ ping -n 3 192.0.2.1
Pinging 192.0.2.1 with 32 bytes of data:
Reply from 192.0.2.1: bytes=32 time<1ms TTL=64
Reply from 192.0.2.1: bytes=32 time<1ms TTL=64
Reply from 192.0.2.1: bytes=32 time<1ms TTL=64

Ce que signifie la sortie : Le routage est sain, la passerelle joignable. Si DNS ou l’extérieur échoue, vous avez réduit le problème.

Décision : Si le ping passerelle échoue alors que vous avez un bail, suspectez une discordance VLAN, un pare-feu ou une sécurité de port en amont.

Correctifs pilotes VirtIO : installer, mettre à jour et récupérer

VirtIO sur Windows n’est pas compliqué, mais il est impitoyable face aux pilotes à moitié installés, aux ISOs obsolètes et aux incompatibilités Secure Boot. L’approche la plus propre : montez l’ISO du pilote VirtIO dans Proxmox, installez NetKVM proprement, et redémarrez une fois.

Stagez l’ISO du pilote VirtIO (côté hôte)

Task 22: Confirmez le stockage ISO et la présence de l’ISO VirtIO

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local            dir      active       100000000        20000000         80000000       20%
local-lvm        lvmthin  active       500000000       250000000        250000000       50%

cr0x@server:~$ ls -lh /var/lib/vz/template/iso | grep -i virtio
-rw-r--r-- 1 root root  520M Aug  1 09:12 virtio-win.iso

Ce que signifie la sortie : Votre stockage ISO est disponible et l’ISO VirtIO est présent.

Décision : Si l’ISO est manquante, vous ne pouvez pas installer les pilotes sans autre voie (par ex. injection de pilotes ou utilisation d’un lifeline E1000). Importez l’ISO dans le stockage ISO d’abord.

Attachez l’ISO à la VM (côté hôte)

Task 23: Attachez l’ISO VirtIO comme CD-ROM

cr0x@server:~$ qm set 100 -ide2 local:iso/virtio-win.iso,media=cdrom
update VM 100: -ide2 local:iso/virtio-win.iso,media=cdrom

Ce que signifie la sortie : La VM a l’ISO de pilote attaché.

Décision : Démarrez Windows, puis installez/ mettez à jour le pilote NetKVM depuis le CD monté.

Installez/mettez à jour NetKVM dans Windows

Vous pouvez le faire via le Gestionnaire de périphériques, mais en production je préfère des commandes reproductibles. Néanmoins, l’interface GUI est acceptable si vous êtes sur la console et que le temps presse.

Task 24: Confirmez que le CD VirtIO est visible et localisez le INF NetKVM

cr0x@server:~$ powershell -NoProfile -Command "Get-Volume | Where-Object DriveLetter | Format-Table -Auto DriveLetter,FileSystemLabel"
DriveLetter FileSystemLabel
----------- ---------------
D           virtio-win

cr0x@server:~$ powershell -NoProfile -Command "Get-ChildItem -Path D:\NetKVM -Recurse -Filter netkvm.inf | Select-Object -First 3 FullName"
FullName
--------
D:\NetKVM\w10\amd64\netkvm.inf

Ce que signifie la sortie : Le INF du pilote est accessible pour les variantes Windows 10/Server sur amd64.

Décision : Utilisez pnputil pour ajouter/installer le pilote depuis le répertoire approprié pour votre OS.

Task 25: Ajoutez et installez le pilote NetKVM avec pnputil

cr0x@server:~$ pnputil /add-driver D:\NetKVM\w10\amd64\netkvm.inf /install
Microsoft PnP Utility

Driver package added successfully.
Published Name: oem42.inf
Driver package installed on matching devices.

Ce que signifie la sortie : Le pilote est stagé et installé pour le matériel correspondant (votre NIC VirtIO).

Décision : Redémarrez la VM. Oui, redémarrez. Les installations de pilotes qui « ne nécessitent pas de redémarrage » sont la cause de fantômes à déboguer.

Task 26: Vérifiez que la description de l’adaptateur est VirtIO et que le lien est up après reboot

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Format-Table -Auto Name,Status,InterfaceDescription"
Name     Status InterfaceDescription
----     ------ --------------------
Ethernet Up     Red Hat VirtIO Ethernet Adapter

Ce que signifie la sortie : NetKVM fonctionne et l’interface est up.

Décision : Si le statut reste Down/Disconnected alors que l’hôte voit du trafic, vérifiez les étiquettes VLAN, le pare-feu Proxmox et les paramètres avancés d’adaptateur Windows.

Quand Secure Boot ou la signature de pilote vous bloquent

Si Windows refuse le pilote (Code 52, problèmes de signature), vous avez trois options sensées :

• Utiliser une build VirtIO plus récente correctement signée pour votre version de Windows et la politique Secure Boot.
• Désactiver Secure Boot pour cette VM (si votre politique le permet ; beaucoup d’entreprises ne le feront pas).
• Bascule temporairement le modèle NIC vers E1000 pour restaurer l’accès, puis planifiez un déploiement contrôlé des pilotes VirtIO.

Task 27: Vérifiez les problèmes de périphérique liés à la signature du pilote

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDevice -Class Net | Where-Object Status -ne 'OK' | Format-Table -Auto FriendlyName,Status,Problem"
FriendlyName                         Status Problem
------------                         ------ -------
Red Hat VirtIO Ethernet Adapter       Error  52

Ce que signifie la sortie : Le problème 52 indique généralement que Windows ne peut pas vérifier la signature du pilote.

Décision : Mettez à jour vers une version signée du pilote adaptée à votre OS, ou changez les paramètres Secure Boot selon la politique. Ne désactivez pas l’enforcement de signature en production à moins d’aimer les audits.

Blague #2 : Une VM sans pilote NIC, c’est comme une conférence téléphonique en sourdine — tout le monde est techniquement connecté, et rien d’utile ne se passe.

Trois mini-histoires du monde corporate (celles qui ruinent les vendredis)

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

Une équipe a migré une petite flotte de serveurs utilitaires Windows depuis un cluster VMware vieillissant vers Proxmox. Le plan était « simple » : recréer les VMs, attacher les disques, utiliser VirtIO partout, célébrer. Le premier serveur a démarré, les services semblaient sains, puis la supervision a alerté : pas de métriques, pas de RDP, pas de patching, pas de trafic de domaine.

L’hypothèse était que Windows « trouverait la NIC finalement ». Ils avaient été gâtés par E1000 dans d’autres environnements et pensaient que VirtIO était une optimisation de performance, pas un changement matériel nécessitant un pilote. La console montrait un vide familier : aucun adaptateur, pas de catégorie réseau, et le Gestionnaire de périphériques avait un « Ethernet Controller » avec un point d’exclamation jaune.

Quelqu’un a essayé de réparer en réinstallant des composants réseau Windows et en réinitialisant Winsock. C’est comme polir le capot quand le moteur manque. La vraie correction était ennuyeuse : monter l’ISO VirtIO, installer NetKVM, redémarrer.

Le postmortem fut aussi ennuyeux, ce qui est le but : la checklist de build n’incluait pas « ISO VirtIO attachée » comme étape requise. L’équipe l’a ajoutée. La vague suivante de migrations s’est déroulée sans problème, et la seule panne fut celle qu’ils méritaient.

Mini-histoire 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation faisait tourner des VMs Windows de transferts de fichiers haute-débit sur Proxmox. Quelqu’un a lu que multi-queue VirtIO plus offloads agressifs pouvaient améliorer le débit. Ils ont poussé les réglages, augmenté les queues, et célébré la victoire sur un test synthétique.

Puis le trafic réel est arrivé. Sous charge, les transferts se bloquaient de façon intermittente. Les clients voyaient des timeouts. Les VMs avaient lien, IPs et pings parfaits. L’équipe a perdu des heures parce que la panne n’était pas totale ; c’était de la « bizarrerie », le mode de panne le plus consommateur de temps qui existe.

Sur l’hôte, tcpdump montrait des rafales de retransmissions. Dans Windows, les logs d’événements laissaient entendre des resets de pilote. Rien ne criait « problème d’offload », parce que ça crie rarement. Finalement ils ont annulé les tweaks d’offload et remis les queues par défaut. Le problème a disparu.

Plus tard, ils ont réintroduit les changements progressivement, une variable à la fois, et ont mesuré les taux de réussite des transferts de bout en bout au lieu du débit brut. L’optimisation n’a pas échoué parce que l’optimisation est mauvaise. Elle a échoué parce qu’ils ont optimisé sans plan de rollback et sans tests en charge réelle.

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

Une entreprise avait une règle : chaque template Windows incluait les pilotes VirtIO pré-stagés, même si le modèle NIC initial était E1000. La logique était simple : vous ne voulez pas découvrir des pilotes manquants pendant un appel d’intervention.

Ils exigeaient aussi que chaque VM ait une « NIC casse-glace » documentée : une seconde carte pouvant être activée temporairement (ou ajoutée rapidement) pour retrouver la connectivité. Ça paraît paranoïaque. C’est en fait une assurance peu coûteuse.

Lors d’une maintenance, un lot de VMs a rebooté et un sous-ensemble est revenu sans réseau VirtIO fonctionnel à cause d’une régression pilote après le patching. L’ingénieur on-call n’a pas débattu la métaphysique. Il a basculé ces VMs sur la NIC de secours, a récupéré l’accès, puis déployé la version NetKVM connue bonne.

Pas de nuit blanche héroïque, pas d’escalade fournisseur, pas d’éditions de registre aléatoires. Juste un plan d’évasion pratiqué et documenté. Le rapport d’incident fut court, et c’est la meilleure chose à dire d’un rapport d’incident.

Erreurs courantes : symptômes → cause racine → correction

1) Symbole : Windows affiche « Ethernet Controller » avec point d’exclamation jaune

Cause racine : NIC VirtIO présent, mais pilote NetKVM non installé.

Correction : Attachez l’ISO VirtIO, installez le pilote via le Gestionnaire de périphériques ou pnputil (Task 25), redémarrez.

2) Symbole : L’adaptateur existe, APIPA 169.254.x.x, aucun serveur DHCP affiché

Cause racine : Le trafic DHCP est bloqué ou n’atteint pas le serveur DHCP (discordance VLAN, pare-feu, mauvais pont).

Correction : tcpdump sur tap et uplink (Tasks 6–7). Si les réponses ne reviennent pas au tap, vérifiez le pare-feu Proxmox (Tasks 8–11) et la config VLAN (Task 10).

3) Symbole : L’hôte voit la réponse DHCP sur la NIC physique, Windows reste en APIPA

Cause racine : La réponse n’est pas renvoyée au tap (filtrage du pont, règles de pare-feu, discordance de filtrage VLAN).

Correction : Validez l’appartenance VLAN du pont (Task 10), le ruleset nftables (Task 11), et que le tap est sur le bon pont (Task 2).

4) Symbole : La VM a une IP, peut pinger l’IP du pont hôte, mais pas la passerelle

Cause racine : Discordance trunk/access VLAN sur le commutateur amont, ou taggage Proxmox qui ne correspond pas à la politique du port commutateur.

Correction : Confirmez le tag VM et la config VLAN du pont (Tasks 1, 10). Validez la config du port commutateur (hors Proxmox). Test rapide : retirez le tag VLAN et placez la VM en non-taggué sur le VLAN natif seulement si la politique le permet.

5) Symbole : Le réseau marche jusqu’à la migration à chaud, puis meurt

Cause racine : Config bridge/VLAN/pare-feu incohérente entre nœuds ; le vmbr0 du nœud de destination n’est pas identique.

Correction : Comparez /etc/network/interfaces et la config pare-feu entre nœuds. Standardisez les ponts et le filtrage VLAN partout. Ne traitez pas les nœuds du cluster comme des flocons de neige.

6) Symbole : Pertes aléatoires sous charge, pings globalement ok

Cause racine : Interaction offload/queue/pilote, ou discordance MTU sur une partie du chemin.

Correction : Revenez aux valeurs par défaut (queues/offloads), testez avec du trafic soutenu. Confirmez le MTU sur vmbr, tap, NIC physique et amont. Évitez les trames jumbo sauf si tout le chemin est vérifié.

7) Symbole : Deux VMs clonées ont toutes deux « le réseau », mais l’une est instable

Cause racine : MAC ou IP dupliqués, conflits ARP, sécurité de port du commutateur.

Correction : Assurez des MAC uniques dans la config Proxmox ; régénérez si nécessaire. Videz les caches ARP en amont si nécessaire. Utilisez la Task 12 pour détecter des duplications MAC sur le pont.

8) Symbole : Windows dit « Media disconnected » alors que la VM tourne

Cause racine : NIC non attachée au pont, tap manquant/down, ou pilote Windows qui ne se lie pas correctement.

Correction : Validez la présence du tap sur le pont (Task 2), l’état UP des interfaces (Task 3), et le statut PnP Windows (Task 19). Envisagez d’ajouter temporairement une E1000 lifeline (Task 14).

Checklists / plan étape par étape

Checklist A : Vous avez créé une nouvelle VM Windows et elle n’a aucun réseau

1. Sur l’hôte : qm config <vmid> | grep '^net' → confirmer bridge, tag, pare-feu.
2. Sur l’hôte : bridge link show → confirmer que le tap est esclave du pont prévu.
3. Sur l’hôte : tcpdump -ni tapX → confirmer s’il y a du trafic.
4. Si pas de trafic : dans Windows, vérifiez le Gestionnaire de périphériques pour NetKVM manquant ; montez l’ISO VirtIO et installez le pilote.
5. Si le trafic existe mais pas de réponses : vérifiez VLAN et pare-feu ; reniflez sur la NIC physique pour voir si les réponses reviennent.
6. Après installation du pilote : redémarrez ; vérifiez que ipconfig /all montre un bail, pas APIPA.

Checklist B : Vous avez converti d’E1000 à VirtIO et perdu l’accès

1. Ne paniquez pas. Ajoutez une seconde NIC E1000 (Task 14) pour restaurer l’accès.
2. Attachez l’ISO VirtIO (Task 23).
3. Installez NetKVM via pnputil (Task 25).
4. Redémarrez.
5. Confirmez que l’adaptateur VirtIO est up et a la bonne IP.
6. Retirez la NIC E1000 après vérification de la santé du service.

Checklist C : Adresse APIPA et timeouts DHCP

1. Hôte : tcpdump -ni tap... — voyez-vous DHCP DISCOVER/REQUEST ?
2. Hôte : tcpdump -ni eno1 ... — voyez-vous les réponses DHCP revenir ?
3. Si les réponses ne reviennent pas : DHCP amont ou port commutateur incorrect.
4. Si les réponses reviennent à l’hôte mais pas à la VM : filtrage pare-feu/bridge/VLAN sur l’hôte.
5. Désactivez temporairement le pare-feu VM pour isoler, puis réactivez avec les règles correctes.
6. Après validation du chemin : envisagez une mise à jour du pilote ou un réglage des offloads.

Checklist D : Problèmes de migration dans le cluster

1. Comparez les ponts entre nœuds (/etc/network/interfaces), incluant le filtrage VLAN.
2. Confirmez une posture pare-feu identique entre nœuds.
3. Validez la cohérence des noms de NIC uplink (eno1 vs enpXsY).
4. Exécutez les mêmes tests tcpdump sur nœud source et destination.
5. Standardisez la configuration ; ne patchez pas par nœud sauf si vous aimez les incidents récurrents.

FAQ

1) Dois-je simplement utiliser E1000 pour que Windows fonctionne toujours ?

Pour un secours ponctuel, E1000 convient. En production, préférez VirtIO une fois les pilotes en place. E1000 est un choix par défaut facile qui devient un impôt de performance plus tard.

2) Ma VM Windows affiche APIPA. Est-ce que ça prouve que le pilote VirtIO est installé ?

Pas nécessairement. Cela prouve que Windows a une interface et a tenté DHCP. Vous devez encore vérifier que le périphérique est bien l’adaptateur VirtIO et que le pilote est sain.

3) Le pare-feu Proxmox peut-il casser le DHCP ?

Oui. DHCP utilise beaucoup de broadcasts et peut être bloqué par des politiques par défaut en drop ou des règles manquantes. Si vous voyez des réponses DHCP sur l’uplink mais pas sur le tap, suspectez le filtrage pare-feu/bridge.

4) Ai-je besoin de QEMU Guest Agent pour le réseau ?

Non. Le Guest Agent aide au reporting IP, shutdown et certaines automatisations. Il ne fait pas fonctionner la NIC. Mais il facilite la vie une fois la NIC opérationnelle.

5) Pourquoi ça marche sur un nœud mais pas après migration ?

Parce que les nœuds du cluster dérivent. Quelqu’un a « patché vite fait » un pont ou un filtrage VLAN sur un hôte. La migration a déplacé la VM dans une autre réalité. Standardisez la config réseau sur tous les nœuds.

6) Que faire si Secure Boot est activé et que NetKVM ne se charge pas ?

Utilisez une version VirtIO signée appropriée pour votre build Windows. Si la politique le permet, désactivez Secure Boot pour la VM. Sinon, utilisez temporairement E1000 pendant que vous préparez des pilotes signés.

7) Le tag VLAN dans Proxmox peut-il entrer en conflit avec la config du port commutateur ?

Constamment. Si la VM est taggée VLAN 20 mais que le port commutateur est en access VLAN 1, vous n’aurez rien. Alignez le tag VM, le filtrage VLAN du pont et la politique du port physique.

8) Comment savoir si le problème est dans Windows ou dans le réseau Proxmox ?

Reniflez le trafic sur l’interface tap de la VM. Si vous voyez DHCP/ARP partir, Windows émet au moins. Si vous voyez des réponses sur l’uplink mais pas sur le tap, c’est côté hôte. Si vous ne voyez rien sur le tap, c’est pilote/état adaptateur guest ou attachement NIC VM.

9) Est-il sûr de désactiver les offloads ou réduire les queues pour corriger une instabilité ?

C’est sûr comme diagnostic et souvent sûr à long terme. Mesurez après les changements. Les offloads peuvent aider, mais aussi introduire des comportements difficiles à diagnostiquer selon le pilote et le filtrage.

10) Quel est le mouvement le plus rapide pour « me remettre en ligne » ?

Ajoutez une seconde NIC E1000, démarrez la VM, installez les pilotes VirtIO, puis retirez l’E1000. Pragmatique, réversible et sans devinerie.

Conclusion : prochaines étapes pour éviter les répétitions

Réparer une VM Windows sans réseau sur Proxmox n’est généralement pas une malédiction mystique de Windows. C’est un pilote VirtIO manquant, une discordance de pont, une politique de pare-feu ou une configuration VLAN presque correcte. Le chemin le plus rapide est toujours le même : vérifiez la config VM, observez le trafic sur le tap, confirmez le comportement du pont et de l’uplink, puis corrigez le pilote du guest seulement après avoir prouvé le chemin réseau.

Faites ceci ensuite :

1. Standardisez la politique NIC des VM : VirtIO par défaut, avec pilotes stagés dans les templates.
2. Gardez un chemin de secours : procédure documentée « ajouter NIC E1000 lifeline » pour les pannes.
3. Rendez le réseau du cluster identique : mêmes ponts, filtrage VLAN et posture pare-feu sur chaque nœud.
4. Opérationnalisez les vérifications : l’étape tcpdump sur le tap attrape la moitié des pannes en moins d’une minute.