> Oracle VM VirtualBox 6.1.14 brings host/guest support for the Linux 5.8 stable kernel
and VMware is still sleeping as it does with every new kernel-version......
sadly the SuSE guy this time too (GitHub - mkubecek/vmware-host-modules at workstation-15.5.6 )
5.7.19 [EOL] means you can choose between VMware or Security updates
The vmware-modconfig segfault is a known problem; fortunately it can be worked around easily by building (patched) modules manually and then bypassing the execution of vmware-modconfig. You can e.g.
is that the one which drops support for Intel SandyBridge and IvyBridge at a time where you don't can buy IceLake/TigerLake for desktop computes i am waiting for years now?
and to make it clear: it's a shame that a guy from a different company is needed for years to get the vmmon and vmnet tarbalss compatible with recent Linux kernels
GitHub - mkubecek/vmware-host-modules at workstation-15.5.6
and Vmware needs a major version upgrade for that?
a new major release is not the answer, it's that simple
I have not tried it yet but this is supposed to patch to make kernel 5.8 work.
https://github.com/baryonix/vmware-host-modules/tree/fixes-for-5.8
yeah, hopefully this will work soon, but i don't get why VMware doesn't manage that itself given that new Linux releases don't fall unannounced from heaven, the vmnet/vmmon tarballs should be downloadable independent of new Workstation releases at all
yeah, the 3rd party pacthes are working again
[root@srv-rhsoft:~]$ lsmod | grep vm
vmw_vmci 90112 0
vmmon 131072 3
vmnet 65536 16
[root@srv-rhsoft:~]$ uname -r
5.8.7-200.fc32.x86_64 #1 SMP Mon Sep 7 15:26:10 UTC 2020
[root@srv-rhsoft:~]$ vmrun.sh
HOST: srv-rhsoft.rhsoft.net
Total running VMs: 2
/mnt/data/vmware/testserver/config.vmx
/mnt/data/vmware/esx/esx1.vmx
luckily i start most of my guests in background with systemd-services, starting my win10 guest with vmplayer still dont't work, as service it also does
Sep 9 13:17:55 srv-rhsoft kernel: vmware-modconfi[595529]: segfault at 0 ip 00007f7ad703b797 sp 00007ffecd90a7f8 error 4 in libc-2.31.so[7f7ad6fc1000+150000]
Sep 9 13:17:55 srv-rhsoft kernel: Code: 00 00 00 f3 0f 1e fa 66 0f 6e ce 89 f8 25 ff 0f 00 00 66 0f 60 c9 3d c0 0f 00 00 66 0f 61 c9 66 0f 70 c9 00 0f 8f 69 01 00 00 <f3> 0f 6f 07 66 0f ef db 66 0f 6f e0 66 0f 74 c1 66 0f 74 e3 66 0f
The vmware-modconfig segfault is a known problem; fortunately it can be worked around easily by building (patched) modules manually and then bypassing the execution of vmware-modconfig. You can e.g.
indeed, that works - thanks!
[root@srv-rhsoft:~]$ rm /usr/bin/vmware-modconfig
[root@srv-rhsoft:~]$ ln -s /usr/bin/true /usr/bin/vmware-modconfig
BTW: that script is part of my boot process and fired by systemd oneshot units for years now to build the modules
[root@srv-rhsoft:~]$ cat /usr/local/bin/vmware-build-modules.sh
#!/usr/bin/bash
MAKE_DEBUG="-d"
MAKE_DEBUG=""
LANG=C
RUNNING_KERNEL=`/usr/bin/uname -r`
if [ -f /lib/modules/$RUNNING_KERNEL/misc/vmmon.ko ] && [ -f /lib/modules/$RUNNING_KERNEL/misc/vmnet.ko ]; then
echo "VMware-Modules are already built"
chmod 644 /lib/modules/$RUNNING_KERNEL/modules.* 2> /dev/null
chmod 755 /lib/modules/$RUNNING_KERNEL/misc 2> /dev/null
chmod 644 /lib/modules/$RUNNING_KERNEL/misc/*.ko 2> /dev/null
exit 0
fi
UUID=$(uuidgen)
TEMP_DIR="/tmp/vmware-$UUID"
rm -rf "$TEMP_DIR"
mkdir "$TEMP_DIR"
cd "$TEMP_DIR"
find /usr/lib/vmware/modules/source -name "*.tar" -exec tar xf '{}' \;
mkdir -p /lib/modules/$RUNNING_KERNEL/misc
rm -f /lib/modules/$RUNNING_KERNEL/misc/{vmblock.ko,vmci.ko,vmmon.ko,vmnet.ko,vsock.ko}
cd vmmon-only
make $MAKE_DEBUG
cd ..
cp -p vmmon.o /lib/modules/$RUNNING_KERNEL/misc/vmmon.ko 2> /dev/null
cd vmnet-only
make $MAKE_DEBUG
cd ..
cp -p vmnet.o /lib/modules/$RUNNING_KERNEL/misc/vmnet.ko 2> /dev/null
cd ~
rm -f /etc/vmware/not_configured
rm -rf "$TEMP_DIR"
depmod -a
chmod 644 /lib/modules/$RUNNING_KERNEL/modules.* 2> /dev/null
chmod 755 /lib/modules/$RUNNING_KERNEL/misc 2> /dev/null
chmod 644 /lib/modules/$RUNNING_KERNEL/misc/*.ko 2> /dev/null
it's a **bleep**ing joke that you still have to replace the module tarballs and do the "rm /usr/bin/vmware-modconfig; ln -s /usr/bin/true /usr/bin/vmware-modconfig" with VMware-Workstation-Full-15.5.7-17171714.x86_64.bundle
The 15.5.7 host modules source is exactly the same as in 15.5.6 and 15.5.5 so this doesn't really come as a surprise. What is worse is that the hack which works around the 5.8 breakage cannot be used with 5.10-rc1 and newer. The proper solution implemented in version 16 is quite intrusive and it's not obvious if it could be implemented without modifying also the userspace part (which is something only VMware can do).
i stopped to be surprised in 2018 when VMware started to trhow out network divers with ESXi failing the whole management network because they don't test what they get form hardware vendors no matter on the HCL or not and that the *beep* network shouldn't ever have gone down given that the temaing was configured over diffrent phyiscal NIC's (all on the HCL) to exactly avoid such idiotic issue when a single NIC or driver goes wrong
in other words: if KVM and Proxmox would have existed in 2008 i would never have touched all that [removed by moderator]
Hi loungehostmaste,
I am struggling with the bypass in order to have VMware up and running again.
I never had issues with different versions until I upgraded to Debian bullseye.
I tried VMWare version 15.5.1 and 15.5.7 - result is the same.
As I am not so experienced could you please kindly support me a bit.
I did following:
Thanks
sorry, but nobody cares about 15.x in 2022 when current is 16.2.1 which works at the moment with kernel 5.15.12 out-of-the-box
Except v16 dropped support for the "Workstation Server" service, so staying on v15 is prefered.
who needs "Workstation Server" when you have a builtin VNC via ssh-tunnel to directly access the VM and everything else is done with the network of the guest-vm itself? thank's god the bloatware gone away
Workstation Server is needed to have access to shared VMs with different user logins, and perform automatic VM starting along with the host. Replacement for this functionality was announced as 'suspected to come back in a future version', but it hasn't yet.
Not everybody has the same needs.