Das Forum wurde aktualisiert. Wurde höchste Zeit. Wenn etwas nicht funktioniert, bitte gerne hier jederzeit melden.

Detected Hardware Unit Hang

Alles zum Thema vSphere 6, ESXi 6.0 und vCenter Server.

Moderatoren: Dayworker, continuum, Tschoergez, irix

Member
Beiträge: 30
Registriert: 24.12.2014, 15:40

Detected Hardware Unit Hang

Beitragvon someone » 30.08.2015, 12:17

Hallo Zusammen,

nachdem ich vor einiger Zeit hier schonmal meine Probleme mit einer RS214 und iSCSI kundgetan hab, bin ich auf NFS gewechselt.
Das Problem damals war, dass unter Last der ganze Stack abgebrochen war und die iSCSI Verbindung samt Netzwerkkarte auf dem ESXi weg war.

vmnic0 0000:00:19.0 e1000e Up 1000Mbps Full XX:XX:XX:XX:XX:XX 1500 Intel Corporation Ethernet Connection I218-V
vmnic1 0000:02:00.0 e1000e Up 1000Mbps Full XX:XX:XX:XX:XX:XX 9000 Intel Corporation 82574L Gigabit Network Connection

vmnic0 ist meine NIC, die in das LAN geht.
vmnic1 ist mit einem Kabel direkt mit der RS214 verbunden. Hier liegt mein Storage via NFS bereit.

Nun kam es bei sehr hoher Last (Backup aller VMs von einer VM aus) zum Absturz der vmnic1:

Code: Alles auswählen

015-08-30T10:07:09.733Z cpu0:33084)<6>vmnic1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
2015-08-30T10:07:10.279Z cpu1:32814)NetPort: 1780: disabled port 0x3000002
2015-08-30T10:07:10.279Z cpu1:32814)Uplink: 7270: enabled port 0x3000002 with mac 00:03:1d:08:XX:XX
2015-08-30T10:07:11.736Z cpu1:33082)<6>e1000e 0000:02:00.0: vmnic1: Hardware hanged on TSO context. Reset it.
2015-08-30T10:07:11.736Z cpu1:33082)<3>e1000e 0000:02:00.0: vmnic1: Detected Hardware Unit Hang:
  TDH                  <0>
  TDT                  <3>
  next_to_use          <3>
  next_to_clean        <0>
buffer_info[next_to_clean]:
  time_stamp        $
2015-08-30T10:07:28.860Z cpu0:33080)<4>0000:02:00.0: unable to set PM QoS requirement
2015-08-30T10:07:46.075Z cpu2:33085)<4>0000:02:00.0: unable to set PM QoS requirement
2015-08-30T10:07:49.223Z cpu2:33085)<6>vmnic1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
2015-08-30T10:07:50.278Z cpu1:32814)NetPort: 1780: disabled port 0x3000002
2015-08-30T10:07:50.278Z cpu1:32814)Uplink: 7270: enabled port 0x3000002 with mac 00:03:1d:08:XX:XX
2015-08-30T10:07:51.224Z cpu0:33084)<6>e1000e 0000:02:00.0: vmnic1: Hardware hanged on TSO context. Reset it.
2015-08-30T10:07:51.225Z cpu0:33084)<3>e1000e 0000:02:00.0: vmnic1: Detected Hardware Unit Hang:
  TDH                  <0>
  TDT                  <4>
  next_to_use          <4>
  next_to_clean        <0>


Hat da jemand eine Idee?
Ist es eventuell doch ein Hardware-Problem? Oder macht es Probleme, dass ich ESXi und RS214 direkt mit einem Kabel verbunden habe? Settings für den vSwitch sind standard. Lediglich die MTU habe ich überall auf 9000 gesetzt.

Experte
Beiträge: 1003
Registriert: 30.10.2004, 12:41

Beitragvon mbreidenbach » 30.08.2015, 12:27

Auch wenn ich nur rate - schon mal versucht TCP Segmentation Offload (TSO) abzuschalten ?

Experte
Beiträge: 1858
Registriert: 23.02.2012, 12:26

Beitragvon ~thc » 30.08.2015, 12:46

Ich habe auch mehrere DS214 mit ESXi in mehreren Kombos im Einsatz und bin diesem Phänomen noch nicht begegnet. Ein Server entspricht bis auf die Version (5.0) fast deinem Setup (gleiche Netzwerkkarte, gleiches Szenario). Da ein Offload-Feature (TSO) hängt, kann eventuell wirklich die Hardware Schuld sein.

