Windows Server VM verliert sporadisch das NIC

[swdgtl]

Hallo zusammen,

wir haben sporadisch ein Problem auf manchen unserer Windows Server VMs, dass das Windows Betriebssystem das NIC verliert.
Im Proxmox ist das NIC hardwareseitig weiterhin zugewiesen.
Sobald ich die VM neustarte ist das NIC sofort wieder da und hat weiterhin die richtige IP-Konfiguration.
Das Thema ist nun bereits zwei oder drei mal auf einer Windows Server 2025 VM passiert und heute das erste mal auf einer Windows Server 2016 VM.
Bei der 2025er VM habe ich mal die Thematik mit Screenshots festgehalten - siehe anbei.

Kurz zur Umgebung:
Proxmox VE 9.2.2 über das Enterprise Repository
Netzwerk kommt über eine Linux Bridge mit VLAN welche auf einen Linux Bond (LACP 802.3ad) verweist
Die 2025er VM ist folgender Machine-Typ: pc-q35-10.1
Als NIC haben wir eine VirtIO (paravirtualized) Karte
VirtIO Windows Treiber v.0.1.271 inklusive Guest-Agent sind installiert

Falls Informationen fehlen, reiche ich diese gerne nach.

Über Tipps und Lösungsvorschläge wäre ich sehr froh!



Vor Reboot:




Nach Reboot:

 

[j.theisen]

Hallo @swdgtl

vielen Dank für deinen Post!

Kannst du in der betroffenen VM die Event Logs überprüfen ob dort etwas auf den Grund für das Verschwinden des NICs hindeutet?
Ggf. auch gerne einen Export machen und hier zur Verfügung stellen. Speziell das System Log müsste hier Aufschluss geben.

Wenn möglich auch bitte das journal des Proxmox VE Hosts überprüfen und ggf. hier anhängen.
journalctl --since "2026-06-23 08:00" --until "2026-06-24 15:00"
Die Timestamps bitte entsprechend anpassen

MfG
Jonas

 

[cwt]

Welche NICs sind denn im PVE verbaut? Ggf. "Problemkinder" von Intel oder Broadcom?

 

[swdgtl]

Welche NICs sind denn im PVE verbaut? Ggf. "Problemkinder" von Intel oder Broadcom?

Also fürs LAN haben wir ein LACP Bond auf folgenden Hardware NICs:
Intel Corporation Ethernet Connection X722 for 10GbE SFP+ (rev 09)

Für den ISCSI Traffic haben wir pro PVE zwei NICs via Linux Bridge in zwei verschiedenen ISCSI-Subnetzen mit Multipath konfiguriert:
Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 02)

Sind das problematische Karten?

 

[Falk R.]

Die Intel 7xx Reihe ist gerade bei iSCSI für Problemchen bekannt, aber ich glaube nicht, dass dieses Problem damit zusammenhängt.
Ich habe sowas auch noch nie gesehen, daher wären Logs echt nicht schlecht.
Hast du im Windows Gerätemanager mal einen rescan Hardware gemacht, wenn die NIC weg ist?

 

[swdgtl]

Hallo zusammen,

danke schonmal für die Rückmeldungen.

Zur Nebeninfo, es ist ein Terminalserver, wir starten diese täglich per Skript um 2 Uhr nachts neu.
Um 2.30 Uhr habe ich im Systemlog bereits Fehler, dass er seine Domäne nicht erreichen kann, ich denke das Fehlen der Netzwerkkarte hat also etwas mit dem Reboot zu tun.
Dann folgt periodisch immer wieder eine Warnung bzgl. der NTP-Synchronisation.
Die Warnmeldungen hören dann gegen 10.10 Uhr am 18.06.2026 auf, als ich den Server rebooted habe.

@Falk R. Ja ich glaube das habe ich beim ersten Mal gemacht, aber er hatte das NIC dennoch nicht gefunden, aber ich bin mir nicht ganz sicher. Reboot hatte das NIC in jedem Fall wieder hergestellt.

 

[Falk R.]

Hi, ich sehe da auch Meldungen von Veeam Backup. Hängen die Netzwerkverluste eventuell zeitlich mit den Backups zusammen?

 

[Bu66as]

Das leere Netzwerkverbindungen-Fenster ist das Wichtige: die Karte verschwindet komplett aus Windows, also ein PnP-Surprise-Removal und nicht nur Link weg. Schau im System-Log mal nach Kernel-PnP (Event 219) und netkvm-Einträgen zum Zeitpunkt, da müsste die Deregistrierung auftauchen.

Die Veeam-Spur von @Falk R. würd ich auf jeden Fall weiterverfolgen. Wenn das zeitlich mit dem Backup bzw. dem VSS-Snapshot zusammenfällt, ist der recht frische virtio-net 0.1.271 ein heißer Kandidat. Mit den neueren netkvm-Treibern gibt's schon Berichte, dass die NIC beim Quiescing wegfliegt und dann erst nach Reboot wiederkommt. Ich würd testweise mal auf ein stabiles virtio-win-Release runter (0.1.262 oder 0.1.240) und dann beobachten, ob's weg ist.

Zum schnellen Eingrenzen kannst du der VM auch temporär ne zweite NIC als e1000e verpassen. Wenn beim nächsten Vorfall nur die virtio dropt und die e1000e steht, ist's ziemlich sicher der netkvm-Treiber und nicht Bond/Bridge/Hardware.

 

[swdgtl]

Das es mit Veeam Backup zusammenhängt kann ich nicht ganz ausschließen.
Wir haben uns bewusst für 0.1.271 entschieden, gestartet sind wir initial mit der neusten Version 0.1.285, bis wir bei folgendem Artikel weit unten die Info gelesen haben, dass diese Version Probleme macht und die 271er empfohlen wird: https://pve.proxmox.com/wiki/Windows_VirtIO_Drivers

Nach weiterer Recherche haben wir folgenden RegKey gesetzt:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\netkvm\Parameters
"NdisPoll"=dword:00000000

Das stellt ein neues Verhalten von WS2025 auf das altbekannte stabile Verhalten von 2019/2022 um.
Seither hatten wir keine Probleme mehr gehabt.

Vielen Dank an alle.