loungehostmaste
Enthusiast
Enthusiast

Linux 5.8 host-support like VirtualBox this year or next?

Jump to solution

> 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

0 Kudos
1 Solution

Accepted Solutions
mkubecek
Enthusiast
Enthusiast

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.

  • replace /usr/bin/vmware-modconfig by a link to /bin/true
  • edit /usr/bin/vmware (or /usr/bin/vmplayer) so that it does not run vmware-modconfig
  • run /usr/lib/vmware/bin/vmware directly without the wrapper script

View solution in original post

14 Replies
loungehostmaste
Enthusiast
Enthusiast

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?

0 Kudos
loungehostmaste
Enthusiast
Enthusiast

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?

loungehostmaste
Enthusiast
Enthusiast

a new major release is not the answer, it's that simple

0 Kudos
watcher1
Enthusiast
Enthusiast

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

0 Kudos
loungehostmaste
Enthusiast
Enthusiast

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

0 Kudos
loungehostmaste
Enthusiast
Enthusiast

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

0 Kudos
loungehostmaste
Enthusiast
Enthusiast

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

0 Kudos
mkubecek
Enthusiast
Enthusiast

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.

  • replace /usr/bin/vmware-modconfig by a link to /bin/true
  • edit /usr/bin/vmware (or /usr/bin/vmplayer) so that it does not run vmware-modconfig
  • run /usr/lib/vmware/bin/vmware directly without the wrapper script

View solution in original post

loungehostmaste
Enthusiast
Enthusiast

indeed, that works - thanks!

[root@srv-rhsoft:~]$ rm /usr/bin/vmware-modconfig

[root@srv-rhsoft:~]$ ln -s /usr/bin/true /usr/bin/vmware-modconfig

loungehostmaste
Enthusiast
Enthusiast

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

0 Kudos
loungehostmaste
Enthusiast
Enthusiast

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

0 Kudos
mkubecek
Enthusiast
Enthusiast

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).

0 Kudos
loungehostmaste
Enthusiast
Enthusiast

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

0 Kudos
loungehostmaste
Enthusiast
Enthusiast

in other words: if KVM and Proxmox would have existed in 2008 i would never have touched all that [removed by moderator]

0 Kudos