Windows Server Network Adapter crash?

[iKonst]

Hey,
ich habe auf zwei meiner Windows Maschinen das Problem das alle paar Tage der Network Adapter crasht oder so. Der Server wird alle paar Tage vom Internet getrennt und nur ein Server Restart oder Netzwerk Adapter Disable/Enable können das beheben. Weiß jemand woran das liegen könnte und wie das zu beheben ist?

Einstellungen:
Intel E1000
vServer IP (OVH)
Gateway: 255.255.255.255
Default Gateway: Main Maschine IP
DNS Server 8.8.8.8/4.4.4.4

 

[fireon]

Was für eine Windowsversion verwendest du denn? Der Intel E1000 ist normal nur ein Notnagel. Verwenden hier immer den Virtio. Damit hatten wir noch nie Probleme.

 

[iKonst]

Windows Server 2012 R2. Wie genau kann man VirtIO installieren?

 

[fireon]

https://pve.proxmox.com/wiki/Windows_VirtIO_Drivers

 

[iKonst]

Hat nichts gebracht, crasht immernoch...

 

[fireon]

Poste doch mal deine VM-Config.

qm config <id>

Und noch deine Proxmoxversion:

pveversion -v

 

[sumsum]

Wie sieht das Ereignis Protokoll der Windows Vm zum Zeitpunkt des Crash aus ?

 

[iKonst]

Ich weiß nicht um wie viel Uhr es genau crasht. Sehe in der Ereignisanzeige aber auch nichts auffälliges. Heute ist der Server wieder, so wie mittlerweile jeden Tag, gecrasht. Um 2 Uhr habe ich eine Warnung bekommen in der steht "Name resolution for the name sqm.telemetry.microsoft.com timed out after none of the configured DNS servers responded.".

VM-Config: http://i.epvpimg.com/30OXcab.png
Version: http://i.epvpimg.com/q5ftfab.png

 

[sumsum]

und nach der "Name Resolution..." Meldung kam etwas ähnliches wie :

"Das Schließen einer UDP-Socket mit der lokalen Portnummer "56327" im Prozess "888" dauert länger als erwartet. Die lokale Portnummer ist möglicherweise erst nach Abschluss dieses Vorgangs wieder verfügbar. Der Grund hierfür liegt in der Regel im fehlerhaften Verhalten von Netzwerktreibern. Stellen Sie sicher, dass die neuesten Updates für Windows und für die Netzwerksoftware von Drittanbietern einschließlich NIC-Treibern, Firewalls oder anderer Sicherheitsprodukte installiert sind. "

Quelle AFD Error ID 16002 ?

Wir haben hier zwei Server die unregelmässig die Netzwerkverbindung verlieren. ca all 13h - 24h (manchmal aber auch schon nach 2-3h) immer kurz nach dem diese Meldungen in der Ereignisanzeige erscheinen. Der Unterschied zu anderen stabilen VM's - diese beiden VM's haben die aktuellsten Virtio Drivers, Ballooning enabled und die aktuellsten QEMU Agents installiert.

 

[iKonst]

Nein, nach dieser Meldung kommt kein anderer Fehler/Warnung mehr.
Was genau ist Ballooning und wie kann ich die QEMU Agents updaten?

__

Habe gerade gesehen das der Server erst nach 4:10 abgestürzt ist und da ist in der Ereignisanzeige bis auf die normalen Meldungen nichts zu sehen.

 

[mcparlandj]

I'm having this exact same issue on a few hosts and guests. Windows just seems to drop it's network connection until i reboot the guest.

 

[Matthi Chevy]

Any update on this issue?
We are experiencing the simelair issues on some VM's where almost al network traffic is dropped. Whenever we disable the adapter in Proxmox and reenable the network adapter or reboot the server all is working wel again.

Hope to hear from somebody.

Kindest regards

 

[Ronny]

Hi,

we also have this problem. some changes we made had no effect:
virtio-drivers installed from ISO 0.1.149 (hdd, network, baloon, qemu-guest-agent)

at this moment every day our one Win2012R2 VM had no Network and must Hard-Stopped.
we also have a few other Win-Server and Win10/Win7 VMs with no Problem.

any updates about this issue?


5-node cluster with CEPH luminous

