VMDK-Probleme

[Mark_Le]

Hallo Leute,

nach Ausschalten und neu Einschalten von 5 Vms funktionieren 2 nicht mehr.
Im Datastore wird mir bei der einen nur noch eine .vmdk angezeigrt und bei der anderen alle Daten , aber teilweise mit flat.vmdk.

Fehlermeldung ist: Es sss.vmdk oder eine der Snapshotfestplatten konnten nicht geöffnet werden bzw. die angegebene Datei ist keine virtuelle Festplatte.

Seltsamerweise kam das Problem einfach so bei den Maschinen.

Vielleicht kann mir jemand helfen.




Titel durch Moderator gesetzt

[JustMe]

Standard-Antwort auf das immer wiederkehrende Problem:

- Datastore-Browser ist vollkommen nutzlos fuer diese Zwecke/Probleme
- Auf der ESXi-Kommandozeile (oder z.B. mit putty/ssh) in den Verzeichnissen der VM/VMs die Ausgabe von

Code: Alles auswählen

ls -la
grep -i vmdk *.vmx

einfangen, dann noch das jeweils aktuelle vmware.log (und wenn's geht auch die .vmx) aus dem VM-Verzeichnis packen und auf Freehoster hochladen. Link dann hier posten. NICHT DIE LOGDATEI HIER POSTEN!!! (Sorry, ich schreie sonst nicht, und meine Tastatur hat auch keinen Klemmer auf dem Ausrufezeichen)

Dann sehen wir weiter...

[Mark_Le]

http://file-manager.hostinger.de/6/inde ... NHNA%3D%3D

Files VM

Vielen Dank schon mal

[JustMe]

Gerne doch...

Fuer die VM Win7_Opti_Mark findet sich die vmdk auf demselben Datastore, aber in einem anderen Verzeichnis: Win7_Opti_Mark_KopieW10

Ich nehme mal an, dass dort aber dasselbe Problem besteht wie fuer die drei Platten der VM lucas:

Die Descriptor-Dateien fuer die -flat.vmdk fehlen.

Die kann man wiederherstellen: Recreating a missing virtual machine disk descriptor file (inkl. Video).

Was merkwuerdig erscheint ist jedoch, dass im lucas-Verzeichnis eine Datei namens "lucas-flat.vmsd" besteht, und die lucas.vmdk (normalerweise der Name der Deskriptor-Datei) die Groesse einer -flat.vmdk aufweist. Eine .vmsd ist normalerweise die Snapshot-Deskriptor-Datei (es gibt ja auch noch eine lucas.vmsd), und beide sind eh' nur 0 Bytes gross...

Da ist also irgendwas im VMFS nicht ganz sauber...
... vorausgesetzt, dass der Fehler nicht beim Output-Kopieren entstanden ist. Oder hat vielleicht irgendjemand/irgendwas munter versucht, Dateien umzubenennen?

Wenn Du trotzdem irgendwas probieren willst, solltest Du die GROSSEN Dateien per cp auf einen anderen Datastore kopieren, und dort die Descriptoren erstellen. Die lucas.vmdk kann dann auch gleich nach lucas-flat.vmdk umbenannt werden. Zur Sicherheit kannst Du mit einem hexdump -C -n 512 <Dateiname> mal den Anfang anschauen, dass es tatsaechlich eigentlich eine -flat-Datei sein sollte.

Um mit dem VMFS auf saubere Fuesse zu kommen, waere evtl. "continuum" hier aus dem Forum hilfreich.

Ich hoffe, das bringt Dich erst einmal ein Stueckchen weiter...

[continuum]

Kann es sein, dass bei der 2ten VM jemand flat.vmdk-Dateien ubenannt hat ?
Die 2te VM scheint ja noch halbwegs komplett zu sein - von den Beschreibungs-vmdks mal abgesehen (die lassen sich aber problemlos neu erstellen.
Die 1te VM sieht nicht gut aus - wenn dir die VM wichtig ist - ruf mal an - am besten per skype.

[Mark_Le]

Vielen Dank für die schnellen Antworten, und ja es könnte sein das zum Test die Datei umbenannt wurde. Wieso kommt es überhaupt zu solchen Fehlern auf dem Esxi Host?

[JustMe]

Ursache sind allgemein Zugriffsprobleme auf die Datentraeger; meist Hardware, eher selten Software.

PS:
Bei solchen "Tests" sollte man
- genau wissen was man tut, und was es fuer Auswirkungen und Zusammenhaenge hat
- JEDEN einzelnen Schritt peinlich genau dokumentieren
- ein erwiesenermassen funktionierendes Backup in der Hinterhand haben
- und zuletzt diese Schritte beim Posten gleich mit erwaehnen

[Mark_Le]

Ob es wirklich ein Test war, das bekomme ich erst am Montag raus, wenn ich die Kollegen befrage. Trotzalledem werde ich morgen versuchen , nach den geschickten link mit Video die Dateien wieder herzustellen. Ihr meint also, dass es bei der vm Lucas problemlos funktionieren sollte und bei der anderen vm es keine Hoffnung mehr gibt?

[Dayworker]

Tu dir selbst den Gefallen, nimm das Angebot von "continuum" an und nimm Kontakt mit ihm auf. Wenn er es nicht hinbekommt, brauchst du den VMware-Support nicht mehr probieren, der gibt vorher auf...

[JustMe]

@Mark_Le:
Wenn Du das aus meinem Posting herausliest, dann kann ich Dayworker's Rat nur unterstreichen...

Nur, weil eine vmdk in einem anderen Verzeichnis als dem "Home"-Verzeichnis der VM liegt, bedeutet das selbstverstaendlich NICHT, dass die VMDK (oder die VM) kaputt waere. Schliesslich hat's ja wer weiss wie lange gut so funktioniert. Wie lange, laesst sich leider so nicht ohne Weiteres mutmassen, weil saemtliche vmware-*.log vom 3.11. sind.
Aber es wird schon seinen Grund haben, dass jemand eine Kopie der VM angelegt, und (aus Konfigurationssicht korrekt) auf die dortige VMDK verwiesen hat.

Die Frage ist halt:
Was befindet sich tatsaechlich alles in dem Verzeichnis Win7_Opti_Mark_KopieW10?
Und vielleicht, falls es sich ermitteln laesst: WER hat WANN WIE das Verzeichnis Win7_Opti_Mark_KopieW10 angelegt und befuellt?

Mal einfach so in's Blaue gemutmasst (oder versucht, die Schlieren der Glaskugel zu deuten): Traten die Probleme evtl. beim Kopieren dieser VM auf, weil dabei der Datastore voll lief?

[Mark_Le]

Nun ja, die vm win7 opti.... habe ich damals aus einer anderen vm erstellt. Insgesamt lief die vm bis Freitag, genauso wie webas640. Ich fuhr die Maschinen am Freitag herunter und habe den RAM vom Host erhöht. Km Anschluss fuhr ich die Systeme wieder hoch und diese beiden Systemen starteten nicht .
Die Dateien scheinen ja noch alle da zu sein, sehr seltsam.

[Dayworker]

Ohne mir die Verlinkung angesehen zu haben, sei gesagt, daß der ESXi beispielsweise beim Löschen von Dateien einen Lock drauf hat und das Ansinnen mit einer Fehlermeldung verhindert. Solange die VM läuft, bleibt das auch so. Sobald jedoch die VM heruntergefahren wird, ist der Lock weg und die Datei ist gelöscht. Im Prinzip sehe ich da beim Umbennen oder Verschiebenen keinen Unterschied. Sobald der Lock weg ist, wird der letzte anstehende Befehl ausgeführt.


Wie bereits von anderen gesagt, laß die Finger vom Datastore-Browser. Dieser liefert bekanntermaßen nur eine interpretierte Ansicht des Dateisystems und es gilt weiterhin, daß sobald die Ansicht im DS-Browser und einer WinSCP-Verbindung übereinstimmen, man ein gewaltiges Problem hat. Je nach Wissensstand zur Thematik "ESXi mit VMFS" empfehle ich dann den umgehenden Kontakt entweder hier oder direkt bei "continuum". Seine Kontaktmöglichkeiten stehen in seiner Signatur unter jedem seiner Posts.

[Mark_Le]

So Leute, ich habe mich mal etwas in die Sache rein gefuchst und habe die 2 Vms mit insgesamt 4 vmdks wieder zum laufen gebracht.
Die Description Dateien waren kaputt und ich habe diese mittels Recreating a missing virtual machine disk descriptor file (1002511) wieder zum laufen gebracht.

Besten Dank nochmal für den Tipp