4) With Kernel 4.4.68-2-default WS fails to compile since it cannot find file version.h. Version.h is nowhere to be found in any sources. This happened with some versions of openSUSE many years ago but there version.h could be found otherwise.

5) I have a choice. I can go back to kernel 4.4.62-18.6-default or I can use kernel-4.4.68-2-vanilla which I know will compile and has version.h. The other possibility of course is to use another distro. Unfortunately I'm finding that Debian 9 has problems with recent upgrades.

If anybody knows how I can version.h for the current Leap kernel I'd appreciate it.

Hopefully an openSUSE Kernel dev uses VMware Workstation but I guess I'll need to post to the openSUSE forums.

Adding the latest openSUSE Leap 42.3 kernel reposI find kernel 4.4.68-5.g47b5464-default fails to compile because version.h is not found but kernel 4.4.68-5.g47b5464-vanilla will compile but the Workstation server still fails to start.

I think I will live with this for awhile since Virtualbox 5.1.23-115382 (a test build) compiles and run just fine and I like openSUSE otherwise and the Windows version of WS works completely on Windows Server 2016 which I can boot to (as well as Windows 10 where I'm using Hyper-V).

Make sure you have the vanilla kernels installed also. I run openSUSe also, and anything after 10.1 both the kernel source and vanilla kernels need to be installed to compile Workstation.

**EDIT: DO NOT install the vanilla kernels. I am have issues connecting to vSphere server after an upgrade, and noticed that the vanilla kernels were not installed. I re-installed them, and Workstation will not run at all now. But do as mkubecek states and install the default kernels.

Basically, WS 12.5.7 doesn't really work on openSUSE Leap 42.3 even with a vanilla kernel. I will compile but WS Server won't start so no Shared VMs. Can't connect to a ESXiVM either. I may as well install Tumblewee <sigh>

I don't know, if VMWare workstation uses the same modules as the player. If not, I could put them on my site too, if someone sends me either the patched versions or the unpatched ones. Use the email address in the imprint ("Impressum") on the site.

I'm affected by the issue discussed here, but it's not really time critical for me: As it seems that Hendrik narrowed down the issue and has found a solution, will his changes find it's way back to VMware? Any ideas if and when this bug will be fixed?