The file specified is not a virtual disk - Fehler auf Hauptmashcine und Snapshots

[LexLusa]

Hallo zusammen,

seit zwei Tagen sitze ich an diesem Problem und habe alle Foren und Google und die KB durch und komme nicht weiter.

Meine VM ist ohne Grund abgestürzt und lässt sich nicht mehr starten.
Egal ob die Hauptmaschine, oder die Snapshots (Tägliche Snaps 14-Tage back).
Immer kommt die Fehlermeldung: "The file specified is not a virtual disk".

Folgende Dinge habe ich schon versucht:
- Gecheckt ob die vmx die falsche vmdk mapped - nein.
- Die *.LCK Ordner und Dateien entfernt.
- Versucht eine neue VM von der letzten vmdk zu machen (Fehler: "Parent of this virtual disk could not be opened")

All dies half nicht.

Hat noch jemand eine Idee?
Was könnte ich euch zeigen, damit ihr mir noch helfen könntet?
(Logs, Screens?)

Vielen Dank!

[JustMe]

Das, was bei immer wieder denselben Problemmeldungen auch immer wieder benötigt wird:

- detailliertere Beschreibung der bisherigen Versuche ("letzte vmdk" ist leider nicht eindeutig...)
- vmware*logs aus dem Verzeichnis der VM
- Dateilisting aus dem Verzeichnis der VM (auf der Eingabeaufforderung, "dir /ogn /r /a")
- die Erkenntnis "SNAPSHOTS SIND KEINE BACKUPS". Auch nicht (oder eigentlich gerade), wenn sie täglich angelegt und über 14 Tage behalten werden.
- weitere Dateien (oder binäre Dateianfänge), wenn die ersten Daten ausgewertet sind.

Ob ueberhaupt noch was zu retten ist, nachdem Du offenbar versucht hast, alles moegliche irgendwie zu starten oder einzubinden, muss man dann mal schauen.

[LexLusa]

Hey JustMe, danke für die detaillierte Auflistung.

Detaillierte Beschreibung der bisherigen Versuche:

Nachdem die Fehlermeldung das erste mal auftrat, habe ich:

Versucht aus dem Snapshot von der letzten Nacht vor dem Crash die VM wiederherzustellen - Selber Fehler
Die *.LCK Ordner und Dateien entfernt (Kopiert in einen anderen Ordner)
Versucht eine neue VM von der letzten vmdk (WinterHeld-000025.vmdk - das ist der aktuelle State) zu machen (Fehler: "Parent of this virtual disk could not be opened").

vmware*logs aus dem Verzeichnis der VM
Siehe hier: https://we.tl/LGZHITCRPI


Dateilisting aus dem Verzeichnis der VM (auf der Eingabeaufforderung, "dir /ogn /r /a")
Siehe hier: http://pastebin.com/HnTdP5pE


Die Erkenntnis "SNAPSHOTS SIND KEINE BACKUPS". Auch nicht (oder eigentlich gerade), wenn sie täglich angelegt und über 14 Tage behalten werden.
- Hab ich verstanden.

Vielen Dank für deine Antwort.

[JustMe]

Ach Du Heimatland...
792 vmdk-Dateien im Listing, und jeder (erfolglose) VM-Start bringt bereits knapp 400kB an Logdaten. Und dann gibt's auch noch 2 (i.W. ZWEI) .vmx-Dateien im Verzeichnis.

Versuche doch mal, die Logs zu zippen, und direkt hier hochzuladen. WEtransfer moechte mir vor dem Zugriff unbedingt seine Nutzungsbedingen und Cookie-Richtlinien unterjubeln.

Scheint wohl auch keine unwichtige VM zu sein. Jeder Snapshot (selbstverstaendlich im laufenden Betrieb; irgendwas wie Self-Protect [auch schon mal als Self-Destruct bezeichnet]?) legt auch gleich noch gut 12GB Hauptspeicherinhalt der VM mit ab...

Wenn's nix offensichtliches sein sollte, wird vmtl. doch continuum noetig sein. Sorry.

[LexLusa]

Hey,
danke, dass du dir die Zeit nimmst, mir zu helfen.
Ich habe die logs mal gezippt und als Anhang reingepackt.

[Supi]

Nun ich lese im Log was von :

C:\VMs\WinterHeld-000021.vmdk" : failed to open (The specified virtual disk needs repair).

Datensicherung des VM verzeichnisses und dann mal nen Repair starten?
https://kb.vmware.com/selfservice/micro ... Id=2019259

http://blog.myswnet.de/?p=76

Wobei das Problem ja ggf. dadurch kommt laut log:

[msg.vmxaiomgr.retryabort.diskfull] The operation on the file "C:\VMs\WinterHeld-000021-s001.vmdk" failed (Unknown error 112 (0x70)).
The file system where disk "C:\VMs\WinterHeld-000021-s001.vmdk" resides is full.
[msg.vmxaiomgr.corrupted] VMware Workstation cannot synchronize with the disk before canceling. Disk C:\VMs\WinterHeld-000021-s001.vmdk may be inconsistent.
PANIC: User requested abort: Exiting because of failed disk operation.

