ESXi Host löscht VM´s? Geht das?

[Keks22]

Hallo zusammen

Wir haben hier ein sehr seltsames Problem. Von gestern auf heute sind einige VM´s nicht mehr vorhanden und wir haben leerverweise. Ganz konkret sieht es so aus:

Wir haben 3 Hosts welche auf 3 Datastores auf einer msa2324sa zugreifen. Host 1 meldet auf allen 3 Datastores folgenden Fehler und zwar alle paar Minuten:

Auf Volume "..." wurde mindestens eine beschädigte Ressourcen-Metadaten-Region gefunden. Weitere Bereiche des Volumes sind möglicherweise auch beschädigt.

Der Fehler wird nun von einem Host angezeigt, die anderen zeigen keine Fehler an. Auf dem Host 1 sind nun VM´s vorhanden welche eine nach dem anderen "verschwinden" und der Fehler vom ESX Host ist erstmalig zur gleichen Zeit angezeigt worden wie die erste VM verschwunden ist.

Nachforschungen haben folgendes ergeben. Der Ereignislog der SAN zeigt kein Fehlverhalten an. VM´s welche auf dem besagten Host liefen sind entweder komplett vom Datastore verschwunden oder Configfiles sind nicht mehr vorhanden oder der Ordner der VM auf dem Datastore ist leer. Wie kann es passieren das einer laufenden VM die Daten entzogen werden?!? Das geht doch gar net. Auf den Anderen ESX Hosts habe ich die Datastores auch überprüft und die zeigen das gleiche Bild an. Ich habe mich zudem noch via Webbrowser mit dem Datastore Browser verbunden und sehe hier einige Dateien mit einer Filegrösse von "-1", z.B. Konfigfiles!.

Hat einer eine Ahnung was uns hier passiert ist oder wo das Problem liefen kann? Wir haben sicherheitshalber mal den betroffenen Host ausser Betrieb genommen. Das ärgerliche daran ist, wir haben bereits den DC (samt Exchange), einen SharePoint und zwei Webserver "verloren", Wir haben zwar Backup, wüssten aber trotzdem gern was hier lief!!!

Gruss
Keks

[bla!zilla]

Unbedingt einen SR bei VMware öffnen. Sieht nach einem defekten VMFS aus.

[Keks22]

Hab ich mir auch so gedacht, aber wie kann es sein das nur 1Host den Datastore als fehlerhaft anschaut und die anderen nicht?!? Versteh ich nicht....wir wollten morgen alles wieder versuchen hinzubiegen, aber wenn wir erst den SR machen dann steht unsere Firma still am Montag....

[bla!zilla]

Sehr unprofessionelles Vorgehen. Mach den SR auf und lasse VMware das Problem lösen. Ich sehe die Gefahr, dass da noch mehr zu Bruch geht.

[Keks22]

Ja noch haben wir nix gemacht! Ich sehe es auch so zuerst den Call zu machen und zu warten das VMware das Problem anschaut. Kannst du dir erklären warum ein Host die Datastores als "defekt" anschaut und die anderen beiden Hosts nicht?

Mit hinbiegen ist wohl eher gemeint, die VM´s zur Not auf physikalischer Hardware wieder bereit zu stellen. Die Datastores sind ja im Moment nicht "sicher". Ein Restore auf die möglicherweise "fehlerhafte" Infrastruktur kommt nicht in Frage, das Problem muss zuerst analysiert und gelöst werden und dann lieber noch einen Tag drauf verzichten als jetzt übereilte Aktionen durchzuführen.

Könnte durch den Versuch die verbliebenden Daten von den Datastores weg zu kopieren (mittels FastSCP) noch mehr in die Brüche gehen und sollten wir lieber gar nix unternehmen oder wäre es sinnvoll schnellstmöglich damit zu beginnen?

[Dayworker]

Wir haben Montag. Was sagt VMware zu eurem Problem?

[continuum]

Hab ich mir auch so gedacht, aber wie kann es sein das nur 1Host den Datastore als fehlerhaft anschaut und die anderen nicht?!?

Nicht wundern - ein Typ von VMFS Fehlern (ich nenne diese Fehler "Heartbeat Corruption") äussert sich so.
ACHTUNG: das Problem ist ansteckend !!! - kein Witz.

Hatte letzte Woche erst noch so einen Fall ... wenn es das ist, was ich meine, dann hilft dir VMware support auch nicht unbedingt weiter.

Ich empfehle dringend Massnahmen um grössere Datenverluste zu vermeiden.

Wenn ich mir die Sache mal ansehen soll - ruf an

[irix]

