VMware Player funktioniert nicht in Siduction Host

[Hanisch]

Hallo,
Der Versuch, den VMware Player unter dem topaktuellen Siduction Host zu installieren, schlug fehl.

Nach erfolgreicher Installation von ~/DOWNLOADS/VMware-Player-15.5.6-16341506.x86_64.bundle
kam bei Aufruf von vmware-player:

Code: Alles auswählen

VMware Kernel Module Updater
Compiling and installing following kernel-modules...
vmmon
vmnet


und dann weiter:

Code: Alles auswählen

Unable to install all modules. See log /tmp/vmware-opa/vmware-117283.log for details (exit code 1)

Warum funktioniert das nicht?

Gruß
Ch. Hanisch

[~thc]

Siduction ist ist eine auf Debian unstable (sid) basierende Linux Distribution.

Aufgrund des modifizierten Kernels (für 18.2.0: "a custom-patched version of the Linux kernel 4.15.7") sind genau solche Probleme zu erwarten.

Vielleicht gibt es aus der SIduction-Community heraus irgendwo einen Patch für die VMWare Kernel Module.

[Dayworker]

Hier muß man wieder eines ganz klar sagen. Falls man am Kernel-Puls der Zeit bleiben will und immer die neuesten Kernel einzusetzen gedenkt, bleibt einem als einfachste Lösung nur die Nutzung eines VT-Produktes übrig, daß von den Kernel-Maintainern im Zuge der Kernel-EW mitgepflegt wird und das wäre dann halt KVM.

[Hanisch]

Hier muß man wieder eines ganz klar sagen. Falls man am Kernel-Puls der Zeit bleiben will und immer die neuesten Kernel einzusetzen gedenkt, bleibt einem als einfachste Lösung nur die Nutzung eines VT-Produktes übrig, daß von den Kernel-Maintainern im Zuge der Kernel-EW mitgepflegt wird und das wäre dann halt KVM.

Schwacher Trost.
Nur gut, daß ich noch ein altes EOL Ubuntu 12.04 habe. Da läuft nämlich auch die neueste Version von VMware Player noch.
Leider funktioniert im Gegensatz zu VirtualBox die VM mit Fedora 32 nicht.
Siehe Anhang.

Code: Alles auswählen

 cat /etc/fstab
# /etc/fstab
# Created by anaconda on Sun Jun 21 05:06:05 2020
#
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
#
UUID=38d730e7-72cd-4edf-9ddb-59c5ca8d0cb1 /                       ext4    defaults        1 1
UUID=9ed52596-7fd1-4410-9c51-e74a61ff0c81 /boot                   ext4    defaults        1 2
UUID=89b74026-ff81-4637-adc9-238e9ae000cf /home                   ext4    defaults        1 2
UUID=88e91714-8c95-44c2-a1ed-534524b8f4ab none                    swap    defaults        0 0

$ sudo blkid
/dev/sda1: UUID="9ed52596-7fd1-4410-9c51-e74a61ff0c81" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="0006e9f9-01"
/dev/sda2: UUID="38d730e7-72cd-4edf-9ddb-59c5ca8d0cb1" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="0006e9f9-02"
/dev/sda3: UUID="88e91714-8c95-44c2-a1ed-534524b8f4ab" TYPE="swap" PARTUUID="0006e9f9-03"
/dev/sda4: LABEL="FedoraHome" UUID="89b74026-ff81-4637-adc9-238e9ae000cf" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="0006e9f9-04"

Ansonsten werde ich VirtualBox benutzen, da gibt es diese Probleme mit dem Kernel nämlich nicht.

Gruß
Ch. Hanisch

[Dayworker]

Das hat mit schwachem Trost nix zu tun, sondern ist eher der Realität geschuldet. Das Player/WS mit dem alten Ubuntu laufen, ist kerneltechnisch vollkommen verständlich. Denn für fast alle alten Kernel bringt VMware bereits die notwendigen Kernel-Module mit. VMware auf der anderen Seite kostet ab der WS immer Geld und leistet dafür auch Support. Sowas ist jedoch schwer zu leisten, wenn gepatchte Kernel die Support-Grundlage sein sollen. Man kann als Programmierer beim Bughunting nix nachstellen, wenn sich entscheidende Teile verändern. Verstehe einfach mal jede neue Kernel-Version als das was sie in der Windows-Welt ist, nämlich als neue Win-Version.

Das VB diese Probleme nicht hat, halte ich für ein Gerücht. Jede VT-Lösung muß funktionsbedingt extrem tief im System ansetzen und da sind gepatchte Kernel ebenfalls hinderlich. Es macht gleichfalls einen Unterschied, ob man seine SW als "wie sie ist" herausgibt oder Support zu leisten hat. Oracle als VB-Mutter macht ja bis auf das "Extension Pack" im Grunde nix anderes, gibt die SW "wie sie ist" raus und verweist ansonsten auf die Community.


