ESXi 5.1 abgesturtzt - VM startet nicht mehr

[novichok1977]

Moin, ich habe ein Problem. Ich habe einen ESXi5.1 Server der wurde über die Nacht abgeschmiert. Auf dem habe ich eine VM mit dem 2008 Server und die VM hat 5 Platten. Wenn ich Datastore anschaue sehe ich 5 Platten bzw. disk.vmdk, disk1.vmdk etc. Plus Snapshot Dateien dir vor einem Monat erstellt wurden disk-ooo1.vmdk, disk1-0001.vmdk etc.
Die Maschine startet nicht und bleibt bei 95% händen nach ca. 10 Min. kommt die Meldung
Beim ESX-Host ist ein Fehler beim Einschalten der virtuellen Maschine Kronos aufgetreten.
Die Festplatte '/vmfs/volumes/51dd0c75-16d02185-ada9-3c4a92e870ae/Kronos/Kronos-000001.vmdk' oder eine der Snapshot-Festplatten, auf die sie angewiesen ist, konnte nicht geöffnet werden.
0 (Input/output error)
Ich habe versucht die Snapshots zu löschen ging nicht. Neue Snapshots erstellt. Hats geklappt. Jetzt habe ich natürlich fünf mal Kronos-000002.vmdk
Dann dachte ich jetzt kann ich die Snapshots über GUI vSphere löschen, klappt aber nicht. Allgemeine Systemfehler.
Jetzt kann ich die Maschine gar nicht starten.Gleiche Meldung wie vorher:
Die Festplatte '/vmfs/volumes/51dd0c75-16d02185-ada9-3c4a92e870ae/Kronos/Kronos-000002.vmdk' oder eine der Snapshot-Festplatten, auf die sie angewiesen ist, konnte nicht geöffnet werden.
0 (Input/output error)

Was kann man machen? Die Datensicherung wurde seit einem Monat nicht mehr gemacht.

[novichok1977]

Habe jetzt Datastore überprüft die Datei *.vmsd hat nur drei Zeilen:
.encoding = "UTF-8"
snapshot.lastUID = "13"
snapshot.needConsolidate = "TRUE"

Die *.vmsn Dateien fehlen komplett

Kann man das noch reparieren?

[JustMe]

Die *vmsd-Datei duerfte nicht problematisch sein; die braucht da System nur, um im Snapshot-Manager was anzeigen zu koennen. DAS liesse sich einfach bereinigen (wenn auch nicht so einfach reparieren).

Das schlimmere Problem duerfte aber der Input/Output Error sein, der auf ein Leseproblem auf den physischen Datentraegern hinweist. Vmtl. wird auch ein Copy der Dateien auf einen anderen Datastore (oder mit WinSCP) den gleichen Fehler zeigen.

Wenn der Lesefehler in der Basisdatei liegt, koennte die Sicherung von vor einem Monat noch wertvoll sein. Liegt er in der Snapshot-Datei *-0000x.*, dann hilft nur nur noch "continuum".

[Dayworker]

Das erste gleich vorneweg und in aller Deutlichkeit. SNAPSHOTS SIND KEIN BACKUP
Bevor du jetzt noch irgendwelche weiteren Probleme verursachst und dich dadurch ggf sämtlicher Rettungsmöglichkeiten beraubst, würde ich erstmal klären, weshalb der ESXi überhaupt abgestürzt ist. Bei deiner VM-Angabe von 5 vDISKs plus die einen Monat alten Snapshots würde ich fast alles auf einen vollgelaufenen Datastore setzen und diesen Umstand gilt es als erstes zu beheben.

Zippe daher von dieser VM alle vorhandenen Logs, VMSNs und VMDKs unter 5Kilobyte und verlinke die auf einen Freehoster. Desweiteren wäre es hilfreich ein komplettes Dateilisting per "ls -l" dieser VM mit sichtbaren Grössenangaben zu haben und sowohl die Grösse des DataStores als auch noch dessen freien Platz zu wissen. Da der im ESXi-eingebaute DS-Browser seit Generationen lügt, mußt du dich für die letzten beiden Angaben entweder per SSH auf den ESXi draufschalten oder direkt am ESXi ein Terminal mit ALT+F1 aufmachen und dich dann zum VM-Ordner durchhangeln.