Die anderen Hosts bekommen das erst mit wenn Sie mal rebooten oder im einfachsten Fall ein Rescan HBA durchfuehren.

Wir waren von VMFS Heartbeat Corruption betroffen aber hier war die Ursache Hardware Vendor und ein kleinwenig VMware. Der Hardware Hersteller musste das Hauptproblem loesen und der VMware Support hat uns die Metadaten repariert.

Aber ich meine hier sieht das anders aus. Ich haette als erstes bei VMware nen Call aufgemacht und die VMs welche nur im Zugriff sind wegmigriert (frei Platz vorrausgesetzt)

Gruss
Joerg

[Keks22]

Ja wir haben Montag und stehen vor einem ziemlichen Scherbenhaufen.....

Ich sag es mal so...@continuum hat es passend formuliert!

Wir haben gestern für sage und schreibe 1200$ einen VMware Notcall eröffnet welcher 3 Stunden Analyse zur Folge hatte mit der Erkenntnis das VMware uns nicht wirklich helfen kann. Das Problem sind nicht die Metadaten oder oder das VMFS, welches laut VMware intakt ist, das Problem sind eher die Daten an sich welche sich bei jedem Zugriff darauf "selbst zerstören" und nicht mehr zugreifbar sind.

Am Freitag als das Problem nur auf einem Host geloggt wurde, haben wir den Host neu gestartet und alle Maschinen welche vor dem Neustart heruntergefahren oder auch nur in die Eigenschaften der VM geschaut wurde haben wir nach dem Reboot verloren. Solange die Maschinen laufen und VMware seitig nix gemacht wird, sondern nur innerhalb der VM operiert wird ist das ganze kein Problem. Lesezugriff über den Host auf den Datastore z.B. zum wegkopieren der restlichen ausgeschalteten VM's ist auch kein Problem, was wir auch durchgeführt haben. Sobald allerdings vom Host ein Schreibzugriff auf den Datastore passiert ist es vorbei mit der entsprechenden VM. Das Passiert z.B. wenn das Eigenschaftsfenster der VM mit OK statt Abbrechen geschlossen wird oder wenn der Gast vom Host in einen anderen Status versetzt wird (herunterfahren, ausschalten, einschalten, Clonen, vMotion usw.). Einen neuen Host zum Datenstore zu verbinden ging auch nicht, da dieser gleich nach dem Discovery meine "Nö,...da ist kein Dateisystem drauf. Darf ich formatieren mit VMFS???"

Also ich nenne es dann genauso wie @continuum Heartbeat Corruption oder wie der VMware Supporter meinte "massive Data Corruption". Ein VMFS oder Metadaten wären zu retten laut VMware aber Fehler auf Datenebene sind nicht wieder herstellbar ohne Dattenrettung!

VMware wartet jetzt darauf das wir uns an HP wenden damit VMware mit HP das Problem anschauen kann. Das Ganze hat aber keine Rettung der Daten zur Folgen (das geht nur noch über Datenrettungsfirmen (damit haben wir abgeschlossen)) sondern Sie wollen analysieren was dazu führte und wie es vermieden werden kann, hilft uns also im Moment nur bedingt weiter. Wenn ich es mal so sagen soll aus vergangen Calls bei HP wird eh nur der Controller getauscht und gut ist. Chance auf Aufklärung =0!

Noch haben wir noch kein Call bei HP gemacht, der folgt aber denk schon noch. Wir sind allerdings im Moment an dem Punkt die Geschichte VMware/SAN in Frage zu stellen den das traurige daran ist das der Fehler passiert ohne Anzeichen oder Fehler auf irgendeine Art und Weise zu bekommen. Im Gegenteil.

Falls noch jemand eine Idee hat, das "TESTSYSTEM" (so wie wir es jetzt nennen) steht noch!

Gruss
Keks

[Keks22]

Die anderen Hosts bekommen das erst mit wenn Sie mal rebooten oder im einfachsten Fall ein Rescan HBA durchfuehren.

Der Post kam leider ein wenig zu spät!

[bla!zilla]

Für meinen Geschmack stinkt das sehr nach einem Problem mit der MSA.

Bezüglich Support von HP: You get what you pay for. Gegen Einwurf kleiner Münzen gibt es nicht nur reaktiven Break-and-Fix-it-Support, sondern auch relativ guten Support. Ich bin immer wieder erstaunt wie wenig Kunden da bereit sind Geld zu investieren und sich dann wundern, warum HP REAKTIVEN Support leistet.

[irix]