Die Frage für mich wäre eher, ob jeder Virtualisierung als solches überhaupt noch braucht. Für viele Dinge muß man nicht mehr ein OS als Wasserkopf mitschleppen, Container - in welcher Form auch immer - leisten ihre Arbeit mit wesentlich kleinerem Fußabdruck und skalieren dadurch auch weitaus besser.



[edit]
VMware unterstützt immer nur die zum Zeitpunkt der Veröffentlichtung erhältlichen Gast-OS und erweitert diese Liste nur selten. Das Fedora32 in der alten WS/Player-Version scheitert, ist daher vorherzusehen.

[Martin]

VB wird als Open Source Lösung von einigen Linux Distributionen geforked und mitgeliefert, daher ist es deutlich "näher" an neuen Kernel-Versionen und es dauert oft nur einzelne Wochen, bis ein ganz neuer Linux-Kernel unterstützt wird.
Außerdem gibt es VB auch als .run Download zum direkten Kompilieren, womit man dann nicht abhängig von vorgepackten Installern einer Linux-Distribution ist.

Es ist einfach ein komplett anderer Ansatz, der für einige Einsatzvarianten damit besser funktioniert.

[Dayworker]

@Martin
Genau diese Nähe war auch der Grund für VMware, seine VMware-Tools für Linux nicht mehr mitzuliefern sondern auf die Open-VM-Tools zu verweisen. Da es keinen eigenständigen Player gibt, kann VMware auch dessen Sourcen nicht einfach mal so veröffentlichen. Der Player war und ist schon immer eine im Funktionsumfang abgespeckte Workstation gewesen.

Das heutige Linux- und Windows-Nutzer mit den VMware-Desktopprodukten inzwischen nicht mehr so glücklich sind wie noch zu WinXP-Zeiten, ist mir jedoch auch nicht entgangen. Ich persönlich verstehe die VMware-Desktopprodukte inzwischen als unabwendbarer Übergang zum ESXi mit seiner genau spezifierten HW. Eine geringe HW-Varianz, wie es auch bei Apple auftritt, läßt halt mehr Raum für das wesentlich und man verplempert keine Zeit in irgendwelche Eigenheiten unterschiedlicher HW. Letzteres ist auch so ein Grund, weshalb neue Android-Versionen sich so zögerlich durchsetzen und Apple auch 5 Jahre alte Gerät mit einem aktuellen iOS ausrüsten kann.


Aber das ist reichlich Offtopic...

[Hanisch]

Das Player/WS mit dem alten Ubuntu laufen, ist kerneltechnisch vollkommen verständlich. Denn für fast alle alten Kernel bringt VMware bereits die notwendigen Kernel-Module mit.
Das VB diese Probleme nicht hat, halte ich für ein Gerücht.

Ich konnte jedenfalls bei noch keiner meiner vielen VM's in VirtualBox ein ähnliches Problem feststellen.

VMware unterstützt immer nur die zum Zeitpunkt der Veröffentlichtung erhältlichen Gast-OS und erweitert diese Liste nur selten. Das Fedora32 in der alten WS/Player-Version scheitert, ist daher vorherzusehen.

O Wunder!
Während mit den Kernels:
Fedora (5.6.19-300.fc32.x86_64 ) 32 (Thirty Two)
Fedora (5.6.6-300.fc32.x86_64) 32 (Thirty Two)
die VM mit obigem Ergebnis nicht funktioniert, gelingt es mit dem rescue-Kernel:

Code: Alles auswählen

Fedora (0-rescue-1aef1ea8bdcf4d4f8efe541aedae142b) 32 (Thirty Two)

Mit der Installation der 'vmware-tools' wird auch eine 'initramfs' für den Kernel 5.6.6-300.fc32.x86_64 neu geschrieben.
Nach Korrektur nun mit folgender

Code: Alles auswählen

# cat /etc/dracut.conf.d/vmware-tools.conf
add_drivers+=" vmxnet3 vmw_pvscsi "

und

Code: Alles auswählen

$ sudo dracut --force --regenerate-all

bootet er jetzt auch mit allen Standard-Kernels.

Gruß
Ch. Hanisch

[Dayworker]

Nimm mal eine alte VB-Version und installiere darin ein neues OS, das wird auch nicht vollkommen problemlos ablaufen.

Wenn der Rescue-Kernel funktioniert, schau doch einfach mal nach, was sie dort gegenüber dem Standard-Kernel verändert haben. In diese Betrachtung mit reinnehmen solltest du die X.org- und jetzt Wayland-Geschichte.