[continuum]

Hallo
wie JustMe schon sagte: wenn der I/O error bei einem der Snapshots auftritt hast du ein ernstes Problem.
Falls du die Snapshotkette noch überblickst versuch einen Clone des letzten Snapshots per vmkfstools

vmkfstools -i kaputt-000002.vmdk neu.vmdk

Wenn das dann auch mit einem I/O error abbricht - dann ruf am besten mal an und ich schau mir die Sache mal genau an.

Telefonnummer habe ich dir per PM geschickt.

[novichok1977]

Jungs, vielen Dank. Konnte nicht antworten, hatte keine Zeit. DIe VM läuft wieder. Habe selbst alles hin bekommen. Danke für die Unterstützung

[continuum]

Es wäre nett wenn du kurz berichtest was los war und wie du es beheben konntest

[novichok1977]

1. Bei dem VM Start hatte ich die Meldung das die Platte xxx-0001.vmdk defekt ist oder änlich. Dann habe ich in Storage geschaut und habe gesehen dass die Datei xxx.vmdk vorhanden ist und ist gleich groß wie xxx-0001.vmdk.
2. Ich habe die vmx Datei geändert. So dass die VM von statt xxx-0001.vmdk die xxx.vmdk nimmt. Die restliche Partitionen habe ich so mit xxx1-0001.vmdk gelassen. Zum Glück ist die VM Hoch gefahren. Daten waren aktuell.
3. Snapshot über CLI erstellt. Davor war es gar nicht möglich.
4. Nach 4 Stunden über CLI alle Snapshots konsolidiert.
5. Nach 4 Stunden war die VM wieder in Ordnung. vSphere zeigt Konsolidieren ist nicht mehr erforderlich.
Ich bin so glücklich. Danke für eure Hilfeangebote. Hoffentlich hilft mein Thread jemandem weiter.
Grüße aus Bremen

[Dayworker]

Die "xxx.vmdk" war die Basis-VMDK und die "xxx-0001.vmdk" der Snapshot. Der Snapshot selbst kann dabei je nach Schreibanforderungen in der VM immer bis auf die Grösse der Basis-VMDK anwachsen und nur weil die Snaphot-VMDK inzwischen dieselbe Grösse wie die Basis-VMDK hat, sagt das nichts über eventuell verloren Daten aus. Kommt halt drauf an, was genau in der "xxx.vmdk" gespeichert war. Falls du darin nur das OS samt Programmen gespeichert und ansonsten eine vollständige Trennung (verschiedene Platten keine Partitionen) zwischen OS und Nutzdaten vorgenommen hattest, sind vielleicht nur einige Programme, deren Programm- oder allgemeine OS-Einstellungen verloren gegangen. Die Daten in einer anderen vDISK sprich VMDK sind davon jedoch völlig unabhängig.

[novichok1977]

Da es sich um einen SQL Server handelt war die Erste Partition nur das OS. Restliche vier sind Logs, Datenbanken, SQL Backup und die Software.

[Dayworker]

Dann war mit deinem Vorgehen nur in diesem einen, bestimmten Fall kein Datenverlust aufgetreten. In allen anderen Fällen ist der Datenverlust gewiß und dieser ist umso grösser, je grösser die Snapshot-VMDK ist.

Gerade bei Datenbanken würde ich aber auf jedwede Art von Snapshots verzichten und diese ausschließlich zum Zwecke eines Backups nutzen. Ein Snapshot wird je nach VMware-Produkt immer als Sparse- bzw Thin-VMDK angelegt und macht dadurch jedwede Performancevorteile einer Thick-VMDK zunichte.

[novichok1977]

Das ist mir klar. Das Snapshot entstand weil die Datensicherung wurde gestartet und snapshot wurde erstellt. Die Datensicherung wurde aber abgebrochen aber das Snapshot wurde nicht gelöscht. Die Daten wurden in das Snapshot vmdk geschrieben.
Keiner hat es gesehen. Also ich wurde sagen - Glück gehabt.