Letztendlich ist das Kind ja schon in den Brunnen gefallen aber ich haette eine Frage:
- Gabs ueberhaupt SnS fuer die Umgebung oder ist es "nur" ein Essentials? Ansonsten wie kommen die 1200,- zustande?
- Bei uns war im Log das "Corruption" deutlich gekennzeichnet. Der Support wusste auch sofort bescheid als ich sagte welches Storage wir haben. Bei uns war aber nichts "verschwunden" und der Support konnte ohne Datenverlust alles reparieren. Ich meine immer noch das dein Problem anders gelagert zusein scheint.


Gruss
Joerg

[bla!zilla]

- Bei uns war im Log das "Corruption" deutlich gekennzeichnet. Der Support wusste auch sofort bescheid als ich sagte welches Storage wir haben. Bei uns war aber nichts "verschwunden" und der Support konnte ohne Datenverlust alles reparieren. Ich meine immer noch das dein Problem anders gelagert zusein scheint.

Das sehe ich auch so.

[Keks22]

Wo genau war die "Corruption" im Log zu sehen? Wir sehen nur die Fehler im vCenter im Host Log. Die MSA zeigt keine Anzeichen eines Fehlers.

Diesen Fehler bringt der Host bei jedem Zugriff auf den Storage:

At least one corrupt resource metadata region was detected
on volume 4e2f4512-d7820fef-d4ad-00237ded446e
(san-sft01data03). Other regions of the volume might be
damaged too.
error
13.10.2014 15:26:30
srv-sftesx05.softtech.ch

Es ist eine Essentials Plus Umgebung. Wir haben intern nur den "Basic Support Agreement" Support welchen wir durch ein Upgrade (1200$) in einen Produktion Support umgewandelt haben. Das Geld ist ja gar nicht das Schlimme daran, nur die Tatsache das der Support nicht helfen konnte ist ärgerlich und die Wahrscheinlichkeit das jemals rausgefunden wird wo der Fehler war ist = 0.

You get what you pay for! Das sehe ich eigentlich auch so, aber bei einem Betreib unserer grösse wärealles andere Überdimensioniert (Betreib mit 15 Mitarbeiter im Bereich Abacus und IT Dienstleistung). Was gibt es den für bessere Möglichkeiten als ein Carepack auf der Hardware zu haben? Wenn Carepack nur Break and Fix Support wäre, fänd ich das tragisch.

Grundsätzlich bin ich mit dem HP Support auch zufrieden und hab gute Erfahrungen gemacht, aber bei Komplizierteren Problemen find ich es nicht in Ordnung erst mal Teile auszutauschen in der Hoffnung der Fehler ist danach weg als das Problem zu analysieren. Meistens ändert der Tausch einer Komponente sehr viel und löst das Problem temporär, kommt aber wie schon oft erlebt später erneut.

Gruss
Keks

[Keks22]

Wir denken auch das es ein Storage Problem ist. Wenn die VM's laufen findet diese ja meistens alles im Cache vom Host statt. Der Fehler äussert sich ja nur wenn vom Host Operationen über den Storage Controller am Storage stattfnden (Log Datei schreiben, Konfigurationsänderungen usw.). Das deutet für mich auch sehr stark auf ein Controller Problem hin. Warum allerdings der Controller keine Fehlermeldungen anzeigt ist mir schleierhaft.

[Keks22]

Falls jemand was mit den Storage Logs anfangen kann, habe ich sie mal hier plaziert.

https://onedrive.live.com/redir?resid=A ... 7E9%215128

Gruss
Keks22

[irix]

Ein ESXi, mal von CBRC oder VSAN abgesehen "cached" nichts.

Gruss
Joerg

[Keks22]

Aber er lädt die VM doch in den Memory oder nicht?

[bla!zilla]

You get what you pay for! Das sehe ich eigentlich auch so, aber bei einem Betreib unserer grösse wärealles andere Überdimensioniert (Betreib mit 15 Mitarbeiter im Bereich Abacus und IT Dienstleistung). Was gibt es den für bessere Möglichkeiten als ein Carepack auf der Hardware zu haben? Wenn Carepack nur Break and Fix Support wäre, fänd ich das tragisch.

Aber genau das ist ein Carepack: Break & Fix. Schau dir mal Proactive Care oder Foundation Care Support an.

[JustMe]

Aber er lädt die VM doch in den Memory oder nicht? Shocked

Wieso sollte er DAS denn tun??? Doppel-

Was im Hauptspeicher des Hosts ausgefuehrt wird, ist der Hauptspeicherinhalt des Gastbetriebssystems. Die Daten von der (virtuellen) Platte werden ganz sicher nicht zur Ausfuehrung der VM in den "Memory" geladen, auch nicht z.B. bei einem Kopiervorgang, bei dem hoechstens Bloecke der vmdk durch Puffer des Hauptspeichers geleitet werden.