3
Detected Tx Unit Hang
Hallo zusammen,
ich betreibe einen ESXi 6.0.0 (Build 2615704) mit einer VM für die UTM (v9.310-11) und zwei Debian 7.8 VMs, auf der einen läuft ein Apache und auf der anderen VM läuft der MySQL Server.
Auf dem Server sind rund 10 Webseiten die alle kaum Ressourcen benötigen.
Mein externes Monitoring meldete mir gestern gegen 06:15 Uhr das die beiden Server nicht mehr auf Ping / HTTP Anfragen reagierten.
Die UTM selbst ist zu dem Zeitpunkt auch gestartet gewesen
hat aber nichts mehr durchgelassen, ein Restart der VM behebte das Problem soweit.
Daraufhin habe ich mir die Logdateien der UTM angeschaut und bin in der
kernel.log schliesslich fündig geworden:
Im Hostsystem ist übrigens eine Intel 82574L verbaut.
Über die Google Suche habe ich bereits gelesen dass man GRO, GSO und TSO deaktivieren soll als Workaround allerdings soll das zu Performanceverlust führen. Habt ihr vielleicht noch eine andere Idee?
Viele Grüße
DasBill
ich betreibe einen ESXi 6.0.0 (Build 2615704) mit einer VM für die UTM (v9.310-11) und zwei Debian 7.8 VMs, auf der einen läuft ein Apache und auf der anderen VM läuft der MySQL Server.
Auf dem Server sind rund 10 Webseiten die alle kaum Ressourcen benötigen.
Mein externes Monitoring meldete mir gestern gegen 06:15 Uhr das die beiden Server nicht mehr auf Ping / HTTP Anfragen reagierten.
Die UTM selbst ist zu dem Zeitpunkt auch gestartet gewesen
hat aber nichts mehr durchgelassen, ein Restart der VM behebte das Problem soweit.
Daraufhin habe ich mir die Logdateien der UTM angeschaut und bin in der
kernel.log schliesslich fündig geworden:
kernel.log
2015:04:27-06:15:42 utm kernel: [1115617.596637] e1000 0000:02:00.0 eth0: Detected Tx Unit Hang
2015:04:27-06:15:42 utm kernel: [1115617.596637] Tx Queue <0>
2015:04:27-06:15:42 utm kernel: [1115617.596637] TDH <bf>
2015:04:27-06:15:42 utm kernel: [1115617.596637] TDT <c0>
2015:04:27-06:15:42 utm kernel: [1115617.596637] next_to_use <c0>
2015:04:27-06:15:42 utm kernel: [1115617.596637] next_to_clean <bf>
2015:04:27-06:15:42 utm kernel: [1115617.596637] buffer_info[next_to_clean]
2015:04:27-06:15:42 utm kernel: [1115617.596637] time_stamp <11126b01b>
2015:04:27-06:15:42 utm kernel: [1115617.596637] next_to_watch <bf>
2015:04:27-06:15:42 utm kernel: [1115617.596637] jiffies <11126b287>
2015:04:27-06:15:42 utm kernel: [1115617.596637] next_to_watch.status <0>
2015:04:27-06:15:45 utm kernel: [1115620.431242] e1000 0000:02:00.0 eth0: Detected Tx Unit Hang
2015:04:27-06:15:45 utm kernel: [1115620.431242] Tx Queue <0>
2015:04:27-06:15:45 utm kernel: [1115620.431242] TDH <bf>
2015:04:27-06:15:45 utm kernel: [1115620.431242] TDT <c0>
2015:04:27-06:15:45 utm kernel: [1115620.431242] next_to_use <c0>
2015:04:27-06:15:45 utm kernel: [1115620.431242] next_to_clean <bf>
2015:04:27-06:15:45 utm kernel: [1115620.431242] buffer_info[next_to_clean]
2015:04:27-06:15:45 utm kernel: [1115620.431242] time_stamp <11126b01b>
2015:04:27-06:15:45 utm kernel: [1115620.431242] next_to_watch <bf>
2015:04:27-06:15:45 utm kernel: [1115620.431242] jiffies <11126b54c>
2015:04:27-06:15:45 utm kernel: [1115620.431242] next_to_watch.status <0>
2015:04:27-06:15:45 utm kernel: [1115620.899151] e1000 0000:02:00.0 eth0: Detected Tx Unit Hang
2015:04:27-06:15:45 utm kernel: [1115620.899151] Tx Queue <0>
2015:04:27-06:15:45 utm kernel: [1115620.899151] TDH <bf>
2015:04:27-06:15:45 utm kernel: [1115620.899151] TDT <c0>
2015:04:27-06:15:45 utm kernel: [1115620.899151] next_to_use <c0>
2015:04:27-06:15:45 utm kernel: [1115620.899151] next_to_clean <bf>
2015:04:27-06:15:45 utm kernel: [1115620.899151] buffer_info[next_to_clean]
2015:04:27-06:15:45 utm kernel: [1115620.899151] time_stamp <11126b01b>
2015:04:27-06:15:45 utm kernel: [1115620.899151] next_to_watch <bf>
2015:04:27-06:15:45 utm kernel: [1115620.899151] jiffies <11126b5c1>
2015:04:27-06:15:45 utm kernel: [1115620.899151] next_to_watch.status <0>
2015:04:27-06:15:47 utm kernel: [1115622.429701] e1000 0000:02:00.0 eth0: Reset adapterethtool -k eth0
Features for eth0
rx-checksumming: off
tx-checksumming: on
tx-checksum:-ipv4: off [fixed]
tx-checksum-ip-generic: on
tx-checksum-ipv6: off [fixed]
tx-checksum-fcoe-crc: off [fixed]
tx-checksum:-sctp: off [fixed]
scatter-gather: on
tx-scatter-gather: on
tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: off [fixed]
tx-tcp6-segmentation: off [fixed]
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: on
generic-recieve-offload: on
large-recieve-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on [fixed]
ntuple-filters: off [fixed]
receive-hashing: off [fixed]
highdma: off [fixed]
rx-vlan-filter: on [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-mpls-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off
rx-all: off
tx-vlan-stag-hw-insert: off [fixed]
tx-vlan-stag-hw-parse: off [fixed]
tx-vlan-stag-filter: off [fixed]Im Hostsystem ist übrigens eine Intel 82574L verbaut.
Über die Google Suche habe ich bereits gelesen dass man GRO, GSO und TSO deaktivieren soll als Workaround allerdings soll das zu Performanceverlust führen. Habt ihr vielleicht noch eine andere Idee?
Viele Grüße
DasBill
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 270516
Url: https://administrator.de/contentid/270516
Ausgedruckt am: 22.11.2024 um 13:11 Uhr
3 Kommentare
Neuester Kommentar
Moin,
altbekannter Kandidat: Netzwerkkartentyp: wenn der auf e1000e gestellt ist, durch vmxnet3 in der .vmx ersetzen, das geht aber nur in Verbindung mit den VMware-Tools, ob die in der UTM installiert sind, wäre vorher zu prüfen.
Wenn die Karten keine neuen MACs bekommen (direkt in der .vmx austauschen ohne den viClient/viWebClient) sollten sich die Devices nicht verschieben.
Vorher aber ein vernünftiges Backup der ganzen VM machen...
HG
Mark
altbekannter Kandidat: Netzwerkkartentyp: wenn der auf e1000e gestellt ist, durch vmxnet3 in der .vmx ersetzen, das geht aber nur in Verbindung mit den VMware-Tools, ob die in der UTM installiert sind, wäre vorher zu prüfen.
Wenn die Karten keine neuen MACs bekommen (direkt in der .vmx austauschen ohne den viClient/viWebClient) sollten sich die Devices nicht verschieben.
Vorher aber ein vernünftiges Backup der ganzen VM machen...
HG
Mark
Hi broecker,
meine VMs laufen alle mit E1000 Karten und Open-VM-Tools bisher hatte ich damit auch diesbezüglich keine Probleme gehabt zumindest bis vor wenigen Tagen.
Interessant wäre es auch einen spürbaren Unterschied von der Netzperformance her gibt.
Hast du das mal getestet?
Viele Grüße
DasBill
meine VMs laufen alle mit E1000 Karten und Open-VM-Tools bisher hatte ich damit auch diesbezüglich keine Probleme gehabt zumindest bis vor wenigen Tagen.
Interessant wäre es auch einen spürbaren Unterschied von der Netzperformance her gibt.
Hast du das mal getestet?
Viele Grüße
DasBill
getestet nicht, aber VMware empfiehlt - und es ist aufgrund der Integration der VMware-Tools auch plausibel, für beste Performance immer die vmxnet(3). Dann müssen ja nicht künstlich kleine RAM-Zwischenspeicher zur Kompatibilität mit Hardware-Treibern simuliert werden.
Viele Threads gibt's hier im Forum zu W2012(R2) und sporadischen Hängern bei e1000(e).
HG
Mark
Viele Threads gibt's hier im Forum zu W2012(R2) und sporadischen Hängern bei e1000(e).
HG
Mark
1
