Bei der heutigen Installation der VMware Workstation 9 unter Opensuse 12.1 trat bei mir folgendes Problem auf:
Ich hatte die Installation als root über das Kommando
sh VMware-Workstation-Full-9.0.0-812388.x86_64.bundle
durchgeführt. Die lief dann über den graphischen VMware-Installer auch einwandfrei durch. Ein Start vorhandener virtueller Maschinen (Win XP, Win 7) schlug jedoch mit folgender Fehlermeldung fehl:
Version mismatch with vmci driver: expecting 11.0, got 10.0. Module DevicePowerOn power on failed.
VMCI-Treiber (“Virtual Machine Communication Interface”) sind für den VMware-Workstation-Betrieb essentiell. Sie regeln die Kommunikation zwischen Host und den virtuellen Gästen. VMCI erfordert Kernel-Module; die Fehlermeldung zeigt an, dass nicht das richtige Modul – in der richtigen Version – geladen wird.
Dieses Problem hat mich etwas Zeit gekostet. Ich hoffe, der nachfolgende Artikel zur Problemlösung hilft auch anderen.
Problemursache
Aus meiner Sicht arbeitet der Installer für die WS 9 diesbzgl. unter Opensuse 12.1 und 12.2 nicht hinreichend gründlich und kollidiert in meiner Situation mit dem sog. “Weak Versioning” oder “Weak-Update”-Mechanismus.
Oftmals ist ein Modul mit mehreren Kernel-Versionen kompatibel. Kernel-Updates und KMP-Updates führen dann dazu, dass im Verzeichnis “/lib/modules/KERNEL_VERSION/weak-updates/” und darunter Links zu kompatiblen Modulen anderer (früherer) Kernel-Versionen angelegt werden.
http://http://www.suse.de/~agruen/KMPM/old/KernelModulePackagesManual-CODE10.pdf
http://comments.gmane.org/gmane.linux.kernel.dkms.devel/843
Der gut gemeinte Mechanismus kann schon mal zu Problemen führen:
http://www.gossamer-threads.com/lists/linux/kernel/992144
http://www.linuxquestions.org/questions/suse-novell-60/virtualbox-kernel-modules-wont-load-after-updating-kernel-in-opensuse-11-0-a-696801/
So gilt:
Hat man auf einem Opensuse oder Red Hat System vorher andere VMware WS Versionen am Laufen gehabt und zwischenzeitlich Kernel-Updates (und/oder WS-Updates) durchgeführt, so greift ggf. der beschriebene Mechanismus. Danach befinden sich im oder unterhalb des Verzeichnisses “/lib/modules/KERNEL_VERSION/weak-updates/” also möglicherweise Einträge zu Kernelmodulen für VMware. Diese haben dann Priorität gegenüber anderen gleichlautenden Modulen in anderen Verzeichnissen unterhalb “/lib/modules/KERNEL_VERSION” (mit Ausnahme von Modulen unter “/lib/modules/KERNEL_VERSION/updates”).
Der gleiche Mechanismus greift bei Opensuse übrigens auch, wenn man parallel mehrere Versionen derselben Kernelversion – aber mit unterschiedlicher Modulausstattung wie den Desktop-Kernel “3.1.10-1.16-desktop” oder den Default-Kernel “3.1.10-1.16-default” installiert hat.
Der Installer für die WS 9 er rechnet leider nicht damit, dass es zwei Module “vmci.ko” an unterschiedlichen Stellen unter “/lib/modules/KERNEL_VERSION/” gibt. In meinem Fall war es aber so, dass kontinuierliche Upgrades und zwei parallele Kernelvarianten auf meinem System zu einer solchen Situation geführt hatten. Ein ähnliches Problem gab es schon mal bei Opensuse 11.1 und Opensuse 11.4 mit dem vmmon-Modul.
Ein find-Befehl am root-prompt
zeigte auf meinem aktuellen Opensuse 12.1, auf dem früher unterschiedliche Versionen der WS 7 und 8 installiert und upgegradet worden waren, fast erwartungsgemäß :
mylinux:~ # cd /lib/modules/3.1.10-1.16-default
mylinux:/lib/modules/3.1.10-1.16-default # find . -name “*vmci*”
./weak-updates/updates/vmci.ko
./misc/vmci.ko
Nach der WS 9 Installation waren bei mir jedenfalls 2 “vmci.ko”-Module vorhanden! Wie immer und wann auch immer im Zuge früherer Kernel und VMware-Updates das eine “vmci.ko”-Modul im Verzeichnis unter “/lib/modules/3.1.10-1.16-default/weak-updates/updates” gelandet ist. Der Eintrag wird bei mir auch aus anderen Kernel-Zweigen unter “/lib/modules/” (Opensuse’s Desktop-Kernel !) referenziert.
Hinweis:
Hat jemand das gleiche Problem wie ich, findet aber nichts im “weak-updates”-Verzeichni, so lohnt sich jedenfalls eine Suche in anderen Subverzeichnissen von “/lib/modules/KERNEL_VERSION”:
Bei anderen Opensuse-Versionen (z.B. 12.2) kann ein zweiter Eintrag statt unterhalb des “weak-updates”-Verzeichnis ggf. auch im “weak-updates”-Verzeichnis selbst oder aber im Verzeichnis “/lib/modules/KERNEL_VERSION/updates” vorliegen.
Das im “weak-updates”-Verzeichnis eingetragene Modul “vmci.ko” ist zwar mit der aktuellen Version 3.1.10-1.16 des Opensuse Default- und des Desktop-Kernels kompatibel, denn dafür wurde das Modul mal von einem VMware-Installer kompiliert. Der Eintrag entspricht aber dem Modul einer VMware WS 8.0.4 Version !
VMware WS 9 benötigt dagegen ein neueres “vmci.ko”-Modul und prüft die Modul-Version offenbar auch beim Hochfahren eines virtuellen Gastes ab. Daher die oben genannte Fehlermeldung! (Die richtige, benötigte und zur WS 9 passende Modul-Version lag und liegt im Verzeichnis “/lib/modules/3.1.10-1.16-default/misc”.)
Offenbar wird im Zuge des Bootvorgangs beim initialen Aufbau der vmware-Umgebung durch das Script “/etc/init.d/vmware” also das falsche Modul – nämlich das im “weak-updates”-Verzeichnis eingetragene – geladen. Woran legt das?
Verantwortlich hierfür sind Prioritätsregeln für die Ladereihenfolge; s. hierzu den obigen PDF-Link zum “Weak-update”-Mechanismus. Zitat:
Modules usually remain compatible with a range of kernel-flavor packages. To make such modules visible to other kernel-flavor packages, symbolic links to compatible modules are put in /lib/modules/version-release-flavor/weak-updates/ directories. Modules in the weak-updates/ directory has lower priority than modules in the updates/ directory, but higher priority than all other modules in /lib/modules/version-release-flavor. If more than one compatible module is available for a kernel, the module with the highest kernel release is chosen.
Auch “/etc/init.d/vmware” verläßt sich darauf, dass es nur ein Modul mit der Bezeichnung “vmci.ko” gibt. Das Script führt einfach “insmod vmci.ko” aus – und dann greifen eben die Prioritätsregeln des “weak-update”-Mechanismus bei der Lade-Reihenfolge. Diese sind im System (depmod!) hinterlegt.
Eigentlich müsste der VMware-Installer für die WS 9 deshalb unter Opensuse nicht nur sein neues “vmci.ko”-Modul kompilieren, sondern auch die alten mit dem Kernel kompatiblen Module (bzw. Links) entfernen – und dabei checken, dass es auch die Einträge unter “weak-updates” erwischt – und dann das neue Modul an der richtigen Stelle (hier: “/lib/modules/3.1.10-1.16-default/misc”) hinterlegen.
Der Installer für VMware WS 9 rechnet aber wohl leider von vornherein fest damit, dass das “vmci.ko”-Modul nur unter dem Verzeichnis “/lib/modules/KERNEL_VERSION/misc”
lag und liegen soll. Das muss nach Updates und Zusatz-kernel-Installation unter Opensuse und Red Hat
aber nicht zwangsläufig der Fall sein.
Das ich nicht der einzige bin, dem das schon mal mit einem VMware-Kernel-Modul passiert ist, kann man nach einer Suche mit
- “VMware WS Version mismatch vmci vmmon driver” oder
- “VMware WS Version mismatch vmci” oder
- “VMware WS Version mismatch”
im Internet nachvollziehen.
Auf einem anderen System, auf dem ich die WS 8.0.4 jungfräulich aufgesetzt hatte, tauchte das vmci.ko-Modul nur unter “/lib/modules/3.1.10-1.16-default/misc” auf. Na ja, ….. Jedenfalls war die Ursache meines vmci-Problems mit der WS 9, dass es zwei VMware-Kernelmodule gleichen Namens unterhalb von “/lib/modules/3.1.10-1.16-default” gab. Damit war und ist aber auch der Lösungsweg klar.
Lösung
Man verschiebe das Modul als root in ein anderes Verzeichnis (bei mir /extras/root) und starte VMware neu:
mylinux:/lib/modules/3.1.10-1.16-default/weak-updates # cd updates/
mylinux:/lib/modules/3.1.10-1.16-default/weak-updates/updates # ls
balloon blkfront netfront platform-pci scsifront vmblock.ko vmci.ko vmhgfs.ko vmsync.ko vmxnet.ko vsock.ko
mylinux:/lib/modules/3.1.10-1.16-default/weak-updates/updates # mv vmci.ko /extras/root/
mylinux:/lib/modules/3.1.10-1.16-default/weak-updates/updates # /etc/init.d/vmware stop
Stopping VMware services:
VMware Authentication Daemon done
VM communication interface socket family done
Virtual machine communication interface done
Virtual machine monitor done
Blocking file system done
mylinux:/lib/modules/3.1.10-1.16-default/weak-updates/updates # vmware &
Beim erneuten Start (vmware &) können Abhängigkeiten (vergl. “/lib/modules/3.1.10-1.16-default/modules.dep”) und die bisher definierte Ladereihenfolge nicht mehr richtig aufgelöst werden, weil das (falsche) Modul nun fehlt. VMware versucht in dieser Situation automatisch, seine Module neu zu kompilieren und die Modulabhängigkeiten durch ein abschließendes depmod zu regeln.
Danach gibt es nurmehr ein “vmci.ko”-Modul :
mylinux:/lib/modules/3.1.10-1.16-default # find . -name “*vmci*”
./misc/vmci.ko
und auch “/lib/modules/3.1.10-1.16-default/modules.dep” zeigt die richtigen Einträge/Abhängigkeiten:
misc/vmci.ko:
misc/vmmon.ko:
misc/vmnet.ko:
weak-updates/updates/vmblock.ko:
weak-updates/updates/vmxnet.ko:
weak-updates/updates/vmhgfs.ko: misc/vmci.ko
weak-updates/updates/vmsync.ko:
weak-updates/updates/vsock.ko: misc/vmci.ko
Und natürlich lassen sich die virtuellen Gäste unter der VMware WS 9 nun auch problemlos hochfahren.
Man kann dann auch die die HW-Kompatibilität der alten WS 8 Gästsystem an die WS 9 anpassen.
Viel Vergnügen weiterhin mit der VMware Workstation 9 unter Opensuse 12 !