VMware – Possible Clues to Failure?

OPINION/SPECULATION:

After more tests, I am still encountering the odd behaviour of VMware (14.1.2 with vmmon patch) and Kernel 4.18-rc1, but did notice one possible clue..

Looking at the # systemctl status vmware.service output, it includes the following:

Jun 18 01:02:03 rgtest vmware[5663]: Blocking file system[FAILED]

I think this should not be there, as VMBlock has been obsolete for a long time now, and the functionality has been taken over by kernel code, including FUSE (File system in User Space)..     And… it turns out that there have been some changes to FUSE in 4.18-rc1:   http://lkml.iu.edu/hypermail/linux/kernel/1806.0/01405.html

So.. it may be that changes to FUSE have caused VMware – including userland functions – to be ‘confused’?

More investigation needed, of course..

Robert Gadsdon.   June 18, 2018.


Comments

VMware – Possible Clues to Failure? — 5 Comments

  1. Good catch but I’m not sure it’s related to FUSE changes. Starting the “blocking filesystem” leads to executing /usr/lib/vmware/bin/vmware-vmblock-fuse with arguments “-o subtype=vmware-vmblock,default_permissions,allow_other /var/run/vmblock-fuse”. But vmware-vmblock-fuse is actually using a wrapper named appLoader which first loads some dynamic libraries and then executes itself again with the same parameters (not sure what is the purpose of this exercise as execve() drops everything, maybe it sets some environment variables). Except the last parameter, “/var/run/vmblock-fuse” is missing for some reason, leading to error message “fuse: missing mountpoint parameter”.

    However, this “blocking filesystem” is AFAIK only used for directory sharing which is something I don’t use. I rather suspect that other strange problem are also symptoms of the same issue: appLoader losing its last argument somehow.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.