Das TSO abzuschalten, sollte dann auch wirklich helfen.

Member
Beiträge: 30
Registriert: 24.12.2014, 15:40

Beitragvon someone » 30.08.2015, 13:27

...und ich dachte ich bin der einzige, der bei dem Wetter vor der Kiste hängt ;-)
Danke für das schnelle Feedback!

Laut Prüfung gibt es zumindest keinen Fehler bezüglich TSO. Ich habe es dennoch versucht abzuschalten.

Code: Alles auswählen

ethtool --show-offload vmnic1

Offload parameters for vmnic1:
Cannot get device udp large send offload settings: Function not implemented
Cannot get device generic segmentation offload settings: Function not implemented
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: on
udp fragmentation offload: off
generic segmentation offload: off


Allerdings brachte mich das Ausschalten zu einer Fehlermeldung:

Code: Alles auswählen

ethtool -K vmnic1 tso off
Cannot set device tcp segmentation offload settings: Function not implemented


Edit:
Habe es nun wie folgt gesetzt:

Code: Alles auswählen

esxcli system settings advanced set -o /Net/UseHwTSO -i 0

Allerdings sagt ethtool noch immer, dass es aktiviert ist. Schauen wir mal, was passiert.

Edit2:
Noch ein weiterer Gedanke: Kann so etwas auch durch ein Hitzeproblem entstehen? Ich habe den Intel NUC i5 in einem Gehäuse ohne Lüfter (Akasa Tesla H) verbaut. Die Netzerkkarte hat keinerlei Kühlung.

Experte
Beiträge: 1292
Registriert: 30.03.2009, 17:13

Beitragvon UrsDerBär » 30.08.2015, 14:25

Du bis nicht alein *g*

Wie sagt man so schön, wer unter der Woche zu langsam arbeitet muss halt am Week-End auch noch ran *hust*

... bin auch noch drann, die Motivation hält sich gerade arg in Grenzen



Ah und noch was zum Thema: Überhitzung kann schon seltsame Dinge hervorrufen. So richtig nen Schema gibts da dann nicht. Bis es die Hardware (kurzfristig) juckt, brauchts aber in der Regel schon einiges an Temp. Längerfristige Überhitzung ist aber sicher nicht gut. Problematisch ist hier vor allem das austrocknen der Electrolyte in den Kondensatoren. Vor allem in Netzteilen und sonstigen Spannungsglättern Davon ist heutzutage leider eh immer weniger Reserve vorhanden. Das gibt dann die verschiedensten Fehlerbilder.

Ob es auch deines sein kann, keine Ahnung. ;)

Member
Beiträge: 30
Registriert: 24.12.2014, 15:40

Beitragvon someone » 30.08.2015, 15:27

Der Tipp mit dem TSO könnte etwas gebracht haben.
Habe den Stress-Test (das Backup) nun 2x durchgeführt und es kam zu keinem Fehler.

Allerdings lief es ja schon ein paar mal vorher durch, ohne Abbruch.

Der Fehler könnte also einmalig gewesen sein?
Mir kribbelt es ja jetzt in den Fingern mein Setup von damals aufzusetzen, bei welchem ich die argen Probleme mit iSCSI habe. Möglicherweise hilft auch hier das TSO Deaktivieren.

Einen Performance-"Einbruch" ohne TSO konnte ich auch nicht feststellen.

Member
Beiträge: 30
Registriert: 24.12.2014, 15:40

Beitragvon someone » 30.08.2015, 20:29

So, trotz des schönen Wetters komme ich aus dem Forschen nicht heraus.

Ich habe mal auf der Syno Rackstation geprüft und dort ist tcp-segmentation-offload deaktivert. Trotz reboot.
Wie mag das kommen? Bei eth0 der Syno ist es an, bei eth1, welches direkt mit der nic1 des ESXi verbunden ist, aus.
Trotz Reboot beider Systeme. Dann war das TSO off auf dem ESXi eventuell wirklich deswegen nötig?! Ich hätte gedacht, das wird "ausgehandelt".

Experte
Beiträge: 1003
Registriert: 30.10.2004, 12:41

Beitragvon mbreidenbach » 30.08.2015, 20:46

