The file specified is not a virtual disk.

[SR117]

Hi Leute

Als ich meine VM (host Windows 7 64-bit / VM Kubuntu 64-bit) gestern Mittag unbeaufsichtigt gelassen habe ist diese gecrashed.
Grund war nicht schwer zu finden:
Aus einem mir nicht ganz nachvollziehbaren Grund ist die SSD zugemüllt worden - als ich dann die VMWare geschlossen habe um die Temp-Ordner zu leeren bzw. den verbleib der 60GB näher zu untersuchen, gabs noch nen netten Bluescreen (Win7 läuft ebenfalls auf selbiger SSD) und erstmal Schicht im Schacht.

Nach dem Neustart habe ich den Temp-Ordner dann geleert und war 60GB reicher, jedoch ist die VM seitdem nicht mehr startbar.
Fehler: The file specified is not a virtual disk.

Die altbewerte Ursachen-/Lösungssuche via google brachte mir zwar schnell Gewissheit das das Platzproblem den Crash ausgelöst hat, aber eine funktionierende Lösung konnte ich bisjetzt nicht entdecken.

In der VM liegen jetzt keine lebenswichtigen Sachen - der Verlust der darin gespeicherten Daten wäre blöd aber auch keinen riesigen Rettungsaufwand wehrt. Frage an die Profis wäre somit: kann man hier auf einfachem Wege noch etwas retten?

vmware.log lade ich als Anhang hoch

Reparatur mit vmware-vdiskmanager ergab bei keiner .vmdk Besserung (wobei auffiel das die aktuellste 0KB hat - evt. wegen dem Crash?)

Rücksprung zu einem früheren Snapshot mit gleicher Fehlermeldung nicht möglich.

Gruß Ben

[JustMe]

Deine Analyse duerfte soweit korrekt sein. Am 18.2. um 13:05 Uhr war die Platte C: mit dem VM-Verzeichnis drauf voll.
Allerdings wurde die VM am 2.2. um 16:58 offenbar auch schon auf einer Snapshot-Datei gestartet, und wurde seither nur in Suspends geschickt, und nicht sauber heruntergefahren...

Egal, ohne ein Dateilisting (dir /a /ogn /r) aus dem Verzeichnis "C:\VMWare\Kubuntu 64-bit\" kommen wir nicht weiter.

Wenn die Datei "Kubuntu 64-bit-000002.vmdk" jetzt 0 Bytes Groesse hat, ist zumindest alles seit dem 2.2. wech...

Voraussetzend, dass auch eine Kubuntu 64-bit-000001.vmdk und eine Kubuntu 64-bit.vmdk existieren, kannst Du die ja nacheinander manuell mal in die Kubuntu 64-bit.vmx statt der Kubuntu 64-bit-000002.vmdk eintragen. Aber mach' vorher besser eine Sicherheitskopie vom kompletten Verzeichnis, dann hat man zumindest noch den aktuellen Stand fuer weitere Versuche.

[SR117]

Danke für die schnelle Antwort JustMe

Also eine Sicherheitskopie habe ich bereits auf meiner HDD gespeichert.
Das die VM seit längerem nicht runtergefahren wurde ist gut möglich, da ich dazu neige sie zu pausieren

Wenn man den letzten Snapshot zum booten bringen könnte wäre das nicht schlecht, dann ist wenigstens nicht alles weg - das letzte Backup dürfte letzten November gewesen sein
Reicht es in der .vmx aus die Zeile

Code: Alles auswählen

scsi0:0.fileName = "Kubuntu 64-bit-000002.vmdk"

umzuschreiben?

Code: Alles auswählen

C:\VMWare\Kubuntu 64-bit>dir /a /ogn /r
 Volume in Laufwerk C: hat keine Bezeichnung.
 Volumeseriennummer: A0F0-14D7

 Verzeichnis von C:\VMWare\Kubuntu 64-bit

18.02.2017  17:29    <DIR>          .
18.02.2017  17:29    <DIR>          ..
02.02.2017  16:58    <DIR>          Kubuntu 64-bit.vmdk.lck
02.02.2017  16:58    <DIR>          Kubuntu 64-bit-000001.vmdk.lck
02.02.2017  16:58    <DIR>          Kubuntu 64-bit-000002.vmdk.lck
02.02.2017  16:58    <DIR>          Kubuntu 64-bit-ddb096d0.vmem.lck
18.02.2017  15:53             8.684 Kubuntu 64-bit.nvram
01.01.2017  23:05    94.210.097.152 Kubuntu 64-bit.vmdk
24.01.2017  18:34               809 Kubuntu 64-bit.vmsd
18.02.2017  16:08             3.199 Kubuntu 64-bit.vmx
22.01.2017  21:50               376 Kubuntu 64-bit.vmxf
24.01.2017  18:34    23.459.790.848 Kubuntu 64-bit-000001.vmdk
18.02.2017  15:53                 0 Kubuntu 64-bit-000002.vmdk
28.01.2017  12:10     4.294.967.296 Kubuntu 64-bit-ddb096d0.vmem
01.01.2017  23:29            28.694 Kubuntu 64-bit-Snapshot1.vmsn
24.01.2017  18:37     4.294.967.296 Kubuntu 64-bit-Snapshot2.vmem
24.01.2017  18:37         6.358.882 Kubuntu 64-bit-Snapshot2.vmsn
18.02.2017  15:53         1.047.270 vmware.log
01.02.2017  22:35           433.257 vmware-0.log
28.01.2017  12:02           383.846 vmware-1.log
24.01.2017  21:08         2.177.052 vmware-2.log
18.10.2016  14:50                 0 vmware-vmx.dmp
04.10.2016  22:34             2.245 vprintproxy.log
04.10.2016  19:05             2.245 vprintproxy-0.log
02.10.2016  11:25             2.243 vprintproxy-1.log
01.10.2016  20:57             2.243 vprintproxy-2.log
              20 Datei(en), 126.270.273.637 Bytes
               6 Verzeichnis(se), 65.579.937.792 Bytes frei

Gruß Ben

[JustMe]

Reicht es in der .vmx aus die Zeile
umzuschreiben?

Genau. Einfach -000002 aendern nach -000001.

Evtl muessen noch die .lck-Verzeichnisse geloescht werden, weil die VM abgestuerzt war.

Auch hier der schon so oft genannte Hinweis: Snapshots sind KEIN Backup (noch dazu, wenn sie im laufenden Betrieb erzeugt werden. Tststs...), und sollten so schnell wie moeglich wieder entfernt werden. Der -000001er hatte auch schon gut 20G angesammelt, bevor in den -000002er weitergeschrieben wurde.

Da ja wie erwaehnt der Snapshot im laufenden Betrieb erstellt wurde, bedeutet das fuer das startende Gast-OS selbstverstaendlich einen Neustart nach Absturz. Zu diesem Snapshot "zurueckzukehren" wird vmtl. nicht klappen.

Abschliessend kannst Du bei ausgeschalteter VM die .vmsd loeschen, dann einen neuen Snapshot anlegen, und gleich darauf "Alle loeschen". Damit wird auch die -000001 wieder in die Basis-vmdk eingearbeitet. Danach noch die restlichen -000002-Datei entfernen.

[SR117]

Also das ein Snapshot kein Backup ist ist mir bekannt - ich meinte mit Backup einen wirklichen Save der gesammten VM

Habe die .vmx jetzt umgeschrieben auf -000001 und bekomme beim Drücken auf Start:

Unable to open file "D:\Kubuntu 64-bit\Kubuntu 64-bit-000001.vmdk":
One of the disks in this virtual machine is already in use by a virtual machine or by a snapshot.

Gehe ich jetzt recht in der Annahme das ich alle überbleibsel der -000002 entfernen muss - sprich alle Dateien im Ordner Kubuntu 64-bit mit der Zahl 2?

Gruß Ben

[JustMe]

Das hatte ich schon so verstanden
Meine Anspielung ging dahin, dass die beiden Snapshots -000001 und -000002 schon so alt sind (=so lange schon vorhanden sind).

Du kannst die 2er Dateien auch loeschen, aber ich vermute eher, dass die .vmsd, in der der Snapshot 2 ja noch verzeichnet ist, hier Probleme bereitet. Du hast doch die .lck-Verzeichnisse bereits geloescht, oder?

Wenn alle Stricke reissen, dann erstellst Du einfach eine neue VM (gleicher Name, gleiches Verzeichnis, ...), kopierst in deren Verzeichnis die beiden vmdk-Dateien, und passt die neue .vmx entsprechend an. Die Verzeigerung aus der -000001 in die Basis-Datei ist dabei transparent.

[SR117]

Da du .lck-Verzeichnisse schreibst gehe ich mal davon aus diese Ordner müssen alle weg und nicht nur der 000002-er?

Die vmsd könnte ich ja denke ich umschreiben, indem ich den Speicherbereich

Code: Alles auswählen

snapshot1.filename = "Kubuntu 64-bit-Snapshot2.vmsn"
snapshot1.parent = "1"
snapshot1.displayName = "24-01-2017"
snapshot1.type = "1"
snapshot1.createTimeHigh = "345818"
snapshot1.createTimeLow = "-2037581424"
snapshot1.numDisks = "1"
snapshot1.disk0.fileName = "Kubuntu 64-bit-000001.vmdk"
snapshot1.disk0.node = "scsi0:0"
snapshot.mru1.uid = "1"

entferne und den Eintrag lastUID und current von "2" auf "1" abändere.

Gruß Ben

[JustMe]

Kannst Du versuchen; Vorteil ist ja, dass alle Dateien von SSD auf Platte gesichert sind.
Wenn Du Glueck hast, kannst Du damit sauber zu der laufenden VM am 24.1. zurueckkehren.

Aufpassen musst Du nur, weil offenbar nicht alle Nummern konsistent sind, soll heissen, dass nicht unbedingt alles mit einer "1" drin zusammengehoert. Wenn also irgendwas nicht ganz klappt, einfach die Dateien wieder zurueckkopieren, und nochmal versuchen.

[SR117]

Wunderbar - hat geklappt!

Vielen Dank an dich JustMe für deine Hilfe

Abschliessend kannst Du bei ausgeschalteter VM die .vmsd loeschen, dann einen neuen Snapshot anlegen, und gleich darauf "Alle loeschen". Damit wird auch die -000001 wieder in die Basis-vmdk eingearbeitet. Danach noch die restlichen -000002-Datei entfernen.

Das werde ich dann heute Abend noch umsetzten und zukünftig mal vermehrt Backups einplanen

Gruß Ben