VMX-Datei fehlt plötzlich, VMDK-Datei korrupt?!?

[Guy Inkognito]

Hallo zusammen,

ich wollte einer VM (Win Srv 2008 R2, gehostet auf einem ESXi 5.0-Server) mehr RAM spendieren und habe sie dafür runtergefahren. Nachdem ich den RAM via vSphere-Client erhöht habe und den Wizard mit "OK" beenden wollte, wollte gab es die Fehlermeldung: "Datein <unspecified Filename> nicht gefunden". Die VM startet auch nicht mehr, weil das VMX-File nicht mehr gefunden wird. Ich habe in das Verzeichnis der VM geschaut, dort gibt es nur noch das .VMDK-File und ein 0,00 KB großes VMSD-File.
Wenn ich eine neue VM erstelle und das vorhandene VMDK-File als Festplatte einbinden möchte, wird mir im betreffenden Verzeichnis nichts angezeigt. Im Datenspüeicherbrowser wird es mir jedoch wie gesagt angezeigt. Die VM einfach mal durch den Converter zu jagen (Verzweiflungstat) funktionierte natürlich auch nicht, da der Converter keine Hardwareinformationen einholen konnte.

Wie konnte es dazu kommen? Hat vielleicht jemand eine Idee, wie das wieder ans laufen bringen könnte? Nein, es gibt kein Backup der VM. Ich betreibe hunderte und habe schlicht keine Infrastruktur zur Sicherung. Danke im voraus!

Grüße

[JustMe]

Erster Hinweis:
Wann immer man etwas mit Virtuellen Festplatten tut, sollte AUF KEINEN FALL der Datastore-Browser verwendet werden. Der zeigt nur eine "interpretierte" Sicht der Dinge. Stattdessen sollte fuer solche Zwecke doch lieber gleich die Kommandozeile gestartet werden.

Dann waere es bei diesem Problem nuetzlich zu wissen, auf was fuer einem Storage das Verzeichnis dieser VM lag. In dieser Richtung muss man dann weiterforschen.

Wenn dazu nix gefunden wird, und momentan fehlerfreier Zugriff auf dieses Storage besteht, kann man sich daran machen, die VM wiederzubeleben.

Zuerst mal schauen, welche Dateien wirklich noch im Verzeichnis auf dem Datastore existieren. Wenn da nur eine <VM>.vmdk zu finden ist (klein, so etwa ein halbes KB), und keine "grossen" Dateien, sollte man sich umgehend auf die Suche nach dem aktuellen Backup machen. Wenn's dieses Backup eben nicht gibt, dann koennen pauschal keine wichtigen Dateien in der VM existiert haben. Punkt.