Aushandeln ?

TSO bedeutet daß das NIC mehr Paketverarbeitung und die CPU weniger tut.

Member
Beiträge: 30
Registriert: 24.12.2014, 15:40

Beitragvon someone » 30.08.2015, 21:23

Okay dann bin ich auf dem Holzweg. Ich bin davon ausgegangen, dass der Parameter auf beiden Seiten identisch sein muss. Wie auch Geschwindigkeit und Flow Control.

Edit: wenn die MTU bei der Syno größer eingestellt wird, wird tso deaktiviert. So konnte ich es im Kernel 3.2 Source für die CPU finden.
Könnte die MTU size auch beim esxi etwas beeinflussen? Immerhin ist es ja eine Whitebox..

Ich hab als Alternative mal eine weitere PCI-E Karte bestellt. Zwar realtek aber nur ein 5er bei Conrad.

King of the Hill
Beiträge: 12251
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 31.08.2015, 00:44

Wenn du den 6er ohne angepaßtes ISO installiert hast, wirst du aufgrund diverser HW-Rauswürfe kein Glück mehr mit Realtek haben. Die waren bereits beim 5.5er als "deprecated" geführt...

Hier mal die KB-Einträge für Devices deprecated and unsupported in ESXi 5.5 (2056935) und Devices deprecated and unsupported in VMware ESXi 6.0 (2087970).

Member
Beiträge: 30
Registriert: 24.12.2014, 15:40

Beitragvon someone » 31.08.2015, 08:42

Danke für den Hinweis.
War mir aber bekannt und dennoch einen Versuch wert. Viele Mini PCI express Karten sind nicht am Markt.
Allerdings bin ich mit dem aktuellen Status wenig zufrieden.
Bei iscsi fiel bei hohe Last die NIC aus und nun bei NFS plötzlich.
Irgendwie hab ich da meine Zweifel ob es nicht doch in Hardware Problem mit der NIC gibt.

King of the Hill
Beiträge: 12251
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 31.08.2015, 10:39

Um einen weiteren Punkt in der möglichen Ursachenliste abzuhaken. Hast du spasseshalber mal die Jumbo-Frames abgeschaltet?
Diese sind offiziell erst bei 10GigE festgeschrieben worden. In den meisten Fällen klappt das jedoch auch mit 1GigE. Ich würde auch mal mit einem kleineren MTU-Wert testen. Nicht das für die 9000er MTU irgendwelche Buffer zu klein sind. Ein FW-Update der Intel-NIC würde ich ebenfalls in Betracht ziehen.

Member
Beiträge: 30
Registriert: 24.12.2014, 15:40

Beitragvon someone » 01.09.2015, 21:04

Hallo,

MTU habe ich nicht mehr ausprobiert.
Wer mal nach 82574L und Probleme oder TSO googlet, wird feststelle, dass dieser Chip schon immer Probleme gemacht hat. Es gibt dazu diverse Linux Treiber Probleme.
Ich habe mich daher entschieden die 5 Euro Karte von Conrad in den ESXi zu bauen. Sie hat einen RLT8111 Chip. Mag natürlich sein, dass mich das vom Regen in die Traufe begebe, aber schauen wir mal. Den Treiber musste ich natürlich nach installieren.
Sollte sich hier was neues aus den Tests ergeben kann ich hier gerne Aktuelles posten.
Eventuell probiere ich auch mal wieder iSCSI aus. Vielleicht lag es ja nur an der Intel card... (auch wenn ich von iSCSI inzwischen weg bin und NFS bevorzuge)

Member
Beiträge: 30
Registriert: 24.12.2014, 15:40

Beitragvon someone » 05.09.2015, 17:25

Ich wollte nochmal Feedback geben. Vielleicht hilft es ja dem ein oder anderen...
Die Intel 82574L ist nun gegen eine 8111 Karte getauscht worden und seitdem ist Ruhe im Karton.
Aufgefallen ist mir nur, dass ethtool sagt, dass bei der 8111 viele Features abgeschaltet sind. Ich denke mal, dass das hier eine Limitierung der Hardware ist oder der Treiber diese Features nicht implementiert oder bewusst deaktiviert hat.
Wie dem auch sei. Bisher bin ich zufrieden :)
Danke nochmal für Eure Unterstützung!


Zurück zu „vSphere 6.0“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast