Fehler beim booten einer Virtuellen Maschine - Mac, Fusion5

[ah1975]

Hallo zusammen,

ich habe bei einer VM an einem MacBookPro (10.8.4., auch vorher schon) immer eine Fehlermeldung. Und zwar erst nach dem einloggen ins WindowsSystem.
Ich starte die Maschine, logge mich ein und dann bleibt erstmal der Desktop ohne Icon und dann erscheint die Fehlermeldung, das der Vorgang für die Datei ....flat.vmdk fehlgeschlagen ist.
Klicke ich weiter, dann erscheint umgehend mein Desktop und ich kann arbeiten.
Aber der Fehler nervt, weil es immer eine gefühlte Ewigkeit dauert bis die Meldung erscheint.

Was kann das sein und wie kann ich es lösen?

Vielen Dank


Gruß
Alex

[Dayworker]

Es gibt hier mehrere Möglichkeiten. Entweder läuft die VM mit aktivem Snapshot oder du nutzt eine vDISK im Format Thin/Sparse und diese hat sich im Laufe der Zeit stark auf dem Host-Laufwerk fragmentiert.
Da Snapshots kein Backup sind, löscht man diese daher immer zeitnah. Das regelmäßige Shrinken bei Thin/Sparse-VMDKs brauchst du in Fusion im Gegensatz zu Workstation/Player nicht mehr manuell machen, das erledigt Fusion inzwischen selbst. Anders siehts dagegen aus, wenn die VMDK fragmentiert ist.

Verlinke mal bitte das "vmware.log" aus dem VM-Ordner auf einen Freehoster und dann finden wir auch noch die Ursache für die Fehlermeldung.

[ah1975]

Danke schon mal für die ausführliche Antwort.
Ich lasse jetzt mal ne Dfragmentierung laufen.

Hier noch die Links zu den Logfiles:

https://www.dropbox.com/s/n8fmn0sk55x87zt/vmware-0.log

https://www.dropbox.com/s/91re95671q5t5bh/vmware-1.log

https://www.dropbox.com/s/9mk7x0f6za0gurd/vmware-2.log

https://www.dropbox.com/s/q7hjtrvd1ou1nb1/vmware.log

[continuum]

Wo liegt die vmdk ? - irgendwo im Netzwerk ?

Versuch von der VM so wie sie jetzt ist ein vollen Clone zu erstellen - wenn das klappt werf das Original weg

[Dayworker]

Ich lasse jetzt mal ne Dfragmentierung laufen.

Von Defragmentierung im Gast war nicht die Rede und ist mit aktivem Auto-Protect-Snapshot auch nicht empfehlenswert.

Ich hab jetzt nicht alle Logs durchgesehen, aber hattest du irgendwann mal Platzprobleme auf dem Host?
Falls ja, ist anscheinend die VMDK mangels freien Platz auf dem Host beschädigt worden. Wie continuum bereits sagte, mach einen Fullclone davon.

[ah1975]

Danke für die Antworten.
Das mit dem Platz könnte sehr gut gewesen sein, hat aber sehr wahrscheinlich ein ehemaliger Kollege gelöst.
Hab schon versucht nach dem Update auf die neueste Version von Fusion versucht die Maschine zu importieren, aber die VM bleibt ausgegraut und nicht auswählbar.
Gibt es eine andere Variante die VM zu klonen?

[Dayworker]

Kann es sein, daß bei laufender VM einfach mal den Mac-Deckel geschlossen und der Mac somit in den Ruhezustand versetzt wurde?
Selbst im ältesten Log (vmware-2.log) existiert das Problem bereits, aber eine 195GB vDISK im Format Monolithic-Sparse zeugt schon von einigem Mut in unbekannte Materie. Das Fusion-Update war auch wenig hilfreich, die neue Version scheint die VM aufgrund der vDISK-Probleme überhaupt nicht mehr amzufassen und es ist auch fraglich, ob ein Downgrade daran etwas ändern würde.

Sieh mal im Fusion-Ordner nach, ob du da das Hilfsmittel "vmware-vdiskmanager" findest und sicher dann erstmal einer Kopie des gesamten VM-Ordners an einen anderen Ort. Für die Reparatur und erst recht für den Fullclone brauchst du mindestens 195GB freien Platz und es müssen auch alle Snapshots, erkennbar am 000000 bis 999999 im vmdk-Namen vorhanden sein. Die Syntax ergibt sich im Normalfall bei Tool-Start im Terminal/CMD/ba$h. Ausgehend vom aktuellsten Log (vmware.log) sollte "winxp-000003.vmdk" den aktuellsten Datenbestand enthalten. Die Kurzform zur Reparatur wäre damit:

Code: Alles auswählen

vmware-vdiskmanager -R /Users/nb39/Documents/Virtuelle Maschinen/MacLH_neu.vmwarevm/winxp-000003.vmdk

Selbst wenn die Reparatur erfolgreich verläuft, mach dann trotzdem den Fullclone zur Sicherheit. Die Laufwerkspfade mußt du dann selbst anpassen, aber die Syntax für den Clone lautet:

Code: Alles auswählen

vmware-vdiskmanager -r winxp-000003.vmdk -t 0 neue.vmdk

Dein Kollege hat überhaupt nichts gelöst. Die Lösung hätte schon bei der ersten Problemmeldung in einer Reparatur der vDISK bestanden und durch die Snapshots wurde die Situation eher noch schlimmer. Snapshots waren, sind und werden nie ein Backup sein.