ESX 6.0 U2 friert quasi ein wenn eine disk beschädigt ist

[lennier]

Hallo zusammen,

ich hab ein äusserst seltsames phänomän mit dem neuesten ESXi.

zuerst dachte ich das die iSCSI anbindung schuld ist (das log hat nur so gewütet) jedoch nach verschieben der disks und entfernen des software initiators besteht das problem immer noch, jedoch nun von der internen disk.

Auf dieser Disk dürfe es einen defekten Block geben, denn sobald ich die virtuelle maschine kopiere (Download im Storage Explorer, oder Veeam Zip) friert der vmKernel ein.
Einfrieren heißt:
PING auf das interface geht noch
per IPMI Console kann ich mit ALT und F1 - F2 - F11 und F12 zwischen den einzelnen screens umschalten
auf F12 (dem vmkernel) log geht die hölle ab
auf F2 komm ich bis zum einloggen, dannach ist finster
SSH ist finster
vCenter ist finster
direkter mit dem client drauf ist´s ebenfalls finster

einzige möglichkeit den Reset knopf drücken!

Der Host ist wie üblich auf einem USB Stöpsel, bzw. bei diesen Maschinen auf einem DOM (16GB Disk on Module).
Es gibt ne main und eine backup maschine die baugleich sind.
In beiden steckt eine einzelne 1TB SSD die die OS Laufwerke der Guest systeme beinhaltet (diese wird einmal täglich repliziert).
Die Daten liegen zum größtenteil auf Iscsi Targets die jetzt direkt in den Gast Systemen verbunden sind (wie eingangs erwähnt waren die ersten log errors vom ISCSI initiator).
Jetzt hab ich beide SSD´s in einem Host weil ich die system Disk noch rausziehen wollte und im zuge dessen jetzt die gewissheit habe das diese hinüber ist.
Was mich jetzt nur anfuxt ist, das bei dem ausfall der vmkernel komplett ausfällt und bei einer virtualisierungslösung der ausfall eines storrages ja keine so großen probleme bereitet (ausser den dauf befindlichen gästen).
In dem log wird der AHCI Controller soft, hard und geforced resettet und das im 2 sekunden tackt.
Und schlussendlich ist der Host stehend KO weil er mit sich selbst beschäftigt ist.

Solche Probleme hate ich mit 5.5 noch nie und hier sind auch schon mal ab und an storrages ausgefallen, vorallem die ADAPTEC (Microsemi) Controller haben die Hosts täglich gekillt.

[~thc]

Hattest du denn unter 5.5 auch schon AHCI/SSD-Datastores, die dir vergleichbar ausgefallen sind?

Ich habe in meinen Jahrzehnten noch kein OS gesehen, dass ein Abschmieren einer IDE/SATA/AHCI-Harddisk gut "verarbeitet" hat - im Normalfall stand der Bus (Dauerlicht) und das OS gleich mit.

Da ESXi in einer RAM-DIsk läuft, bringt es eigentlich ideale Voraussetzungen mit - aber wenn du ein System mit defekter SATA-Harddisk vom USB-Stick oder DVD bootest, läuft alles prima - bis das OS zu ersten Mal auf die Platte zugreift - dann steht es auch.

[irix]

Ich kann auch nicht behaupten das ESX/ESXi besonders tollerant gegenueber Storageproblemen ist bzw.. ich wuerde es auch nicht erwarten.

Wir haben eigentlich nur mit LUNs von externen SANs zutun und weniger mit Localstorage und da kann ein Fehler bei einem iSCSI Datastore den ganzen ESXi mit herunterreißen.

Ob APD, PDL da eine Verbesserung bringen kann stell ich mal so in den Raum.

Gruss
Joerg

[kastlr]

Hallo zusammen,

ist es nicht auch eher die Aufgabe der entsprechenden Komponenten, frühzeitig auf Indikatoren zu reagieren, welche sich mittel und langfristig zu Problemen entwickeln können?
Wenn es dort inzwischen defekte Blöcke geben sollte, warum hat der Adapter sich nicht rechtzeitig um die Verlagerung der Daten gekümmert oder dem Administrator mal eine Warnmeldung zukommen lassen?