[JustMe]

Jepp, im vmware.log ist es die C:\VMs\WinterHeld-000021-s001.vmdk, im vmware-0.log die "C:\VMs\WinterHeld-000021-s006.vmdk", und im vmware-1.log die "C:\VMs\WinterHeld-000021-s007.vmdk"

Das sieht so aus, als waere Dein C: Laufwerk voll.

Wie schon geschrieben: Die vielen Snapshots im laufenden Betrieb (auch wg. der jeweils 13GB Memory) pusten doch einiges auf die Platte.

Aber eigentlich solltest Du doch auch von Windows Alarme erhalten, wenn die VM auf dem C: liegt...

[LexLusa]

Nun ich lese im Log was von :

C:\VMs\WinterHeld-000021.vmdk" : failed to open (The specified virtual disk needs repair).

Datensicherung des VM verzeichnisses und dann mal nen Repair starten?
https://kb.vmware.com/selfservice/micro ... Id=2019259

http://blog.myswnet.de/?p=76

Wobei das Problem ja ggf. dadurch kommt laut log:

[msg.vmxaiomgr.retryabort.diskfull] The operation on the file "C:\VMs\WinterHeld-000021-s001.vmdk" failed (Unknown error 112 (0x70)).
The file system where disk "C:\VMs\WinterHeld-000021-s001.vmdk" resides is full.
[msg.vmxaiomgr.corrupted] VMware Workstation cannot synchronize with the disk before canceling. Disk C:\VMs\WinterHeld-000021-s001.vmdk may be inconsistent.
PANIC: User requested abort: Exiting because of failed disk operation.

Hey, danke für dein Antwork - super, wie einem hier geholfen wird!
Nach Backup, habe ich den repair laufen lassen und dann kam tatsächlich folgendes:
The virtual disk, 'C:\VMs\WinterHeld-000021.vmdk', was corrupted and has been successfully repaired.

Leider besteht das Problem immer noch.

Das Laufwerk auf dem sich die VM befindet ist nichtmal zu 30% voll - daher verstehe ich die Fehlermeldung nicht.

Danke und Viele Grüße,
LL

[Dayworker]

Jep. Auto-Protect nennen wir Auto-Destruct. VMware hatte das aber etwas handzahmer gemacht und eigentlich sollte sich diese Funktionalität abschalten, falls der Platz nicht mehr ausreicht. Keine Ahnung was ihr da für Anforderungen habt, aber tägliche Snaps mit 14 Tage Rückkehrzeit nenn ich extrem sportlich und da sind Probleme im Grunde schon vorprogrammiert. Die sich dadurch ergebenden 14 Tage x 12GB vRAM = 168GB an vmem-Dateien sind für heute übliche Datenträgergrössen nicht sonderlich viel, füllen aber neben den Daten recht zügig jeden Datenträger, falls die vDISK auch noch vom Typ Thin bzw Sparse also mitwachsend angelegt wurde. Dann reicht bereits ein Defrag-Lauf oder eine vollständigen Formatierung in der VM aus, um die vDISK auf eure maximal spezifierte vDISK-Grösse von 750GB aufzublasen. Hat man dann kein gescheites Logging des freien Platzes, endet sowas im Grunde immer in kapitalen Datenverlusten und startunwilligen VMs bzw Rechnern.

Nimm am besten direkt Kontakt mit unserem Ulli aka "continuum" auf, er hat seine Mobilenummer und Skype unter jedem seiner Postings stehen. Falls er nichts retten kann, brauchst du auf VMware nicht zählen, die geben wesentlich früher auf und verweisen gleich auf das Backup.


[edit]
Jedes Dateisystem hat seine Grenzen. Auch leere Dateien belegen je nach Dateisystem reichlich Speicherplatz. Hast du bei der NTFS-Partitionserstellung den Standard beibehalten, beträgt die Sektorgrösse ab einer gewissen Plattengrösse volle 64KB. Selbst wenn Dateien nur Null Byte gross sind, belegen diese dann trotzdem die vollen 64KB im Dateisystem und das für jede Datei.

[LexLusa]

Nimm am besten direkt Kontakt mit unserem Ulli aka "continuum" auf, er hat seine Mobilenummer und Skype unter jedem seiner Postings stehen. Falls er nichts retten kann, brauchst du auf VMware nicht zählen, die geben wesentlich früher auf und verweisen gleich auf das Backup.

Super, das werde ich sofort mal tun.
Danke dir!

[JustMe]

30%? Dann muss das C: mindestens 2TB gross sein...
Alleine die Dateien der dir-Ausgabe summieren sich auf 747.272.258.280 Bytes. Und dann kommt ja auch noch Windows und ggfs. weitere Sachen dazu.

Das andere Problem ist, dass in den Log-Dateien nix zur urspruenglichen Meldung "The file specified is not a virtual disk" zu finden ist.
Da wird die VM normal gestartet, die Disks geoeffnet, und dann zugegebenermassen recht kurz gearbeitet, bis die "Disk full" Meldungen beim Arbeiten erscheinen.

