VMware-Forum

Hallo, ich bin neu hier im Forum,

VMware verwende ich nur auf einem Notebook, weil ich es leid war, bei Hardware-Defekten, Gerätewechseln usw. immer wieder alles neu installieren zu müssen (also kein Server o.ä.).

SYSTEMUMGEBUNG:

Ich habe einen ASUS Pro5IJ mit 8 GB RAM und Win7-64bit
VMWare workstation 9.0.4 build-1945795
Weitere Tools von od. für WMware habe ich nicht.

Da ich sehr viele Zusatzprogramme installiert habe, und anfangs die Dateigröße immer ganz schnell aus dem Ruder lief, habe ich die Größe auf 100 GB fixiert. Das funktionierte jahrelang ganz gut. Ab und an mache ich einen Snapshot, wird die physische Platte zu klein, einen Full Clone und lösche dann auf dem Notebook die Snapshots wieder.

Leider hat auch VMware seine ganz eigenen "Defekte", die mich inzwischen schon

ich habe nun schon einige Stunden versucht, den Fehler ...

Defragmentation failed:The specified virtual disk needs repair.

... Instand zu setzen.

Als Hinweis: schon seit einigen Wochen dauerte es viele Minuten, bis die VM herunterfuhr. Dazu konnte ich nichts Googlen. Auch das rücksetzen auf einen älteren Snapshot brachte mehrfach nichts. Gestern nun war die VM auch nach 24h nicht heruntergefahren, so dass ich den Rechner zwangsweise herunterfuhr.

Grund für den Ausfall war vermutlich ein erneut defekter Akku, den ich inzwischen getauscht habe. Leider ist mein ASUS da rigeros: ist der Akku nicht mehr bei annäherend voller Kapazität, dann fährt das Gerät nicht in den Ruhezustand o.ä., sondern schaltet sich ohne herunterfahren aus, was dann zu defekten VMs führt. (Mainboard wurde 1x, Akku bereits 2x getauscht.)

Ich habe schon mehrfach versucht über den cmd code (http://kb.vmware.com/selfservice/micros ... Id=2019259) die Sache in den Griff zu bekommen:

1.) C:\Program Files (x86)\VMware\VMware Workstation

2.) vmware-vdiskmanager -R D:\VMware\Virtual Machines\VMware9\Win7-64D.vmx
oder ... .vdmk

oder Windows 7 x64D-000007.vdmk (das ist die neueste)

bekomme aber immer den Fehler: "Diskname or some other argument is missing". - Gehe ich falsch vor? Was ist die richtig Extension?

Des Weiteren hatte ich irgendwo beim Googlen gelesen, man solle VMs mit Snapshots nicht degfragmentieren - dies mache ich jedoch bis auf v.g. Absturz seit Version 7 seit Jahren ohne Schwierigkeiten mit guten Resultaten. - Sollte ich dies nicht tun?!? Wie warte ich dann aber die VM?
Hier http://vmware-forum.de/viewtopic.php?t=9473 steht was von einem vmreport, den findet aber mein CMD-Fenster ebenfalls nicht in o.g. Program Files Verzeichnis. Scheint ein externes Programm zu sein ...

Ich arbeitet zwar schon seit sehr vielen Jahren mit PCs aber bei VMware bin ich eigentlich nur Enduser, auch wenn ich das System seinerzeit jeweils selbst installiert und konfiguriert hatte..

Ich hoffe, mir kann jemand helfen!

Beste Grüße

Ich bin kein Experte, was die Workstation angeht, aber ein Paar Anmerkungen und Hinweise kann ich dir geben.

Snapshots sollten nie älter sein als 14 Tage. Punkt. Wer Snapshots länger am Leben erhält, sucht nach Spaß mit defekten VMDKs.

Defragmentierung von Disks hat unter VMWare drei Ebenen: Innerhalb der VM, In der Workstation und im Host-OS - welche meinst du denn?

Du solltest zunächst in der Log-Datei der VM nachschauen, welche der (acht?) VMDKs überhaupt betroffen ist.

Du hast ein Leerzeichen im Pfad der VMDK, also musst du diesen mit Anführungszeichen umschließen:

Ich kann dir aber nicht sagen, ob das mit aktiven Snapshots überhaupt richtig funktioniert. Wenn du dies einfach so versuchst, dann auf eigene Gefahr. Das richtige Suffix ist "vmdk".

