Windows Server Network Adapter crash?
- Thread starter iKonst
- Start date
-
- Tags
- e1000 network adapter windows
Hab nur mal die Dell's überflogen.
Die scheinen Braodcomm NIC's onboard zu haben.
Evtl. liegt es daran.
Wir nutzen nur Supermicro Boards mit Intel NIC's und hatten damit noch keine derartigen Vorfälle.
Haben MS 2008, 2012 und 2019 im Einsatz und alles sehr stabil
Die scheinen Braodcomm NIC's onboard zu haben.
Evtl. liegt es daran.
Wir nutzen nur Supermicro Boards mit Intel NIC's und hatten damit noch keine derartigen Vorfälle.
Haben MS 2008, 2012 und 2019 im Einsatz und alles sehr stabil
Hallo zusammen,
sorry aber ich hatte das Thema etwas aus den Augen verloren.
Wir haben derzeit auch Seit über einem Jahr das Problem. Bei allen Systemen ab Proxmox 6.
Wir setzen ausschließlich Supermicro Server mit onboard Intel NIC's ein.
Folgende Boards haben diese Fehler :
X11DPi-NT1
X10DRC-T4+
Die Server die mit den selben Boards unter Proxmox 4.4 laufen haben keinerlei Probleme.
Viele Grüße
Gig
sorry aber ich hatte das Thema etwas aus den Augen verloren.
Wir haben derzeit auch Seit über einem Jahr das Problem. Bei allen Systemen ab Proxmox 6.
Wir setzen ausschließlich Supermicro Server mit onboard Intel NIC's ein.
Folgende Boards haben diese Fehler :
X11DPi-NT1
X10DRC-T4+
Die Server die mit den selben Boards unter Proxmox 4.4 laufen haben keinerlei Probleme.
Viele Grüße
Gig
Hallo,
heute ist es wieder einmal passiert. 6 Kunden haben sich gemeldet. Alle mit Windows Server 2019. Alle mit Intel Nics in Proxmox. Windows zeigt ein Ausrufezeichen bei der Netzwerkverbindung an. Ich kann über die Konsole zugreifen und den Netzwerkadapter stoppen und wieder starten in Windows und alles ist wieder normal. Oder ich kann Windows neustarten und es funktioniert wieder. Oder ich kann in Proxmox beim Netzwerkadapter die Verbindung trennen. Dann kommt aber die Meldung, dass die Config nicht gespeichert werden konnte, weil die Config bereits geöffnet ist?!?, anschliessend kommt die Meldung nicht mehr. Die Einstellungen wurden jedoch gespeichert. ich kann die Verbindung wieder aktivieren und es ist wieder alles normal. Leider wird die Fehlermeldung so kurz angezeigt, dass ich kein Screenshot machen konnte. Die Meldung bezüglich Config speichern in Proxmox tritt aber nicht bei allen Server auf.
Linux Server haben diese Netzwerk probleme nicht. Scheint so, als würde Windows die Verbindung nicht wieder neu aufbauen, wenn da mal was schief läuft. Ich vermute, dass Proxmox kurzfristig auf Netzwerkebene laggt, vielleicht bei einem Backup oder so und dann die Netzwerkschnittstelle ausser Takt gerät. In Windows fehlt dann sowas wie ein auto-reconnect. Das Problem tritt bei Linux sicher auch auf, aber Linux Server verbinden sich halt sofort wieder, weshalb es nicht auffällt. Kein Plan was ich noch tun kann.
Habe jedenfalls alle 6 Server auf Virtio umgestellt und die Treiber virtio-win-0.1.171 installiert. Ich kann aber aus Erfahrung sagen, dass das nichts helfen wird. Zumindest meint nun 1 Kunde, dass der Server massiv schneller läuft...
Ich hoffe hier hat bald jemand eine Lösung. Seit 1 Jahr funktioniert Proxmox nicht richtig. Würde mich freuen wenn sich da mal jemand meldet, der sich auskennt mit Proxmox.
heute ist es wieder einmal passiert. 6 Kunden haben sich gemeldet. Alle mit Windows Server 2019. Alle mit Intel Nics in Proxmox. Windows zeigt ein Ausrufezeichen bei der Netzwerkverbindung an. Ich kann über die Konsole zugreifen und den Netzwerkadapter stoppen und wieder starten in Windows und alles ist wieder normal. Oder ich kann Windows neustarten und es funktioniert wieder. Oder ich kann in Proxmox beim Netzwerkadapter die Verbindung trennen. Dann kommt aber die Meldung, dass die Config nicht gespeichert werden konnte, weil die Config bereits geöffnet ist?!?, anschliessend kommt die Meldung nicht mehr. Die Einstellungen wurden jedoch gespeichert. ich kann die Verbindung wieder aktivieren und es ist wieder alles normal. Leider wird die Fehlermeldung so kurz angezeigt, dass ich kein Screenshot machen konnte. Die Meldung bezüglich Config speichern in Proxmox tritt aber nicht bei allen Server auf.
Linux Server haben diese Netzwerk probleme nicht. Scheint so, als würde Windows die Verbindung nicht wieder neu aufbauen, wenn da mal was schief läuft. Ich vermute, dass Proxmox kurzfristig auf Netzwerkebene laggt, vielleicht bei einem Backup oder so und dann die Netzwerkschnittstelle ausser Takt gerät. In Windows fehlt dann sowas wie ein auto-reconnect. Das Problem tritt bei Linux sicher auch auf, aber Linux Server verbinden sich halt sofort wieder, weshalb es nicht auffällt. Kein Plan was ich noch tun kann.
Habe jedenfalls alle 6 Server auf Virtio umgestellt und die Treiber virtio-win-0.1.171 installiert. Ich kann aber aus Erfahrung sagen, dass das nichts helfen wird. Zumindest meint nun 1 Kunde, dass der Server massiv schneller läuft...
Ich hoffe hier hat bald jemand eine Lösung. Seit 1 Jahr funktioniert Proxmox nicht richtig. Würde mich freuen wenn sich da mal jemand meldet, der sich auskennt mit Proxmox.
Kaum ist eine Woche vergangen, passiert es schon wieder. Dieses Mal hatten wir Blackscreen auf den Windows Server. Komplett eingefroren. Das Problem können wir nun ziemlich genau auf Proxmox reduzieren. Wir haben verschiedene Hardware probiert. Ein parallel laufender Server mit Hyper-V hat keine Probleme mit dem gleichen Image. Scheint wohl einfach an Proxmox zu liegen...
Hat noch jemand einen guten Rat?
Hat noch jemand einen guten Rat?
Good afternoon. Recently, we started experiencing the same problems. Asus WS C422 DC motherboard. The HDD had broken sectors, we replaced all the problem disks. The server is rented in the data center. The data center engineers conducted a full hardware test and no problems were found. The network shutdown on Windows machines started on its own, without any software and hardware updates. We tried different virtual network cards. Different guest machines: Windows Server 2008-2019. In addition to problems with the network, which are solved by disabling / enabling the network adapter, sometimes network settings fly off: static ip addresses are registered everywhere, but automatically switches to receiving via dhcp. I really want to hear the comments of the technical specialists of ProxMox. The product itself is very pleasant and completely satisfied, I hope we will quickly find a solution to the problem.
Thanks.
proxmox-ve: 6.3-1 (running kernel: 5.4.103-1-pve)
pve-manager: 6.3-6 (running version: 6.3-6/2184247e)
pve-kernel-5.4: 6.3-7
pve-kernel-helper: 6.3-7
pve-kernel-5.3: 6.1-6
pve-kernel-5.4.103-1-pve: 5.4.103-1
pve-kernel-5.4.101-1-pve: 5.4.101-1
pve-kernel-5.4.78-2-pve: 5.4.78-2
pve-kernel-5.3.18-3-pve: 5.3.18-3
ceph-fuse: 12.2.11+dfsg1-2.1+b1
corosync: 3.1.0-pve1
criu: 3.11-3
glusterfs-client: 5.5-3
ifupdown: 0.8.35+pve1
libjs-extjs: 6.0.1-10
libknet1: 1.20-pve1
libproxmox-acme-perl: 1.0.7
libproxmox-backup-qemu0: 1.0.3-1
libpve-access-control: 6.1-3
libpve-apiclient-perl: 3.1-3
libpve-common-perl: 6.3-5
libpve-guest-common-perl: 3.1-5
libpve-http-server-perl: 3.1-1
libpve-storage-perl: 6.3-7
libqb0: 1.0.5-1
libspice-server1: 0.14.2-4~pve6+1
lvm2: 2.03.02-pve4
lxc-pve: 4.0.6-2
lxcfs: 4.0.6-pve1
novnc-pve: 1.1.0-1
proxmox-backup-client: 1.0.10-1
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.4-6
pve-cluster: 6.2-1
pve-container: 3.3-4
pve-docs: 6.3-1
pve-edk2-firmware: 2.20200531-1
pve-firewall: 4.1-3
pve-firmware: 3.2-2
pve-ha-manager: 3.1-1
pve-i18n: 2.2-2
pve-qemu-kvm: 5.2.0-3
pve-xtermjs: 4.7.0-3
qemu-server: 6.3-8
smartmontools: 7.2-pve2
spiceterm: 3.1-1
vncterm: 1.6-2
zfsutils-linux: 2.0.3-pve2
Thanks.
proxmox-ve: 6.3-1 (running kernel: 5.4.103-1-pve)
pve-manager: 6.3-6 (running version: 6.3-6/2184247e)
pve-kernel-5.4: 6.3-7
pve-kernel-helper: 6.3-7
pve-kernel-5.3: 6.1-6
pve-kernel-5.4.103-1-pve: 5.4.103-1
pve-kernel-5.4.101-1-pve: 5.4.101-1
pve-kernel-5.4.78-2-pve: 5.4.78-2
pve-kernel-5.3.18-3-pve: 5.3.18-3
ceph-fuse: 12.2.11+dfsg1-2.1+b1
corosync: 3.1.0-pve1
criu: 3.11-3
glusterfs-client: 5.5-3
ifupdown: 0.8.35+pve1
libjs-extjs: 6.0.1-10
libknet1: 1.20-pve1
libproxmox-acme-perl: 1.0.7
libproxmox-backup-qemu0: 1.0.3-1
libpve-access-control: 6.1-3
libpve-apiclient-perl: 3.1-3
libpve-common-perl: 6.3-5
libpve-guest-common-perl: 3.1-5
libpve-http-server-perl: 3.1-1
libpve-storage-perl: 6.3-7
libqb0: 1.0.5-1
libspice-server1: 0.14.2-4~pve6+1
lvm2: 2.03.02-pve4
lxc-pve: 4.0.6-2
lxcfs: 4.0.6-pve1
novnc-pve: 1.1.0-1
proxmox-backup-client: 1.0.10-1
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.4-6
pve-cluster: 6.2-1
pve-container: 3.3-4
pve-docs: 6.3-1
pve-edk2-firmware: 2.20200531-1
pve-firewall: 4.1-3
pve-firmware: 3.2-2
pve-ha-manager: 3.1-1
pve-i18n: 2.2-2
pve-qemu-kvm: 5.2.0-3
pve-xtermjs: 4.7.0-3
qemu-server: 6.3-8
smartmontools: 7.2-pve2
spiceterm: 3.1-1
vncterm: 1.6-2
zfsutils-linux: 2.0.3-pve2
What was done during this time.
1. Updated virtio drivers on all Windows machines - network card settings are no longer automatically reset.
2. Installed qemu guest agent on all Windows machines.
3. Updated Proxmox and all packages to the latest versions.
Everything works correctly until the backup of virtual machines is started, which is configured according to the schedule, weekly, on the night from Friday to Saturday. The backup runs without errors, but today we noticed:
1. 2 of the 6 windows machines are not available even through noVNC
2. 5 out of 6 linux machines (more precisely, Mikrotik CHR) are not accessible even through the console.
3. While we were restoring the operation of the problem machines by stopping/starting, other machines that were working earlier became unavailable.
As a result, we rebooted the hypervisor and after that everything worked. It is logical to conclude that problems arise during the backup process. We can't find a solution on our own. SOS
1. Updated virtio drivers on all Windows machines - network card settings are no longer automatically reset.
2. Installed qemu guest agent on all Windows machines.
3. Updated Proxmox and all packages to the latest versions.
Everything works correctly until the backup of virtual machines is started, which is configured according to the schedule, weekly, on the night from Friday to Saturday. The backup runs without errors, but today we noticed:
1. 2 of the 6 windows machines are not available even through noVNC
Code:
VM 114 qmp command 'change' failed - unable to connect to VM 114 qmp socket - timeout after 600 retrie
TASK ERROR: Failed to run vncproxy3. While we were restoring the operation of the problem machines by stopping/starting, other machines that were working earlier became unavailable.
As a result, we rebooted the hypervisor and after that everything worked. It is logical to conclude that problems arise during the backup process. We can't find a solution on our own. SOS
Code:
# pveversion -v
proxmox-ve: 6.3-1 (running kernel: 5.4.103-1-pve)
pve-manager: 6.3-6 (running version: 6.3-6/2184247e)
pve-kernel-5.4: 6.3-7
pve-kernel-helper: 6.3-7
pve-kernel-5.3: 6.1-6
pve-kernel-5.4.103-1-pve: 5.4.103-1
pve-kernel-5.4.101-1-pve: 5.4.101-1
pve-kernel-5.4.78-2-pve: 5.4.78-2
pve-kernel-5.3.18-3-pve: 5.3.18-3
ceph-fuse: 12.2.11+dfsg1-2.1+b1
corosync: 3.1.0-pve1
criu: 3.11-3
glusterfs-client: 5.5-3
ifupdown: 0.8.35+pve1
libjs-extjs: 6.0.1-10
libknet1: 1.20-pve1
libproxmox-acme-perl: 1.0.7
libproxmox-backup-qemu0: 1.0.3-1
libpve-access-control: 6.1-3
libpve-apiclient-perl: 3.1-3
libpve-common-perl: 6.3-5
libpve-guest-common-perl: 3.1-5
libpve-http-server-perl: 3.1-1
libpve-storage-perl: 6.3-7
libqb0: 1.0.5-1
libspice-server1: 0.14.2-4~pve6+1
lvm2: 2.03.02-pve4
lxc-pve: 4.0.6-2
lxcfs: 4.0.6-pve1
novnc-pve: 1.1.0-1
proxmox-backup-client: 1.0.10-1
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.4-6
pve-cluster: 6.2-1
pve-container: 3.3-4
pve-docs: 6.3-1
pve-edk2-firmware: 2.20200531-1
pve-firewall: 4.1-3
pve-firmware: 3.2-2
pve-ha-manager: 3.1-1
pve-i18n: 2.2-2
pve-qemu-kvm: 5.2.0-3
pve-xtermjs: 4.7.0-3
qemu-server: 6.3-8
smartmontools: 7.2-pve2
spiceterm: 3.1-1
vncterm: 1.6-2
zfsutils-linux: 2.0.3-pve2