VMWare Workstation 9/10 startet nach reboot nicht mehr

[WLemmy]

Hallo,

Host: AMD A10 mit Linux Ubuntu LTS und VMware 9

von heute auf morgen startete die VMWare nicht mehr. Es kommt die Fehlermeldung
Unable to Change virtual machine power state: Internal error

Da ich unsicher war und eh den Host aktualisieren wollte, habe ich LinuxMint 16 KDE installiert und VMWare 10 installiert.

Lief wunderbar - bis zum nächsten Reboot: gleicher Fehler wie oben. In den Logs habe ich nichts gefunden.

Im Internet findet sich so mancher Hinweis auf
sudo vmware-modconfig --console --install-all

hat nichts geholfen, ebenso wenig wie den Prozess killen:
killall -s9 vmware-vmx

Bevor ich mich an den Support wende: Hat von euch noch jemand eine Idee? Auf 2 weiteren Rechnern läuft (einmal LinuxMint15, einmal LinuxMint 16) VMWare 10 bisher problemlos....)

GRüße

[irix]

Irgendwelche *.lck Dateien im Verzeichnis? Falls ja bitte loeschen und nochmal probieren.

Gruss
Joerg

[WLemmy]

Hallo Jörg,

ja vorhanden, habe ich auch schon gelöscht und nochmal versucht: Gleicher Fehler.

Vielleicht der Hinweis:

Wenn ich reboote dauert es einige Zeit (30-60 Sekunden) bis die Fehlermeldung auftaucht. Wenn ich dann gleich nochmal versuche zu starten kommt die meldung gleich.

Wenn ich dann per "killall -s9 vmware-vmx" die Prozesse abschieße dauert es wieder deutlich länger bis die Fehlermeldung kommt.

Log Datei einer VM gibts hier:
lemmermeyer.info/vmware.log.zip

[Dayworker]

Welches Linux du als Host-OS installiert hast, interessiert nur soweit, welche Kernel-Version darauf läuft. VMware spricht nach mehreren Aussagen nicht darüber, was notwendig wäre, damit VMware mit einer bestimmten Kernel-Version läuft. Erst wenn VMware eine neue Produktversion veröffentlicht, werden die damit unterstützten Kernel-Versionen genannt und solange helfen nur die üblichen Patches.

Schau dir dazu auch mal im Workstation- und Player-Bereich die üblichen Threads wie "VMware startet nicht unter Distribution XYZ" oder "VMware-Produkt ein einziger Krampf" genauer an.

[Dayworker]

2014-01-10T15:25:10.213+01:00| Worker#0| I120: DISK: OPEN scsi0:0 '/home/wolfgang/vmware/Windows 7 x64/Windows 7 x64-000001.vmdk' persistent R[]
2014-01-10T15:25:10.289+01:00| Worker#0| I120: DISKLIB-SPARSE: "/home/wolfgang/vmware/Windows 7 x64/Windows 7 x64-000001.vmdk" : failed to open (14): Disk needs repair.
2014-01-10T15:25:10.289+01:00| Worker#0| I120: DISKLIB-LINK : "/home/wolfgang/vmware/Windows 7 x64/Windows 7 x64-000001.vmdk" : failed to open (The specified virtual disk needs repair).
2014-01-10T15:25:10.289+01:00| Worker#0| I120: DISKLIB-CHAIN : "/home/wolfgang/vmware/Windows 7 x64/Windows 7 x64-000001.vmdk" : failed to open (The specified virtual disk needs repair).
2014-01-10T15:25:10.289+01:00| Worker#0| I120: DISKLIB-LIB : Failed to open '/home/wolfgang/vmware/Windows 7 x64/Windows 7 x64-000001.vmdk' with flags 0x1a The specified virtual disk needs repair (14).
2014-01-10T15:25:10.366+01:00| Worker#0| I120: DISKLIB-DSCPTR: Opened [0]: "Windows 7 x64-000001.vmdk" (0x1a)
2014-01-10T15:25:10.366+01:00| Worker#0| I120: DISKLIB-LINK : Opened '/home/wolfgang/vmware/Windows 7 x64/Windows 7 x64-000001.vmdk' (0x1a): monolithicSparse, 209715200 sectors / 100 GB.
2014-01-10T15:25:10.366+01:00| Worker#0| I120: DISKLIB-DSCPTR: Opened [0]: "Windows 7 x64.vmdk" (0x1e)