Für eine andere VM-Umgebung habe ich gerade gelese, man solle den Inhalt des VM-Verzeichnisses per DIR zur Verfügung stellen und auch die Log files sharen. - Sie sind hier zu finden: https://dc2.safesync.com/FjHGlvb/SafeSy ... E2znG2-dIg
Passwort ist "1234"

Zunächst mal ganz herzlichen Dank für die wertvollen Tipps!

~thc hat geschrieben:Snapshots sollten nie älter sein als 14 Tage. Punkt. Wer Snapshots länger am Leben erhält, sucht nach Spaß mit defekten VMDKs.
.

Huh, das habe ich bislang ganz anders gehandhabt, kein Wunder! - Wie dann besser? - Linked Clone, wenn man den alten Stand sichern will und dahin zurückkehren können möchte, auch nach Monaten?

~thc hat geschrieben:Defragmentierung von Disks hat unter VMWare drei Ebenen: Innerhalb der VM, In der Workstation und im Host-OS - welche meinst du denn?.

Vom Host-OS rede ich nicht. Defragmentiert habe ich bislang immer nur nachdem ich die VM heruntergefahren hatte; das heist dann wohl "in der Workstation, oder?

~thc hat geschrieben:Du solltest zunächst in der Log-Datei der VM nachschauen, welche der (acht?) VMDKs überhaupt betroffen ist..

Ich habe die logs gepostet (siehe oben) - habe noch nie damit gearbeitet, welche ist es denn?

~thc hat geschrieben:
Du hast ein Leerzeichen im Pfad der VMDK, also musst du diesen mit Anführungszeichen umschließen:

Code: Alles auswählen

vmware-vdiskmanager -R "D:\VMware\Virtual Machines\VMware9\Win7-64D.vmdk"