pveversion -v
proxmox-ve: 5.4-1 (running kernel: 4.15.18-15-pve)
pve-manager: 5.4-6 (running version: 5.4-6/aa7856c5)
pve-kernel-4.15: 5.4-3
pve-kernel-4.15.18-15-pve: 4.15.18-40
pve-kernel-4.15.18-14-pve: 4.15.18-39
pve-kernel-4.15.18-13-pve: 4.15.18-37
pve-kernel-4.15.18-12-pve: 4.15.18-36
ceph: 12.2.12-pve1
corosync: 2.4.4-pve1
criu: 2.11.1-1~bpo90
glusterfs-client: 3.8.8-1
ksm-control-daemon: 1.2-2
libjs-extjs: 6.0.1-2
libpve-access-control: 5.1-10
libpve-apiclient-perl: 2.0-5
libpve-common-perl: 5.0-52
libpve-guest-common-perl: 2.0-20
libpve-http-server-perl: 2.0-13
libpve-storage-perl: 5.0-43
libqb0: 1.0.3-1~bpo9
lvm2: 2.02.168-pve6
lxc-pve: 3.1.0-3
lxcfs: 3.0.3-pve1
novnc-pve: 1.0.0-3
proxmox-widget-toolkit: 1.0-28
pve-cluster: 5.0-37
pve-container: 2.0-39
pve-docs: 5.4-2
pve-edk2-firmware: 1.20190312-1
pve-firewall: 3.0-22
pve-firmware: 2.0-6
pve-ha-manager: 2.0-9
pve-i18n: 1.1-4
pve-libspice-server1: 0.14.1-2
pve-qemu-kvm: 3.0.1-2
pve-xtermjs: 3.12.0-1
qemu-server: 5.0-52
smartmontools: 6.5+svn4324-1
spiceterm: 3.0-5
vncterm: 1.5-3
zfsutils-linux: 0.7.13-pve1~bpo2

 

[Ronny]

hello,

habe anyone an idea about this?

our next step is to reinstall the windows machine and application with many time amount.


regards
Ronny

 

[chrigiboy]

Hallo,
auch ich habe genau das gleiche Problem. Linux Systeme haben keine Probleme. Nur die Windows Server sind von Zeit zu zeit offline. Hauptsächlich zwischen 01 und 06 Uhr am Morgen. Es handelt sich um Windows Server 2019. Ich habe auch schon die Netzwerkkarten durchprobiert: E1000, Virtio ohne Erfolg. Die Systemunterbrechung der Windowssysteme hat während dem Ausfall ca. 50 bis 80% CPU Auslastung, der Server ist über Netzwerk nicht erreichbar, über Console läuft das System so gut wie gar nicht und hängt. Dann einmal kurz Netzwerk auf disconnect in Proxmox, dann kommt die Meldung dass die Config kürzlich geändert wurde (Checksum Error oder so was ähnliches), aber die Änderung übernimmt es trotzdem, Netzwerk wieder verbinden und der Server läuft wieder 1A während Tage, Wochen oder Monate. Es ist auch nicht immer der gleiche Server. Als Hosttreiber haben wir auch alles schon durchprobiert, zuletzt virtio-win-0-1-171 haben wir die besten Erfahrungen gemacht. Da aber das Speichern der Config genau zu dem Zeitpunkt, wenn der Server einen Unterbruch hat, einen Fehler meldet, gehe ich davon aus, dass es ein Bug von Proxmox ist.
Hat Ihr jemand einen guten Rat? Wir verwenden Proxmox 6.1 alles Up-To-Date.

 

[Ronny]

we had the same problems with server 2012R2 and some old pfsenses.
- on pfsenses only move to virtio was needed
- on server 2012R2:
it is not enough to only re-install the driver and/or move to virtio-card
our solution was to remove all network-drivers and network-cards (via proxmox-gui) from this windows machine, reboot and apply new installation.
we use the latest virtio-drivers (0-1-171)

we use Proxmox 5.4.13 with latest Updates.

hope i can help you

 

[fireon]

Looks like depending von hardware firmware reversion. We have here 3 HP workstations with Proxmox. Same Hardware. One the Machine were running fine with the Windows10 VM. Everythings virtio. Driver virtio-win-0.1.172.iso. 2 of them we had problems with the network, high pingtimes, and completely los the network connections. We solved this to downgrade the drivers to old stable virtio-win-0.1.141.

The same VM with the virtio-win-0.1.172.iso runs on other hosts stable. Really strange.

 

[chrigiboy]

OK, currently nothing helps.
1. I have removed all network devices, and added a new one. After 4 weeks it happens again
2. I have removed the 0.1.171 driver and replaced with 0.1.141 (win2k16) even when we use Win2k19.

What can we do next? We never had such issue with Hyper-V or VMWare with the SAME Host-Machine. The issue happens only on Proxmox!

 

[Gigulon]

Wir haben ebenfalls das Problem wie beschrieben.

pve-manager/6.2-10/a20769ed (running kernel: 5.4.44-2-pve)

Netzwerkverbindung bricht immer wieder sporadisch ab und ist erst nach Neustart des Guests oder deaktivieren und aktivieren des Netzwerkadapters in der VM wieder funktionstüchtig.

Gibt es hierzu irgendwelche neuen Erkenntnisse ?


Grüße
Gig

 

[chrigiboy]

Hallo Gig.
Das Problem besteht seit über 1 Jahr. Bis jetzt ist aber nichts passiert.
Es wurde sogar schlimmer. Sporadisch frieren die Windows Server ein. Das ist daran zu erkennen, dass in Proxmox nicht einmal die Bildschirm Ausgabe funktioniert. Das Bild bleibt einfach schwarz. Die Netzwerkkarte zu reseten hilft da nicht... schade eigentlich...