VCenter startet nicht mehr / Stack Overflow

[Morbus]

Hallo,

seit gestern startet unser VCenter-Server (Server 2K3, VCenter-Version 4.0 Update 2) nicht mehr.
Nach Analyse der Logfiles (Meldung: Stack Overflow) hat sich herausgestellt, das bei drei VMs durch das nächtliche Backup zwar Snapshots angelegt, aber nicht wieder gelöscht wurden.
Leider wurden daher die Snapshots auch nicht im VClient angezeigt.

Bei einer VM gibt es zumindest jetzt fast 70 VMDK-Files; dadurch dann natürlich der Stack Overflow.

Hat jemand eine Idee, wie man an das Problem am Besten heran geht? Neuer VCenter bringt ja nix, so lange die Snapshots nicht ordentlich bereinigt sind.

Hinzu kommt, das die letzten beiden Nächte das Tape-Backup durch den Fehler nicht ordentlich durchgelaufen ist. Wir hätten also zwei Tage Datenverlust. Daher wäre es wichtig, die Daten aus den Snapshots zu erhalten.

Für einen Tip bin ich echt dankbar.

thx

[Supi]

Direkt auf den ESX(i) per Vsphere Client aufschalten?

[irix]

Die Anzahl von 70 VMDKs sollte aus meiner Sicht nicht zu einem Fehler in der Managementkomponente führen. Ergro wenn die Huette brennt warum wird nicht der eingekaufte Supportanspruch verwendet?

Ein

Code: Alles auswählen

vmware-cmd /paht/*.vmx hassnapshot

zeigt ob eine VM aus Sicht des HOSTs Snaps enthaelt. Ob die Kette intakt ist kann man mit snapinfo und snapvmx ermitteln. Dabei wird auch gleich der Platzbedarf angezeigt* welche man für das löschen braucht.

Mittels

Code: Alles auswählen

vmware-cmd /paht/*.vmx removesnapshots

werden alle Snaps einer VM geloescht.

* IIRC hat sich die Art wie unter VMware nun Snapshotketten geloescht werden geaendert so das weniger zusaetzliche Resource benoetigt werden.

Wenn Ruhe eingekehrt ist zusaetzliches Reporting implementieren das nach Snaps sucht und je nach Anzahl/Alter den Admin informiert.

Gruss
Joerg

[Morbus]

Das funktioniert zwar, aber das Problem ist nicht gelöst. Die Snapshots werden nirgendwo angezeigt.
Man erkennt es lediglich an den Unmengen an VMDK-Files auf dem SAN.

Daher kann ich mit dem VClient leider nicht viel anfangen. Und der VCenter startet dann immer noch nicht.

[Morbus]

@irix

Die entsprechenden Befehle haben wir schon alle durch. Ergebnis: hassnapshot = 0.

Die Snapshots werden vom ESX nicht erkannt, sind aber physikalisch als Datei vorhanden und beeinhalten definitiv auch Daten. Dadurch hat auch die Snapshot-Überwachung (haben wir eingerichtet) leider nicht angeschlagen.

Ist irgendwie verzwickt. VMWare-Call haben wir aufgemacht, bisher jedoch noch keine Lösung. Scheint leider etwas ganz Spezielles zu sein

Ich hatte noch mal die Idee, mit dem VCenter-Converter die VM zu klonen. Dann sollte er evtl. nur noch ein VMDK-File haben. Falls dann Daten fehlen, würde ich dann per Robocopy einen Abgleich mit der aktuellen VM machen.
Ist halt nur die Notlösung; falls zeitnah keine andere Lösung in Sicht ist.

Um 9 Uhr kommt ein VMWare-Consultant. Werde mal posten, wie das Problem behoben wurde.

[irix]

Der ESX Host ermittelt seine Snaps in dem er die kleinen *.vmdk Descriptordateien analysiert. Das dumme vCenter bekommt seine Infos ueber den VPXA welcher ungluecklicherweise seine Infos aus der *.vmsd Datei holt. Ist diese Datei defekt/fehlt zeigt ein vCenter im Snapshotmanager keine Infos mehr bzw. es fehlen welche.

Mittels

Code: Alles auswählen

cd /path/to/vmfolder
file *

kann man sehen welche Dateien gelockt "no read permission" sind und darum rueckschlusse ziehen ob sie in Benutzung sind.

Das geht auch noch besser mittels

Code: Alles auswählen

cd /path/to/vmfolder
watch "ls -Ghtu --full-time *.vmdk"


Da siehst du dann in welche VMDK Dateien er wann zuletzt geschrieben hat.

Gruss
Joerg

[irix]

..

Um 9 Uhr kommt ein VMWare-Consultant. Werde mal posten, wie das Problem behoben wurde.

Gibts schon Lebenszeichen oder sitzt ihr noch mit dicken Augen vor den Bildschirmen?

Gruss
Joerg

[Morbus]

Hi,

das mit den dicken Augen kommt fast hin Haben bis gestern nachmittag am Restore gesessen.

Aber von Anfang an:

- Am Freitag war ein Consultant eines VMWare-Partners bei uns. Weil die VMDK-Files leider teilweise noch gelockt waren, haben wir den entsprechenden ESX durchstarten müssen.

Danach konnten alle Snapshots gelöscht werden. VirtualCenter lief dann auch wieder; jedoch war der Datenbestand der betroffenen VM nicht mehr aktuell. Bisher haben wir die Ursache nicht finden können.
Ein Checkdisk zeigte zudem tausende korrupter Dateien an.

Aus diesem Grund haben wir uns dazu entschlossen, die Daten vom nächtlichen Backup zurück zu spielen. Das Problem dabei nur, das aufgrund des Problems seit Donnerstag kein Backup mehr möglich war. Es gibt es also jetzt einen entsprechenden Datenverlust.

Wir haben jetzt noch eine letzte Hoffnung; und zwar haben wir vorher eine Kopie aller VMDKs erstellt. Jedoch lässt sich eine Kopie der VM nicht starten, da der letzte Snapshot scheinbar defekt ist.
Wir haben versucht, über die VMX-Datei auf den vorherigen Snapshot zu verweisen; der Datenverlust wäre dann noch gering.
Aber auch damit lässt sich die VM nicht starten (Invalid Data Storage)

Gibt es sonst noch Möglichkeiten?

[Dayworker]

Das dürfte ein Fall für unseren VMware-Gott Ulli aka continuum und Sickbay sein.