Deine vDISK muß repariert werden und das Problem dabei ist laut unserem Ulli aka "continuum" oder einfach VMDK-Gott, daß der "vmware-vdiskmanager.exe" inzwischen seit mehreren Workstation/Player-Versionen defekt ist und man keine VMDKs mehr reparieren kann.

Du kannst ja mal probieren, was dir der "vmware-vdiskmanager.exe" in einer CMD mit adminsitrativen Rechten ausgibt, wenn du folgenden Befehl startest:

Code: Alles auswählen

vmware-vdiskmanager.exe -R "Windows 7 x64-000001.VMDK"

[edit]
VMDK-Namen spezifiert, da hier zumindest ein aktiver Snapshot vorliegt und die Situation dadurch verkompliziert.

[WLemmy]

Hi,

Schau dir dazu auch mal im Workstation- und Player-Bereich die üblichen Threads wie "VMware startet nicht unter Distribution XYZ" oder "VMware-Produkt ein einziger Krampf" genauer an.

VM 9 läuft auf den aktuellen LTS Versionen von Ubuntu und co, die 10er auf den aktuellen Halbjahresversionen - auch ohne Patch. Wie oben beschrieben bei mir im EInsatz.

vmware-vdiskmanager habe ich laufen lassen, meinte auch dass er die Disk repariert hat, aber keine Änderung

[continuum]

Falls es sich noch nicht herumgesprochen hat ...

vmware-vdiskmanager -R ist broken. Letzte bekannte gute Version ist die von WS 7

[Dayworker]

Den Fehler gibt es aber gerade nach einem Kernel-Update und nach einem halben Jahr haben zwei neue Kernel-Versionen das Licht der Welt erblickt. VMware braucht aber immer etwas länger für eine neue Produktversion. Das die 10 und erst recht die 9 auf allen Ubuntu-Versionen auch so laufen, läßt sich meiner langjährigen VMware-Erfahrung nach so nicht halten oder ist deshalb ungeachtet der VMware-Aussagen spätestens nach jedem Kernel-Patch so auch nicht mehr ungetestet haltbar.

VMware unterstützt eine Distribution auch immer nur mit dem zu deren Auslieferungszeitpunkt mitgelieferten Kernel. Bei einer Distri mit regelmäßigem Kernel-Upgrades benötigt jedes VMware-Desktopprodukt in den meisten Fällen nach 3 Monaten einen Patch. Das sind meine persönlichen Erfahrungen seit ich mich irgendwann 2006 mit dem VMware-Server1 beschäftigt hatte und zu Beginn hatte ich noch Suse9.3 im Einsatz. Nach jedem Kernel-Patch durch Suse wegen gefundener Sicherheitsprobleme war man dort immer wieder auf einen passenden, sogenannten VMware-Any-Any-Patch angewiesen. Diese Patches wurden meiner Erinnerung nach weder von VMware noch von Suse sondern einem Community-Mitglied veröffentlicht. Von daher nimmt man entweder ein richtiges Server-Linux (RHEL/CentOS etc) mit längerfristig gepflegtem, gleichen Kernel (RHEL/CentOS waren manchmal trotzdem nicht sehr pflegeleicht im Zusammenspiel mit VMware-Produkten) oder wechselt wie ich auf ein in dieser Hinsicht einfacher zu händelndes OS. Das Suse9.3 mit dem Realtek8169-Chip merkwürdige, anscheinend unlösbare Performanceprobleme hauptsächlich beim Samba-Zugriff hatte oder der nVidia-Treiber nach einem Kernel-Patch keine GUI mehr anzeigen wollte, haben mir den Umstieg in die Fenster-Welt entschieden vereinfacht.

Auch wenn die letzten beiden Linux-Punkte inzwischen wesentlich entschärft sind, bleiben die stetigen neuen Kernel-Versionen im Dreimonatsrhythmus ein ständiges Quell der Ärgernis für jede propitäre, nicht im Quelltext vorliegende SW und das sind nun einmal alle VMware-Produkte.