Hast Du das Verzeichnis "VMs" evtl. von irgendwo nach c:\ eingehaengt? Zeig' doch mal ein "dir /ogn /a /r" vom c:\.

[Supi]

Nach Backup, habe ich den repair laufen lassen und dann kam tatsächlich folgendes:
The virtual disk, 'C:\VMs\WinterHeld-000021.vmdk', was corrupted and has been successfully repaired.

Leider besteht das Problem immer noch.

Und wenn du nach dem Repair im Vmware auf einen Snap zuvor springst bzw. das mal versuchst?

[LexLusa]

Das andere Problem ist, dass in den Log-Dateien nix zur urspruenglichen Meldung "The file specified is not a virtual disk" zu finden ist.
Da wird die VM normal gestartet, die Disks geoeffnet, und dann zugegebenermassen recht kurz gearbeitet, bis die "Disk full" Meldungen beim Arbeiten erscheinen.
Ja, das verstehe ich auch nicht.

Hast Du das Verzeichnis "VMs" evtl. von irgendwo nach c:\ eingehaengt? Zeig' doch mal ein "dir /ogn /a /r" vom c:\
Die habe ich hier: http://pastebin.com/1bx5hdEn

Und wenn du nach dem Repair im Vmware auf einen Snap zuvor springst bzw. das mal versuchst?
Selbe Fehlermeldung "The file specified is not a virtual disk"

[continuum]

Seit eben läuft die VM wieder - die Anzahl an Snapshots die wir dabei komplett verwerfen müssen lässt sich aber noch nicht abschätzen.
Der Fall ansich zeigt mal wieder, dass der Name "AutoDestruct" für dass Autoprotect-feature die passendere Wahl ist

[LexLusa]

So, hier nochmal zum Abschluss des Ganzen:

1. Bless @continuum!
Ohne ihn wäre nichts mehr lauffähig gewesen und alle Daten wären definitiv im Orkus gelandet.
Ich hoffe zwar, dass ich sowas nie wieder machen muss, aber ich würde jederzeit zu ihm zurückkehren (Wow, das klingt vielmehr nach einem aufgezwungenen Werbetext als mir lieb ist - aber es ist einfach wahr!).
Und danke an dieses Forum für alle hilfreichen Ratschläge und die Empfehlung ihn einzuschalten.

2. Autoprotect ist echt Autodestruct! #rant

3. Nun der eigentliche Fehler: Ein Mitarbeiter der Firma hat, trotz Virenscannerwarnung eine Exceltabelle aus einem EMailanhang geöffnet und Makros aktivieren lassen. Diese hat sich dann selbst bis ins unendliche dupliziert und somit VM und Host bis zum Chrash vollgeschrieben.
Aus Panik hat er dann angefangen irgendwelche Rescueprogramme runterzuladen, auf dem Host installiert und vmdks gelöscht und den Speicher mit Nullen überschrieben.
Als dann gar nichts mehr ging, wurde ich dann angerufen.
Ganz grosses Kino.

Also nochmals: Danke Leute für eure tolle Hilfe und Ratschläge und Danke continuum für das Retten der Daten!

Viele Grüße,
LL

[Supi]

3. Nun der eigentliche Fehler: Ein Mitarbeiter der Firma hat, trotz Virenscannerwarnung eine Exceltabelle aus einem EMailanhang geöffnet und Makros aktivieren lassen. Diese hat sich dann selbst bis ins unendliche dupliziert und somit VM und Host bis zum Chrash vollgeschrieben.
Aus Panik hat er dann angefangen irgendwelche Rescueprogramme runterzuladen, auf dem Host installiert und vmdks gelöscht und den Speicher mit Nullen überschrieben.
Als dann gar nichts mehr ging, wurde ich dann angerufen.
Ganz grosses Kino.

Also nochmals: Danke Leute für eure tolle Hilfe und Ratschläge und Danke continuum für das Retten der Daten!

Viele Grüße,
LL

Also das muss ich aber schon loswerden, dass diese Infos am Anfang wohl schon bekannt waren, oder?
Da hätten sich hier viele das Raten/überlegen/Tipps geben gespart und gleich auf Continuum verwiesen. Da fühlt man sich schon ein wenig veräppelt. Sorry, aber das ist dann unfair.

[continuum]

Alles gut.
Diese Informationen haben sich erst im Laufe der Ermittlung ergeben - solche Hinweise ergeben sich ja leider oft erst nach Androhung von Folter oder Liebesentzug.

[LexLusa]

Also das muss ich aber schon loswerden, dass diese Infos am Anfang wohl schon bekannt waren, oder?
Da hätten sich hier viele das Raten/überlegen/Tipps geben gespart und gleich auf Continuum verwiesen. Da fühlt man sich schon ein wenig veräppelt. Sorry, aber das ist dann unfair.

Genau das, was continuum schon geschrieben hat:
Leider musste ich erst ganz viel gut zureden und log Daten innerhalb der VMs und Servlogs durchforsten um das rauszufinden.
Ich hätte eine solche Info natürlich nicht zurückgehalten.