Vor Kurzem hat mein Heimserver und VM-Host angefangen, zufällig die Netzwerkverbindung zu verlieren. Von außen sieht es so aus, als würde er noch laufen, aber ich kam auf keinem Weg mehr aus der Ferne an ihn heran. Der Ethernet-Adapter war laut Switch eingeschaltet, also musste das Problem irgendwo in der Software liegen.

Es wäre nicht das erste Mal, dass ein Treiber für eine hängende Netzwerkverbindung verantwortlich ist. In der Vergangenheit haben mich schon fehlerhafte WLAN-Treiber unter Linux und Windows geärgert.

Nachdem ich ein bisschen in den Systemlogs gegraben hatte, bin ich auf Folgendes gestoßen:

vmhost kernel: e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang:
vmhost kernel: TDH <0>
vmhost kernel: TDT <1>
vmhost kernel: next_to_use <1>
vmhost kernel: next_to_clean <0>
vmhost kernel: buffer_info[next_to_clean]:
vmhost kernel: time_stamp <10fbc2f81>
vmhost kernel: next_to_watch <0>
vmhost kernel: jiffies <10fbc3871>
vmhost kernel: next_to_watch.status <0>
vmhost kernel: MAC Status <40080083>
vmhost kernel: PHY Status <796d>
vmhost kernel: PHY 1000BASE-T Status <7800>
vmhost kernel: PHY Extended Status <3000>
vmhost kernel: PCI Status <10>
vmhost kernel: e1000e 0000:00:1f.6 eth0: Reset adapter unexpectedly
vmhost kernel: vmbr0: port 1(eth0) entered disabled state

Danach setzt er den Netzwerkadapter zurück und macht nach einer Weile wieder dasselbe, bis die Maschine komplett offline geht.

Bei der Suche nach Antworten im Netz bin ich auf diesen ServerFault-Thread gestoßen.

Ursache

Nach dem Lesen verschiedener Quellen und Bug-Reports scheint der beste Weg, das Problem zu reproduzieren, eine Situation mit hoher Bandbreite auf dem Gerät zu sein, also etwa das Streamen großer Datenmengen, die die Schnittstelle auslasten.

Bei mir passierte es meistens, wenn ich Medien vom lokalen Plex-Server auf ein Gerät streame. Wegen der Art, wie das Netzwerk aufgebaut ist, muss die Windows-VM, auf der die Plex-Instanz läuft, die Mediendatei von einer NFS-Freigabe auf einem separaten Gerät holen, in der VM transkodieren und sie dann an das Wiedergabegerät schicken.

Das summiert sich zu einer Menge Netzwerkverkehr, meist ~40–100 Mbit/s, je nach Wiedergabegerät und Qualität der Quelldatei.

Dasselbe Problem trat auch beim Streamen von Spielen per Steam Link auf unseren Apple TV auf. Die Verbindung ist kabelgebunden, aber es ist nicht ungewöhnlich, dass das Netzwerk abbricht. Ich vermute, dass es mit demselben Problem zusammenhängt, werde aber ein Auge darauf haben, ob es nach dem Fix in Zukunft noch passiert.

Möglicher Fix

Ein möglicher Fix scheint zu sein, GSO (Generic Segmentation Offload), TSO (TCP Segmentation Offload) und GRO (Generic Receive Offload) auf der Netzwerkschnittstelle zu deaktivieren*:

ethtool -K eth0 gso off gro off tso off

Ich habe das bei mir angewendet und warte nun ab, ob es das Problem auf lange Sicht wirklich löst.

Fußnoten

* Diese Optionen betreffen das Auslagern der Paketsegmentierung an den Netzwerk-Controller, um die CPU-Last auf der Maschine zu verringern. Mehr Details gibt es in diesem Wikipedia-Artikel.