Pheckphul's Posts

@jimblue1    Are you still using 15.5.x on 20.04? I was running 15.5.7 and all was fine until I updated to 20.04.4 (with 5.4-110 kernel) a couple of days ago and rebooted. Now I can't get VM sharing to work. I get "Unable to connect to the workstation server. Please ensure that the server is running and that you are authorized to connect." This is from the Workstation GUI on the localhost; I haven't bothered to try remotely. UFW is disabled, BTW. It appears the Github repository you linked to only pertains to networking kernel modules, and I don't think they are my problem as both modules load and my VMs can connect to the outside world. My only problem is getting shared VMs to work.  I've checked, and vmware-hostd is running and pegging a CPU to 100%; I just can't connect to it. I tried reinstalling 15.5.7, but that didn't help. Additionally, I wasn't able to find where VMware stores the settings for the shared VM component (VMware Workstation Server) to verify that my settings were stored correctly during the new install. In the GUI the only field populated is the connection port. The storage location field is blank and not editable, neither when sharing is enabled or not. Any insight or suggestions would be appreciated.

As I noticed. V16 was released and they removed Remote Management support: Product Support Notices Removal of Shared VM feature Shared virtual machines (Workstation as server) has reached end of life and been removed from VMware Workstation 16. Removal of restricted virtual machines Restricted virtual machine has reached end of life and been removed from VMware Workstation 16. So, is this in a roadmap somewhere that this feature was going to be discontinued by a certain date? It sure as hell isn't EOL as it is still a useful feature; VMware just decided it wasn't in their interests to maintain.

Try this... edit ~/.vmware/preferences on your HOST machine. Add the below lines to the "preferences" file. pref.preferWebMKS = "FALSE" pref.preferWebRemoteDevice = "FALSE” Restart host services. So, where did you get this idea from? I just modified the preferences.ini on my Windows client running v15.5.6, which is connecting to a Linux v12.5.9 host, and restarted the VMware Workstation Server service and now I can connect to the Linux host without getting the damn MKS error. Also, VMware Workstation on my Windows client removed the pref.preferWebRemoteDevice = "FALSE" line from my preferences.ini. Thanks!

In another thread​ I was told by a VMware tech to upgrade from 12.5.7 to 15.5.6 on the host I was having issues with. Other than that, silence. My solution has been to ssh to the host and display the VMware console on my desktop via X. Not elegant, not a real solution, but it lets me get my work done.

We are sorry to brought the issue to you. Is that possible to upgrade your Workstation v12.5.9 to Workstation v15.5.6 on CentOS Host? I tested on my environment and the result shows it works fine if both Client and Server also run with Workstation 15.5.6. Sorry, no, else I would have. The processor isn't supported by v15.

> Well, another business day and not a peep out of VMware. FYI the forums are staffed by volunteers from within VMware and outside, i.e. if you want faster response times you would need to go through VMware's official support channel. With that said, there is now an internal bug report and it's being looked into. Thank you for letting me know how the forums are "staffed." I appreciate the fact that you are here. With that said, VMware should pay people to staff these "community" forums as they surely exist to minimize support costs. Also, thank you for letting us know that a bug report has been filed.

Yes, I agree.  It would be nice to know what time-frame we're looking at here.  Since this issue started I've been having to run a remote screen inside another remote screen just to get anything done.  That's not an easy thing to do. Well, another business day and not a peep out of VMware. Like you, I'm having to RDP to another Windows machine that has v15.5.2 on it in order to get work done with the hosted VMs. Pretty damn janky.

Would you please make sure both the client and server side use VMware Workstation 15.5.6 and try if can still reproduce the issue? Thanks a lot Sorry, but that isn't the environment within which I'm having the problem. I'm having an issue connecting to Workstation v12.5.9 build-7535481 running on a CentOS v7.8.2003 host. I have read nothing that states that this is not a supported scenario. This scenario worked fine until Workstation v15.5.6, thus something was changed that broke this. If you want instances of people having the exact same problem with v15.5.6 on both ends, then take a look at this thread. In that thread I've provided logs and indicated where the problem occurs within them. The logs state the client is attempting to connect via WebSocket when connections of this type are disabled. Seems like a pretty good indicator of where the problem is. 2020-06-13T02:28:28.704-07:00 info hostd[7F4CA72C9700] [Originator@6876 sub=Solo.Vmomi opID=ccd532fe user=XXX] Result: --> (vim.fault.GenericVmConfigFault) { -->    faultCause = (vmodl.MethodFault) null, -->    faultMessage = (vmodl.LocalizableMessage) [ -->       (vmodl.LocalizableMessage) { -->          key = "msg.mks.webSocket.enable", -->          arg = <unset>, -->          message = "WebSocket connections are disabled for this virtual machine." -->       }, -->       (vmodl.LocalizableMessage) { -->          key = "msg.asyncsocket.generic", -->          arg = <unset>, -->          message = "Asyncsocket error" -->       } -->    ], -->    reason = "WebSocket connections are disabled for this virtual machine.", -->    messageInfo = (vim.vm.Message) [ -->       (vim.vm.Message) { -->          id = "msg.mks.webSocket.enable", -->          argument = <unset>, -->          text = "WebSocket connections are disabled for this virtual machine." -->       }, -->       (vim.vm.Message) { -->          id = "msg.asyncsocket.generic", -->          argument = <unset>, -->          text = "Asyncsocket error" -->       } -->    ] -->    msg = "WebSocket connections are disabled for this virtual machine. --> Asyncsocket error --> " --> }

I'm sure it is. I and another Windows user responded in https://communities.vmware.com/message/2956744 that we have the same issue. I'm having it with Windows clients connecting to CentOS host. I'm not too pleased that we haven't gotten a response beyond "Yeah, we know this is happening."

Thanks for reporting this issue. We are aware of this issue and trying to resolve it. Best Regards, Yan It has been more than two business days and no update in this thread. Would you please provide a status update?

Workstation v15.5.6 on Windows 8.1 x86-64 10.8.26.11 [client system] Workstation v15.5.2 on Windows 10 1909 x86-64 10.8.26.47 [client system] Workstation 12.5.9 build-7535481 on CentOS Linux release 7.8.2003 (Core)  10.8.26.101 [sharing system] I recently upgrade to v15.5.5 from v15.5.2 and didn't have this problem. I upgraded to v15.5.6 today and started getting the following error: Unable to connect to the MKS: vim.fault.GenericVmConfigFault Unlike someone else in this thread stated, when my client attempts to connect to the shared VMs it doesn't kill vmware-vmx. I can immediately connect from my v15.5.2 system without issue. In the hostd.log file on the CentOS sharing system there there are messages related to WebSocket connections not being enabled for the shared virtual machines when the connection fails from the v15.5.6 client. There is no mention of WebSocket connections when the successful connection is made by the v15.5.2 client. This sounds like something that should be examined. At the end of the hostd.log file I'm attatching you can a successful connect followed by a failed one right before the file ends. Hopefully this helps.