Falls doch noch <VM>-flat.vmdk vorhanden ist, wird zuerst das Deskriptor file wiederhergestellt: z.B. Recreating a missing virtual machine disk descriptor file (http://kb.vmware.com/kb/1002511).
Danach erstellt man eine neue VM, der dann die Festplatte wieder hinzugefuegt werden kann, weil es ja wieder ein Descriptorfile gibt.

Falls es doch noch weitere Dateien im Storage-Verzeichnis geben sollte (z.B. vmware.log) kann man versuchen, die .vmx auch aus diesen Daten wieder zusammen zu setzen.

Hernach kann man sich dann an die Pruefung der Daten INNERHALB der VM begeben.

[irix]

Zeige uns ein

Code: Alles auswählen

ls -alh

Sichere die vmware*.log weil da stehen Infos drin. Bei jedem Startversuch rotieren die Logs und dann sind wichtige aeltere Infos nicht mehr enthalten.

Gruss
Joerg

[Guy Inkognito]

Erster Hinweis:
Wann immer man etwas mit Virtuellen Festplatten tut, sollte AUF KEINEN FALL der Datastore-Browser verwendet werden. Der zeigt nur eine "interpretierte" Sicht der Dinge. Stattdessen sollte fuer solche Zwecke doch lieber gleich die Kommandozeile gestartet werden.

Dann waere es bei diesem Problem nuetzlich zu wissen, auf was fuer einem Storage das Verzeichnis dieser VM lag. In dieser Richtung muss man dann weiterforschen.

Wenn dazu nix gefunden wird, und momentan fehlerfreier Zugriff auf dieses Storage besteht, kann man sich daran machen, die VM wiederzubeleben.

Danke für den Hinweis. Mir war nicht bewusst, dass der Datastore-Browser nur eine interpretierte Sicht darstellt. Ich habe jetzt mal SSH angeworfen und siehe da: Sobald ich im VMFS-Verzeichnis der VM ein simples ls mache, passiert erstmal genau garnix. Nach einigen Minuten gibts dann input/output Errors.

Wenn's dieses Backup eben nicht gibt, dann koennen pauschal keine wichtigen Dateien in der VM existiert haben. Punkt.

Ich gebe dir da vollkommen recht. Wenn man sich die Sicherungen von VMs sparen will, muss man eben mit den Konsequenzen leben. Der Gelackmeierte bin ich natürlich trotzdem

[continuum]

Hast du dir das Datastore mal von Linux aus angesehen ?

ESXi kann I/O errors melden während dasselbe Datastore sich via Linux problemlos auslesen lassen kann.
Wenn die VM wichtig ist kannst du dich ja mal melden - ob noch was zu retten ist kann ich dir nach ner knappen Stunde sagen.

[Guy Inkognito]

Hast du dir das Datastore mal von Linux aus angesehen ?

Naja ich bin halt von Windows aus via putty drauf und da gibts die besagten i/O Errors.

ESXi kann I/O errors melden während dasselbe Datastore sich via Linux problemlos auslesen lassen kann.
Wenn die VM wichtig ist kannst du dich ja mal melden - ob noch was zu retten ist kann ich dir nach ner knappen Stunde sagen.

Danke, ich kläre gerade, wie wichtig die VM gewesen ist. Parallel versuche ich, das vmdk-File mit dem vSphere-Client runterzuziehen. Mit der Bash komme ich ja nicht mal mehr in das Verzeichnis. Mal gucken, in 24h, wenn das kopieren hoffentlich fertig ist, weiß ich mehr und melde mich dann nochmal.

[continuum]

Wenn du per putty I/O errors bekommst - dann ist höchstwahrscheinlich ein Kopierversuch per Datastorebrowser witzlos und Zeitverschwendung.

Die Zeit kannst du dir sparen

[Guy Inkognito]

Wenn du per putty I/O errors bekommst - dann ist höchstwahrscheinlich ein Kopierversuch per Datastorebrowser witzlos und Zeitverschwendung.

Die Zeit kannst du dir sparen

Ich klammer mich an die 0,001%ige Wahrscheinlichkeit, dass die Sache ein gutes Ende nimmt

[Dayworker]

Daran würde ich mich nicht klammern sondern direkt "continuum" draufsehen lassen. Wenn er es nicht schafft, bleiben dir je nach Wichtigkeit nur noch Ontrack & Co übrig.

Du hast bisher leider noch nicht bekanntgegeben, um welches Storage es sich bei dir handelt. Aufgrund deiner Aussage zur Backup-Infrastruktur (mehr als den Ordner entweder bei abgeschalteter VM zu kopieren/clonen oder zumindest im Gast ein Backup durchlaufen zu lassen und extern zu lagern, wäre es eigentlich nicht) müssen wir wohl vom schlimmsten ausgehen. Ich tippe daher auf eine einsame SATA-Platte.

[Guy Inkognito]

Daran würde ich mich nicht klammern sondern direkt "continuum" draufsehen lassen. Wenn er es nicht schafft, bleiben dir je nach Wichtigkeit nur noch Ontrack & Co übrig.

Du hast bisher leider noch nicht bekanntgegeben, um welches Storage es sich bei dir handelt. Aufgrund deiner Aussage zur Backup-Infrastruktur (mehr als den Ordner entweder bei abgeschalteter VM zu kopieren/clonen oder zumindest im Gast ein Backup durchlaufen zu lassen und extern zu lagern, wäre es eigentlich nicht) müssen wir wohl vom schlimmsten ausgehen. Ich tippe daher auf eine einsame SATA-Platte.

Ich wollte das kopieren des VMDK-Files noch abwarten, bevor ich continuum um weitere Hilfe bitte.
Zum Storage: Es sind sechs 600GB SAS-Platten die an einem LSI-Controller hängen und als RAID 5 konfiguriert sind. In den letzten 12 Monaten habe ich ähnliches Theater mit zwei weiteren Servern gehabt, in denen LSI-Controller verbaut sind. Die beiden anderen waren keine VMware-Server. In einem Fall war das Dateisystem (Ext3) nach einem Rebuild teilweise defekt, im anderen (NTFS) hat der Rebuild überhaupt nicht funktioniert. Mit Adaptec-Controllern ist mir sowas in 20 Jahren noch nie passiert.
Was das Backup angeht: Ich sichere wirklich wichtige Infrastruktur-VMs mit den entsprechenden Agents über BackupExec. Für alles andere habe ich keine Speicherkapazitäten und werde sie auch nicht bekommen.

Edith merkt noch an, dass die abgerauchte VM natürlich auch wichtig war, aber "nur" für eine Handvoll Personen, nicht für das ganze Unternehmen.
Der Server, auf dem sie lief, stand ohnehin zur Aussonderung an. Blödes Timing

[~thc]

In den letzten 12 Monaten habe ich ähnliches Theater mit zwei weiteren Servern gehabt, in denen LSI-Controller verbaut sind. Die beiden anderen waren keine VMware-Server. In einem Fall war das Dateisystem (Ext3) nach einem Rebuild teilweise defekt, im anderen (NTFS) hat der Rebuild überhaupt nicht funktioniert. Mit Adaptec-Controllern ist mir sowas in 20 Jahren noch nie passiert

Deine Informationen sind zu oberflächlich, um LSI hier an den Pranger zu stellen. Wenn beim Rebuild eine zweite Platte Schwierigkeiten macht, kann kein Controller der Welt das RAID5-Volume retten. Wenn andererseits die Platten glücklicherweise bei jedem Rebuild mitspielen, sieht jeder Controller hinterher gut aus.

[Guy Inkognito]

Deine Informationen sind zu oberflächlich, um LSI hier an den Pranger zu stellen. Wenn beim Rebuild eine zweite Platte Schwierigkeiten macht, kann kein Controller der Welt das RAID5-Volume retten. Wenn andererseits die Platten glücklicherweise bei jedem Rebuild mitspielen, sieht jeder Controller hinterher gut aus.

- In einem Fall war es ein RAID 6 mit einer ausgefallenen Platte
- In diesem Fall ist überhaupt keine Platte ausgefallen. Es gibt einfah I/O Errors. Das darf niht passieren.

[~thc]

O.K. - da gebe ich dir Recht - das war aus deinem Beitrag davor so nicht herauszulesen.