Hey Josh, Thanks so much for looking into my issue. sunnyflunk did some research when I first encountered the problem and he said it has nothing to do with the kernel. He went to bed after that so he didn't look into this any further.

Side Note: Solus as a VBox guest is really slow, should i create a task for that too?

Side Note: Solus as a VBox guest is really slow, should i create a task for that too?

We don't target being installed in VirtualBox.

Still doesn't work :/
How can I give you more info?

Also, the VM feels a bit slower now, I can't really know if that's really the case but it just feels a bit sluggish, not much though. Resizing any window (like gnome-system-monitor) inside the vm makes the cpu usage spike to ~40%

Same problem here.

VMware ESXI 6.7 (Build: 8169922)
Solus-budgie 4.18.11-93

You can try the following as a workaround:

1. Open a terminal and run killall vmtoolsd
2. Then start the vmtools again with sudo bash -c 'vmtoolsd &'

This seems to fix it for me. Looks like a permissions issue. I didn't have the time to investigate it further.

It stops working after resizing the window a few times though.

Interesting...
I mainly use the Fullscreen feature and it keeps working without issues.
I tried resizing multiple times (about 20, didn't count) and the vmware player window itself didn't want to resize anymore. Fullscreen mode kept working.
After pausing the Solus guest and starting it again. I could resize vmware player again without issues.

Maybe it's two issues at the same time?
PS: My host is a Windows 10 1804 machine.

I grabbed the journal for doing the steps @belzael mentioned.

@Girtablulu and I updated the package open-vm-tools to version 10.3.5 and added support for the current kernel. I tested the package locally with the same results as before.

I attached the journal log. Maybe you can get some information out of it.

I don't know about the segfault of @Gaming4LifeDE but I guess that otherwise the problem could be easily solved by adding a systemd service that runs /usr/bin/vmtoolsd when the machine starts.
Also I see the package is build against the lts kernel only, is there a reason for this (it should only impact vmhgfs which is used for the file sharing feature)

I can look into adding a service file, but would be suprised if it would work

Per request of @DataDrake, here's the output of ldd /usr/bin/vmtoolsd:

	linux-vdso.so.1 (0x00007ffd05dc1000)
	libvmtools.so.0 => /usr/lib/libvmtools.so.0 (0x00007fae87e75000)
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fae87e54000)
	libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00007fae87e4e000)
	libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x00007fae87dfa000)
	libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007fae87ce0000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007fae87af9000)
	libdnet.so.1 => /usr/lib/libdnet.so.1 (0x00007fae878e5000)
	libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fae878e0000)
	librt.so.1 => /usr/lib/librt.so.1 (0x00007fae878d6000)
	libicui18n.so.63 => /usr/lib/libicui18n.so.63 (0x00007fae875fb000)
	libicuuc.so.63 => /usr/lib/libicuuc.so.63 (0x00007fae87428000)
	libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007fae873b4000)
	libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007fae8715b000)
	/usr/lib64/ld-linux-x86-64.so.2 (0x00007fae87f2b000)
	libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fae87140000)
	libffi.so.6 => /usr/lib/libffi.so.6 (0x00007fae87136000)
	libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007fae870be000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fae86f28000)
	libm.so.6 => /usr/lib/libm.so.6 (0x00007fae86d86000)
	libicudata.so.63 => /usr/lib/libicudata.so.63 (0x00007fae85398000)