Proxmox Probleme Windows Gäste im Bereich Netzwerk

Jul 4, 2025
4
0
1
Hallo zusammen,

ich habe einen Proxmoxcluster 2 Node. Beide Nodes sind frisch installiert. Ich habe von VMWARE Gäste migriert. Grunsätzlich seint alles ganz gut zu laufen.
Aber ich habe immer wieder mal leichte "hänger" in unserer ERP Software. Ich vermute hier irgendwie das Netzwerk.
Ich mache tests mit iperf3 im Bereich UDP ( iperf3 -c hostname -u -b 100m -R- t20 und bekomme hier Paketverluste. Habe nun einen Client mal dierekt an dei Switsch gehangen an dem die Nodes hängen um Büro und Verkabelung möglichst weit auszuschließen. Zusätzlich habe ich noch 2 VM´s Server 2016 angelegt und diese Frisch installiert. Genutzt wird hier die VIRTIO virtio-win-0.1.266. Bin schon von der aktuellen eine Version rückwärts gegangen.

Ich habe nun schon einiges verucht komme aber nicht wirklich weiter und brauche mal euere Hilfe. Kann es ggf mit der Kernelversion zusammenhängen


Hier mal ein paar Deteils zu den Hosts:

32 x AMD EPYC 9174F 16-Core Processor (1 Socket)
Kernel Version Linux 6.8.12-11-pve (2025-05-22T09:39Z

Daten Pool
NAME STATE READ WRITE CKSUM
pool-nvme ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
nvme-KIOXIA_KCD8XRUG7T68_25X0A1RPTM9J ONLINE 0 0 0
nvme-KIOXIA_KCD8XRUG7T68_25P0A00KTM9J ONLINE 0 0 0
mirror-1 ONLINE 0 0 0
nvme-KIOXIA_KCD8XRUG7T68_25X0A2NRTM9J ONLINE 0 0 0
nvme-KIOXIA_KCD8XRUG7T68_25P0A00JTM9J ONLINE 0 0 0
mirror-2 ONLINE 0 0 0
nvme-KIOXIA_KCD8XRUG7T68_25P0A00MTM9J ONLINE 0 0 0
nvme-KIOXIA_KCD8XRUG7T68_25P0A0G1TM9J ONLINE 0 0 0

rpool
mirror-0 ONLINE 0 0 0
nvme-eui.01000000000000008ce38ee308917f27-part3 ONLINE 0 0 0
nvme-eui.01000000000000008ce38ee308917fa9-part3 ONLINE 0 0 0



 
Hi Markus,

so ganz entfernt erinnert mich Deine Beschreibung an die Probleme, die wir zu Beginn unserer aktuellen PVE-Hardwaregeneration hatten. Wir haben an Windows-VMs, auf denen Anwendungen gestartet wurden, die auf der Dateifreigabe einer anderen VM liegen (so ist das halt mit unserem ERP...), ungewöhnlich viele Paketverluste und Retransmissions beobachtet.

Das Drehen an zwei Ecken hat unser Problem gelöst. (Wahrscheinlich war nur eine der beiden Ecken die Lösung, aber ich erinnere mich nicht mehr, welche)

1. An allen beteiligten NICs, bzw. den daraus konfigurierten Bonds haben wir das generic-receive-offload deaktiviert, zum Beispiel

Bash:
auto enp189s0f0np0
iface enp189s0f0np0 inet static
        address <ip address>
        mtu 9000
        pre-up /sbin/ethtool --offload enp189s0f0np0 generic-receive-offload off

oder für ein Bond:
Bash:
auto bond0
iface bond0 inet static
        address <ip address>
        bond-slaves enp42s0f0np0 enp61s0f0np0
        bond-miimon 100
        bond-mode balance-rr
        mtu 9000
        pre-up /sbin/ethtool --offload enp42s0f0np0 generic-receive-offload off
        pre-up /sbin/ethtool --offload enp61s0f0np0 generic-receive-offload off

2. Der Machine Type der VMs steht bei uns aus historischen Gründen auf Default (i440fx). Und hier hat der Sprung auf Version 9.x die Situation verbessert. Aktuell haben unsere Windows-VMs hier durchgängig 9.0. Ich habe aus der Situation damals mitgenommen, auch hier regelmäßige "Updates" auf die jeweils aktuelle Version einzuplanen.

Liebe Grüße
Stephan