Sofern die Hardware sich als Fehlerlos ausgibt, warum sollte denn eine Software das in Frage stellen.
Und wenn das Gast OS trotz Problemen nicht aufhört diese Daten anzufordern, warum sollte dann der ESX Server dies tun?

Meiner Meinng nach wird hier das falsche Produkt an den Pranger gestellt.

Nicht falsch verstehen, ich darf mich häufig um Probleme im Bereich VMware und Storage kümmern, aber ein Storage Hardware Problem ist und bleibt ein Storage Hardware Problem.

Hier mal ein Link zum Thema Storage IO crash consistency with VMware products (1008542)

Gruß,
Ralf

[Dayworker]

Dazu müßten die Komponenten aber erstmal von einem Problem wissen. Der übliche SMART-Test beim Rechnerstart testet zwar kurz und wirft ggf ne Meldung raus, aber das war es auch schon. Wenn das Problem zur Laufzeit auftritt, muß irgendwer das auch ständig im Blick haben. Bei sämtlichen Desktop-OS auf Windows-Basis ist dies meines Wissens aber nicht der Fall oder wird nur detektierbar, wenn man zumindest ein wie auch immer geartetes Raid einsetzt. Dann hängt es vom Controller ab, wie er in einem solchen Fall damit umgeht. Bei allen mir bekannten HW-Controllern (Adaptec, LSI) verliert man jedoch bei jedem Raid-Level automatisch auch die Abfragemöglichkeit der SMART-Werte. Kurioserweise wäre man da mit einem im OS zusammengebastelten Raid besser dran und könnte die Werte weiterhin auslesen.

Bezüglich Badblocks. Ich habe es sowohl mit einem Fake-Raid als auch mit LSI zumindest beim Raid1 mehrfach erlebt, daß etwaig gemeldete Badblocks nicht unbedingt stimmen müssen. Mir war eine Platte ausgefallen und nach Tausch meldete mir die LSI-SW auch auf der niegelnagelneuen Platte wieder Badblocks. Der LSI-Controller hat also einfach mal die vorher gemeldeten Badblocks von einem Raidmitglied auf das andere "kopiert". Selbst die meisten Imager sind dann keine Hilfe, da die Badblocks zumindest bei NTFS im Sektor 8 zuerst gesichert werden und man den Mist somit mitsichert. Dazu hatte ich auch mal den Thread Datenträger-Image anlegen trotz defekter Sektoren inklu Lösungsmöglichkeit für Windows verfaßt.

Unabhängig davon wird bei Einzellaufwerken ein grosser Unterschied gemacht. Die Time-Limited Error Recovery, kurz TLER, greift meines Wissens nach nur bei Raid-Leveln und demzufolge triggert ein OS die Platte solange an, bis das OS nur noch damit beschäftigt ist. SATA bietet zudem auch keine Möglichkeit, etwige Übertragungsfehler zu bemerken und ggf eine erneute Übertragung anzustossen, das wurde erst bei SAS umgesetzt.

[lennier]

Hi,

ich hab die disk mit HW2Test komplett (also 1TB) durchgetestet, funktioniert einwandfrei.
Warum der ESX da komplett enrage geht kann ich mir nicht erklären, zumal unter 5.5 und davor sowas nie passiert ist.

[Dayworker]

Je nach SSD, Controller und Firm- sowie Treiberversion gibt es häufiger mal Probleme. Nimm zum Testen nicht irgendwelche Tools, sondern sieh dich bevorzugt bei Hersteller um. Einige Hersteller wollen bei Problemen auch gerne gleich den vom Hersteller-Tool gemeldeten Fehlercode wissen.

Das der 6er auch hier grössere Kopfschmerzen verursacht, ist im Grunde fast zu erwarten gewesen und wird wohl weiterhin nur die Spitze des Eisbergs sein. Da wird sicherlich noch mehr nachkommen.

[kastlr]

Hallo,

was genau wird denn im vmkernel.log protokolliert, wenn das System anfängt zu spinnen.
Denn wenn die Platte tatsächlich fehlerfrei sein sollte, warum sollte der ESXi Server dann Plattenfehler melden?
Eventuell liegt das Problem ja an dem verwendetem Controller.

Gruß,
Ralf