Das lief in Millisekunden durch ohne weitere Fehlermeldung! - Mein Fehler war es v.a. keine "" zu verwenden. (Ob es funktionier hat, kann ich noch eine Weile nicht sagen - ich lösch gerade aus Platzmangel einen alten Snapshot. Poste es später.

~thc hat geschrieben:[/b]
Ich kann dir aber nicht sagen, ob das mit aktiven Snapshots überhaupt richtig funktioniert. Wenn du dies einfach so versuchst, dann auf eigene Gefahr. Das richtige Suffix ist "vmdk".

Wieso aktive Snapshots? - Die Maschine war komplett heruntergefahren.

Nochmals danke!

circulars hat geschrieben:Wie dann besser? - Linked Clone, wenn man den alten Stand sichern will und dahin zurückkehren können möchte, auch nach Monaten?

Mit Linked Clones kenne ich mich nicht aus - ich fertige komplette Cold Clones für einen solchen Zweck an.

circulars hat geschrieben:Ich habe die logs gepostet (siehe oben) - habe noch nie damit gearbeitet, welche ist es denn?

In der Freigabe ist nur eine Textdatei mit dem Listing des Programmverzeichnisses der Workstation. Ich brauche die letzte (neueste) Logdatei aus dem Verzeichnis der VM.

Aktive Snapshots = Die Snapshotkette, die bis zum im Moment aktiven Zustand der VM relevant ist, egal ob die VM läuft oder nicht.

~thc hat geschrieben:[/b]
Du hast ein Leerzeichen im Pfad der VMDK, also musst du diesen mit Anführungszeichen umschließen:

Code: Alles auswählen

vmware-vdiskmanager -R "D:\VMware\Virtual Machines\VMware9\Win7-64D.vmdk"

circulars hat geschrieben:[/b]
Das lief in Millisekunden durch ohne weitere Fehlermeldung! - Mein Fehler war es v.a. keine "" zu verwenden. (Ob es funktionier hat, kann ich noch eine Weile nicht sagen - ich lösch gerade aus Platzmangel einen alten Snapshot. Poste es später.!

Habe es probiert, leider benötigt die disk immern noch "repair".

Des Weiteren ist die Frage, ob es mit, oder ohne Anführungszeichen auszuführen ist
MIT Anführungszeichen passiert eigentlich nach RETURN nichts, außer, dass der Cursor auf die nächste Zeile springt.

OHNE Anführungszeichen heist es immer noch "Disk name or some other argument is missing.
VMware virtual disk manager - build 1945795
Usage ..." (und dann kommen die ganzen Standardhinweise, nutzlos hierfür).

Die Defragmentierung geht leider auch nach wie vor nicht (...repair.)

"Compact virtual disk" würde gehen, aber ob das momentan so schlau ist? (durch das löschen sind es nun nur 10 GB.)

Glücklicherweise startet die VM noch normal, vielleicht sogar einen Tick schneller. - Das Herunterfahren über "Shut down guest" endet leider wie üblich erst mal in einem schwarzen Bildschirm...vermutlich hängt sie sich dann wieder auf. (Im Büro ist sie mit Serverbetrieb in Sekunden unten.)

~thc hat geschrieben:Mit Linked Clones kenne ich mich nicht aus - ich fertige komplette Cold Clones für einen solchen Zweck an.

Meinst Du damit Full Clone? - Die verwende ich normalerweise auch, aber nur sehr sporadisch, da der Speicherkonsum enorm ist.

~thc hat geschrieben:In der Freigabe ist nur eine Textdatei mit dem Listing des Programmverzeichnisses der Workstation. Ich brauche die letzte (neueste) Logdatei aus dem Verzeichnis der VM.

Sorry, da ging wohl SafeSync mal nen Moment offline; habe die Dateien nun alle (sicherheitshalber) auch online gestellt.

~thc hat geschrieben:Aktive Snapshots = Die Snapshotkette, die bis zum im Moment aktiven Zustand der VM relevant ist, egal ob die VM läuft oder nicht.

O.k., "Aktiv" bedeutet somit, dass ihn im "Manager" nicht gelöscht habe, oder?

Daher mache ich Cold Clones auch nicht alle 2 Wochen .

Du kannst auch Snapshots im Manager haben, die jünger sind und die VM läuft aktuell auf einem älteren Zustand weiter - dann sind alle späteren Snapshots inaktiv.

Die Logdatei erzählt mir zwei Dinge:

- Durch die entsetzlich lange und große Snapshotkette und 10 (!) Disks im Thin-Format wird alles seeeeeeehr langsam - wie hältst du das aus?

- Beschädigt ist nur der allerletzte aktive Snapshot (Windows 7 x64D-000009.vmdk)

Versuche also die letzte Disk zu reparieren - wenn das fehlschlägt, müsste die VM mit dem vorletzten Snapshot (Windows 7 x64D-000008.vmdk) eigentlich ohne Fehler startbar sein.

Und dann solltest du überlegen, eine richtige Thick-VMDK daraus zu machen.

~thc hat geschrieben:- Durch die entsetzlich lange und große Snapshotkette und 10 (!) Disks im Thin-Format wird alles seeeeeeehr langsam - wie hältst du das aus?

Zähne zusamenbeißen
... bislang weiß ich es nicht besser ...
(zwischenzeitlich sind es auch nur noch der 1. und der letzte Snapshot sowie die 3 obligatorischen "auto protect")

~thc hat geschrieben:- Beschädigt ist nur der allerletzte aktive Snapshot (Windows 7 x64D-000009.vmdk)

Das klingt doch schon weniger schlimm!:)

~thc hat geschrieben:Versuche also die letzte Disk zu reparieren - wenn das fehlschlägt, müsste die VM mit dem vorletzten Snapshot (Windows 7 x64D-000008.vmdk) eigentlich ohne Fehler startbar sein.

Was ist bitte die genaue Synthax? -
vmware-vdiskmanager -R "D:\VMware\Virtual Machines\VMware9\Windows 7 x64D-000009.vmdk"??? - Mit oder OHNE Anführungszeichen? (siehe Frage oben)
LEIDER SPRINGT ER MIT FRAGEZEICHEN NUR IN DIE NÄCHSTE ZEILE - OHNE HEISST ES WIEDER "ARGUMENT MISSING"?

~thc hat geschrieben:Und dann solltest du überlegen, eine richtige Thick-VMDK daraus zu machen.

Das klingt genial, aber wie GEHT das? Gibts da ein Tutorial?!?
UND: wie konnte es überhaupt soweit kommen bzw. wie kann ich das künftig vermeiden?

Die richtige Syntax lautet:

Wenn dies nicht geht, könntest du noch versuchen, stattdessen ins Verzeichnis der VM zu wechseln:

Sollte das auch nicht gehen: Kannst du den letzten Snapshot entfernen?

Und schalte bitte "Auto Protect" umgehend aus.

~thc hat geschrieben:Und schalte bitte "Auto Protect" umgehend aus.

Habe ich gemacht, da ich das http://vmware-forum.de/viewtopic.php?p=88064 noch nachgelese habe. - Allerdings war ich an "Installationstagen" über die Fkt. früher schon froh gewesen (analog bei Excle od. Word). - Aber sicher ist sicher...

~thc hat geschrieben:Die richtige Syntax lautet:

Code: Alles auswählen

vmware-vdiskmanager -R "D:\VMware\Virtual Machines\VMware9\Windows 7 x64D-000009.vmdk"

Wenn dies nicht geht, könntest du noch versuchen, stattdessen ins Verzeichnis der VM zu wechseln:

Code: Alles auswählen

D:
cd "VMware\Virtual Machines\VMware9"
"C:\Program Files (x86)\VMware\VMware Workstation\vmware-vdiskmanager" -R "Windows 7 x64D-000009.vmdk"

Die letzte Synthax auf D: hat scheinbar funktioniert. - Endlich mal ein Command Output, allerdings:
"No errors were found on the virtual disk, 'Windows 7 x64D-000009.vmdk'."


LEIDER BEKOMME ICH IMMER NOCH BEI "DEFRAGMENT" ... needs repair ...???

Brauchst Du die momentan existierenden Snapshots noch?

Ansonsten konsolidiere die doch erst einmal. Eventuell werden dadurch auch schon gleich ein paar interne Verwaltungsprobleme mit der vmdk geloest.

PS:
An "Installationstagen" darf man ja auch gerne Snapshots verwenden (~thc hatte voellig zu recht von "bis zu 14 Tagen" geschrieben). Es muss halt nicht unbedingt "Auto-Destruct" (wie continuum schrieb) sein.

PPS:
Du brauchst nicht zu SCHREIEN. Wir lesen hier alle noch gut...

JustMe hat geschrieben:Brauchst Du die momentan existierenden Snapshots noch?

Ansonsten konsolidiere die doch erst einmal. Eventuell werden dadurch auch schon gleich ein paar interne Verwaltungsprobleme mit der vmdk geloest..

Hm, ja, die benötige ich noch, aber ich kann sie über einen Full Clone auf eine externe HDD übertragen (mache ich gleich, ebenso wie das Löschen der SnSh's). - Ist das schon das "Konsolidieren", oder wie geht es dann weiter?

Sorry, dass es so kompliziert ist.

Snapshot in der aktiven Kette: Löschen = Änderungen in die Stamm-VMDK übernehmen
Snapshot außerhalb der aktiven Kette: Löschen = einfach Löschen
Konsolidieren: Alle Snapshots übernehmen bzw. löschen

JustMe hat geschrieben:Brauchst Du die momentan existierenden Snapshots noch?

Ansonsten konsolidiere die doch erst einmal. Eventuell werden dadurch auch schon gleich ein paar interne Verwaltungsprobleme mit der vmdk geloest..

Habe alle Snapshops usw. gelöscht, nur noch der letzte Stand ist da. Zudem mehrfach Disk Cleanup ausgeführt.

Hat leider alles nichts gebracht - jetzt habe ich viel Platz (13,4GB für die VM ist alles), aber immer noch, "needs repair".

Habe die neuen logs un das neue VM-Directory hochgeladen (siehe link oben) - weitere Ideen?

Laut Log-Datei braucht jetzt keine der Disks mehr eine Reparatur - aber es sind immer noch 5 Snapshot-Disks aktiv! Wenn du alle Snapshots bereinigt hast - dann muss wohl die Snapshot-Kette defekt sein.

Hier muss ich dann leider passen - da müssen echte VMDK/Snapshot-Profis hier im Forum mal draufschauen.

Die Dateien der VM haben eine Gesamtgröße von 120 GB - was zeigt die VM denn intern als Platzverbrauch an?

Hast Du statt des "-R" auch schon mal das kleine "-r" beim vmware-vdiskmanager probiert?

Damit wuerde die -00009 und alle in der Snapshotkette befindlichen Anteile in eine neue vmdk konsolidiert. Immer vorausgesetzt, dass dabei nicht auch "needs repair" kommt...

Und ausreichend Platz auf einem Zieldatentraeger muss vorhanden sein. Den Bedarf kann man mit "-t 0" fuer den Test etwas reduzieren; fuer spaetere Bearbeitung waere dann aber eher "-t 2" oder "-t 3" (fuer continuum ) geeignet.

Wenn die dann ok sein sollte, kann man einfach die "problematischen" alten Dateien entsorgen.

Ich gebe zu, das ich mir die Logs usw. noch nicht angesehen habe, aber ich koennte mir vorstellen, dass die erwaehnten noch auf dem Datentraeger befindlichen Snapshot-Dateien vielleicht von Snaps waren, die nicht in die Kette gehoeren, und vielleicht von ganz anderen "Versuchen" oder "Aufgaben" stammen...

@JustMe: Die Snaps sind aktiv in der VM eingebunden - ich habe deswegen auch "-r" noch nicht vorgeschlagen, weil ich nicht weiß, welche Quelle (letzter Snapshot oder Basis) man angeben muss...

Grmbl... dann muss ich mir die Logs doch mal anschauen

OK, meiner Ansicht nach verweist die vmx in vmware-1.log (wieso wurde eigentlich die aktuellste vmware.log nicht bereitgestellt??) als Startpunkt auf die schon erwaehnte -00009.vmdk. Davon ausgehend oeffnete die Workstation in der Reihenfolge 9-8-5-6-1-base.

Die -00011.vmdk hat einen ziemlich alten Zeitstempel; wird also vmtl nicht verwendet. Dafuer taucht im Listing eine -00003 mit aktuellem Teitstempel auf, die aber nicht referenziert wird.

Da das abgestellte Inhaltsverzeichnis die -00001 und die -00006 nicht anzeigt, dafuer aber eine -000003, scheinen hier noch ein paar Aktionen gelaufen zu sein.

Daraus einen Vorschlag zur Guete @circulars:
- Stelle bitte ein Buendel aktueller und zusammengehoerender Informationen bereit.
- Wenn Du zwischenzeitlich selber etwas ausprobierst, dann dokumentiere das bitte ausfuehrlich (ausgefuehrte Kommandos, eventuelle Ausgaben) hier in einem Beitrag, damit man nicht raten muss.

Zusammenfassend:
Als Quelle fuer "-r" sollte die aktuell in der .vmx eingetragene .vmdk verwendet werden.

Ausgehend von Ulli's Post im Thread Hilfe! Defekte VDMK! ist der der Workstation7 beiliegende "vmware-vdiskmanager.exe" die letzte funktionale Version um vDISKs zu reparieren und eine Downloadquelle für diese Version ist ebenfalls verlinkt. Bei allen späteren WS-Versionen macht die Repair-Funktion überhaupt nichts.

~thc hat geschrieben:Laut Log-Datei braucht jetzt keine der Disks mehr eine Reparatur

Das sagt auch der Befehl für ""C:\Program Files (x86)\VMware\VMware Workstation\vmware-vdiskmanager" -r "Windows 7 x64D-000001.vmdk"" (sh. Screenshot in der neu hochgeladenen VMSystem_Screenshots.docx, in der ich den gesamten Zustand dokumentiert habe mit Screeshots.

Wie dort jedoch auch sieht, bekomme ich - obwohl nun alles gelöscht ist in der Kette sh. Screenshot - immer noch "... needs repair.".

~thc hat geschrieben:- aber es sind immer noch 5 Snapshot-Disks aktiv! Wenn du alle Snapshots bereinigt hast - dann muss wohl die Snapshot-Kette defekt sein.

Das klingt für mich plausibel, deshalb nunmehr die vollständige Löschung. - Wie man jedoch sieht, gibt es immer noch zusätzlich vmdks -8,-9,-5 und 11 sowie den Snapshot81, die auch durch CLEANUP nicht bereinigt wurden (mehrfach "erfolgreich" durchgelaufen.) -- von Hand löschen getraue ich mir nicht ...

~thc hat geschrieben:Die Dateien der VM haben eine Gesamtgröße von 120 GB - was zeigt die VM denn intern als Platzverbrauch an?

Ich hoffe, diese Frage beantwortet ebefalls einer der Screenshots in der VMSystem_Screenshots.docx! - Soweit ich es verstehe, 13,2GB gemäß Screenshot 1 darin, oder?

JustMe hat geschrieben:Hast Du statt des "-R" auch schon mal das kleine "-r" beim vmware-vdiskmanager probiert?

ja, gerade. - Sh. Dokumentation in der Datei VMSystem_Screenshots.docx, die ich nun hochgeladen habe.

JustMe hat geschrieben:Damit wuerde die -00009 und alle in der Snapshotkette befindlichen Anteile in eine neue vmdk konsolidiert. Immer vorausgesetzt, dass dabei nicht auch "needs repair" kommt...

"... needs repair." Das scheint leider passiert zu sein, oder? (sh. Screeshots / logs)

JustMe hat geschrieben:Und ausreichend Platz auf einem Zieldatentraeger muss vorhanden sein. Den Bedarf kann man mit "-t 0" fuer den Test etwas reduzieren; fuer spaetere Bearbeitung waere dann aber eher "-t 2" oder "-t 3" (fuer continuum ) geeignet.

Danke für den Tipp, momentan ist jedoch jetzt wieder gigantisch viel Platz auf der HDD: 163GB.

JustMe hat geschrieben:Wenn die dann ok sein sollte, kann man einfach die "problematischen" alten Dateien entsorgen.

Das könnte für die bei @thc genannten Dateien der Fall sein ... soll ich die löschen? (oder besser: noch warten, bis "repair" endlich mal funzt.?)

JustMe hat geschrieben:Ich gebe zu, das ich mir die Logs usw. noch nicht angesehen habe, aber ich koennte mir vorstellen, dass die erwaehnten noch auf dem Datentraeger befindlichen Snapshot-Dateien vielleicht von Snaps waren, die nicht in die Kette gehoeren, und vielleicht von ganz anderen "Versuchen" oder "Aufgaben" stammen...

Ich habe mit den logs nie etwas gemacht. Allerdings läuft VM seit Jahren auf dem Rechner, bereits in der Version 7 (damals gab es jedoch ein anderes VM-Verzeichnis für die vmx /vmdks ...)

Ich lade gleich nochmals komplett die jetzt - nach den ganzen Bereinigungen - noch verfügbare logs auf den Server hoch. - ggf. sind jedoch auch "Karteileichen" dabei.

JustMe hat geschrieben:Hast Du statt des "-R" auch schon mal das kleine "-r" beim vmware-vdiskmanager probiert?

ja, siehe im thread weiter oben; kein merklicher Unterschied.

JustMe hat geschrieben:Daraus einen Vorschlag zur Guete @circulars:
- Stelle bitte ein Buendel aktueller und zusammengehoerender Informationen bereit.
- Wenn Du zwischenzeitlich selber etwas ausprobierst, dann dokumentiere das bitte ausfuehrlich (ausgefuehrte Kommandos, eventuelle Ausgaben) hier in einem Beitrag, damit man nicht raten muss.

Zusammenfassend:
Als Quelle fuer "-r" sollte die aktuell in der .vmx eingetragene .vmdk verwendet werden.

M.E. sollte dies mit
"C:\Program Files (x86)\VMware\VMware Workstation\vmware-vdiskmanager" -r "Windows 7 x64D-000001.vmdk"
so richtig gewesen sein, oder (sh. Sreenshot in VMSystem_Screenshots.docx-Datei)

Soweit meine Kenntnisse reichen, habe ich das immer getan. - Die logs habe ich durch suchen im VM-Verzeichnis mit *.log gesucht und dann hochgeladen.

Ich mache das alles gleich für alle Verzeichisse nochmals, inkl. DIR.

Poste gleich, wenn Upload erledigt.

Dayworker hat geschrieben:Ausgehend von Ulli's Post im Thread Hilfe! Defekte VDMK! ist der der Workstation7 beiliegende "vmware-vdiskmanager.exe" die letzte funktionale Version um vDISKs zu reparieren und eine Downloadquelle für diese Version ist ebenfalls verlinkt. Bei allen späteren WS-Versionen macht die Repair-Funktion überhaupt nichts.

Das ist ein sehr wertvoller Input!...damit ist geklärt, warum bislang immer NICHTS passiert ist. - Was denkt sich VMware eigentlich, Programmteile auszuliefern, die ohne Funktion sind?

Schnitzeljagd zum Download:
http://vmware-forum.de/viewtopic.php?p=166336#166336
http://kb.vmware.com/kb/1023856

-> und dann muss man sich einfach in sein Download-Center einloggen, zum Glück hatte ich V7 bereits.

Nun habe ich VMware-workstation-full-7.1.4-385536 zur Installation auf dem Rechner - wie komme ich nun bitte an die benötigte, darin wohl enthaltene Datei heran, ohne zu installieren - VM9 will ich natürlich nicht überschreiben?

Ich habe deshalb von einem alten Rechner noch eine Datei (v7-1-3 gezogen, geht die?!?), allerdings noch auf Win7-32bit (hier: 64bit) und versuche es nun mit ihr.