Closed rbdavis closed 3 years ago
zhoumgh
commented
3 years ago The Void (Linux) distribution https://voidlinux.org/
Void is not in the open-vm-tools compatibility list, refer to https://www.vmware.com/resources/compatibility/search.php?deviceCategory=software&details=1&vmwareTools=195&page=1&display_interval=100&sortColumn=Partner&sortOrder=Asc&testConfig=16
rbdavis
commented
3 years ago It may be the case that Void Linux is not specifically supported, but:
(1) This issue has been raised before in this forum as noted above (#425) and applies to other Linux distros running kernels > 5.4. That issue was closed for some mysterious reason but not in my impression explained or resolved in any satisfactory way.
(2) open-vm-tools was working perfectly well under an earlier Void installation of mine that was running an older kernel. Things stopped working only when I updated to a 5.x kernel.
FWIW, if open-vm-tools is not made to work with 5.x kernels I'm guessing it may not preserve much of a user base going forward.
zhoumgh
commented
3 years ago Here is the comment from dev:
Looking at the bug, the issue appears to be that vmw_vsock_vmci_transport wasn't loaded. The vmci driver is loaded, but not the vsock transport. The vsock transport should auto-load and register with the af_vsock module, if the PF_VSOCK is used by an app.
This is not an issue for all 5.X kernels - open-vm-tools works just fine on a Ubuntu 20.4 with open-vm-tools and kernel 5.11.
What is also interesting here - and in the other issue referenced - is that vhost_vsock is loaded. The issue seems to start from Linux 5.5, which was when the multi-transport support for vsock was introduced. Having vmci vsock transport and the vhost vsock transport loaded at the same time works fine on my 5.11 guest, so the module itself doesn't appear to be blocking the loading of the vmci vsock transport. Also, I don't see vhost_vsock auto-load on my system, so one guess is that there is some additional setup script for vhost, and that script does something that causes vmci vsock to not auto-load, e.g., register a guest to host vsock protocol.
rbdavis
commented
3 years ago Thanks for running this down further, zhoumgh!
I am not at all knowledgeable about kernel configs and runtime initialization. Any idea where I should look for the setup script you are talking about? I understand you may not be able to help specifically with Void, but can you tell me where on other Linux distros it might be found? Is there a specific open-vm-tools script that does this that I have to install?
zhoumgh
commented
3 years ago Here is a workaround from dev:
Void linux has vhost_vsock auto-loaded. Once one vsock transport is loaded, the other transports, e.g., the VMCI transport for vsock, won't auto-load, so they need to be loaded manually.
A work-around for the issue is to do modprobe vmw_vsock_vmci_transport before vmtoolsd is started.
rbdavis
commented
3 years ago Thanks a bunch, zhoumgh/dev, that does the trick!
I inserted into the file /etc/sv/vmtoolsd/run the two lines
/sbin/modprobe vmw_vsock_vmci_transport /sbin/sleep 3
just prior
to the
exec vmtoolsd
The sleep may not be necessary, but I can't login that fast anyway. ;->
stanguturi
commented
3 years ago Closing the issue as per the comments at https://github.com/vmware/open-vm-tools/issues/495#issuecomment-776200919 and https://github.com/vmware/open-vm-tools/issues/495#issuecomment-776235751
Hi all,
I just installed a new Void Linux VM running kernel 5.10.11 under macOS Catalina 10.15.6 running Fusion 11.5.7 and open-vm-tools 11.2.5. As soon as I configured vmtoolsd for boot-time startup by doing
# cd /etc/runit/runsvdir/current # ln -s /etc/sv/vmtoolsd .
the system console immediately began to display ioctl error messages:
[ 3.936342] Unknown ioctl 1976 [ 4.141205] Unknown ioctl 1976 ...
vmtoolsd remains present in the system process list but does nothing useful, i.e., it does not recognize VM root window resizes triggered by macOS user GUI action. When I remove the startup config link for vmtoolsd and reboot the ioctl errors go away.
This problem was reported previously in https://github.com/vmware/open-vm-tools/issues/425 as impacting Linux kernels > 5.4, but that issue was closed, at least with no obvious solution or workaround that I could glean from that thread.
I also read the discussion of this in https://bugzilla.redhat.com/show_bug.cgi?id=1821892 where there is a debate about whether or not certain VMWare-related kernel modules should be blacklisted. Reading elsewhere about general blacklisting procedures it seems like a rather murky swamp of complexity into which I'd prefer not to dive if possible, so I have not yet experimented with that. Here are my currently running modules which may be of interest:
# lsmod | grep vm vmw_balloon 24576 0 vmw_vmci 77824 1 vmw_balloon vmw_vsock_virtio_transport_common 32768 1 vhost_vsock vsock 40960 2 vmw_vsock_virtio_transport_common,vhost_vsock vmwgfx 360448 3 ttm 94208 1 vmwgfx drm_kms_helper 217088 1 vmwgfx drm 516096 6 vmwgfx,drm_kms_helper,ttm
The contents of /var/log/vmware-vmsvc-root.log certainly seem indicative of a problem:
[vmtoolsd] Tools Version: 11.2.5.26209 (build-17337674) [vmsvc] SOCKET failed to create socket, error 97: Address family not supported by protocol [vmsvc] SimpleSock: Couldn't get VMCI socket family info. ... [vmtoolsd] Plugin 'vmbackup' initialized. [vmtoolsd] Couldn't get vSocket family. [ warning] [vmsvc] SimpleSock: Couldn't get VMCI socket family info.
Can anyone tell me how to fix this? If blacklisting is required, exactly which modules should be blacklisted, and do I also need to rebuild my initramfs with the same blacklisting, i.e., are VMWare kernel modules built into or loaded by initramfs?
Thanks!