Hello,
I upgraded my workstation to latest version 15.5.5. Now I cannot connect to shared VMs on another VM Workstation (V12.9) anymore.
The following error message appears (image type forbidden?):
"Unable to connect to the MKS:
vim.fault.GenericVmConfigFault."
The log file of the remote VM indicates:
Can anyone help? Thank you in advance
Hi,
I have probably the same problem:
- Host: Ubuntu 20.04
- 2 networks: eno1, eno2
- 1 bond network: bond0 (LACP)
- VMWare Workstation Pro 15.5.5 build-16285975
- several VMs running as Shared VMs on port 443
When I connect from different PC as Connect to Server, I get "A connection to the server could not be established".
Then I ssh -X to linux and start vmware from command line. This vmware also doesn't see any Shared VMs as well.
Then I have to restart vmware-workstation-server service:
drodiger@mainserver:~$ sudo service vmware-workstation-server stop
drodiger@mainserver:~$ sudo service vmware-workstation-server start
drodiger@mainserver:~$ sudo service vmware-workstation-server status
lip 04 08:08:18 mainserver systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
lip 04 08:08:18 mainserver systemd[1]: vmware-workstation-server.service: Found left-over process 40419 (vmware-vmx) in control group while starting unit. Ignoring.
lip 04 08:08:18 mainserver systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
lip 04 08:08:18 mainserver systemd[1]: vmware-workstation-server.service: Found left-over process 47045 (vmware-vmx) in control group while starting unit. Ignoring.
lip 04 08:08:18 mainserver systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
lip 04 08:08:18 mainserver systemd[1]: vmware-workstation-server.service: Found left-over process 49075 (vmware-vmx) in control group while starting unit. Ignoring.
lip 04 08:08:18 mainserver systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies.
And vmware started from the server (ssh -X) see the VMs running again.
But if I click on Connect from different PC with VMware Workstation (Connect to Server), it fails again, so whole vmware-workstation-server becomes unresponsive.
I also changed Bridged network configuration, not to use bond0, and only uses eno1/eno2 networks, but same issue.
Version before didn't had this problem.
I tried to reinstall 15.5.2 and problem is the same. Access from outside stops the vmware-workstation-server service.
I tried to reinstall 15.5.1 and vmnet doesn't install in /lib/modules probably because there is no support for kernel 5.4.
I downloaded git repository with fix and installed it, but the problem is still the same.
I think, the problem is in 15.5.X which doesn't support Ubuntu 20.04 correctly (on 19.10 everything worked, but I had to install new version ;-( )
Or at least kernel 5.4.0-33 ?
Linux mainserver 5.4.0-33-generic #37-Ubuntu SMP Thu May 21 12:53:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Hi all,
I have this problem too after updating things. I'm on Ubuntu. I recently did a dist-upgrade to 20.04 LTS and shortly after was asked by vmware if I wanted to upgrade to 15.5.5 (from 15.5.1). I did this and it connecting to remote with the same error "Unable to connect to the MKS: vim.fault.GenericVmConfigFault".
I suspect the vmware 15.5.5 was not ready for the Ubuntu upgrade implying vmware needs to get working on a 15.5.6 patch yesterday! When I called support just now they didn't acknowledge any problem when I told them the error message and what I had done with upgrading. They said they never heard of it.
It definitely effects both the shared VM server and client side of things. I'm connecting to windows machines running shared VM's on version 12.
There are logs being produced in /tmp for both root and user. I grabbed the portion of the log that directly corresponds to the remote attempt and error; Here it is in all it's glory:
In the log below you can see
/tmp/vmware-max/vmware-ui-2551.log: (excerpts)
========================================================================================
...
2020-06-08T08:57:31.976-04:00| vmui| I005: DoAcquireTicket
2020-06-08T08:57:31.976-04:00| vmui| I005: DoAcquireTicket - issuing ticket acquisition request
2020-06-08T08:57:31.976-04:00| vmui| I005: DoAcquireTicket - issuing WEB_MKS_TICKET ticket acquisition request
2020-06-08T08:57:31.988-04:00| vmui| I005: CUIMKS: cui::MKS::OnSetAttachError (55770F594EC0): -1
2020-06-08T08:57:32.131-04:00| vmui| W003: MKSControlClient: GetScreenCopy: abort because MKSControl is not connected.
...
========================================================================================
Notes:
I hope this information helps someone to figure out a solution to this or perhaps prompt the vmware dev team to produce a proper patch.
-- Max
Moderator: Rather than posting long log dumps, please consider using the Attach function in the bottom-right of the post creator:
Sorry about that - I didn't notice the attach until just now.
BTW, 15.5.6 didn't solve the problem. Connecting to remote Shared VMs Server still stops the vmware-workstation-server service, which you need to restart to work locally.
Hi,
Yes, I confirm, upgrade to 15.5.6 does not solve the issue.
some additional infos:
In our environment the server which hosts the shared VMs is VM workstation V12.9. We us different versions of VMWorkstation as clients. After upgrading the server from V12.2 to V12.9 no client is able to connect to the MKS of the shared VMs anymore. They provide different error messages:
port 903 is not available/used on the PC which is sharing the VMs. Maybe this an issue?
New error with 15.5.6:
Unable to connect to the MKS: Console access to the virtual machine cannot be granted since the connection limit of 0 has been reached.
On our server, port 902/903 are not listening:
drodiger@mainserver:~$ sudo service vmware-workstation-server start
drodiger@mainserver:~$ sudo netstat -talnp|grep vmw
tcp 0 0 127.0.0.1:8307 0.0.0.0:* LISTEN 1680580/vmware-host
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 1680580/vmware-host
tcp6 0 0 :::443 :::* LISTEN 1680580/vmware-host
But, on my laptop:
drodiger@rodigerlaptop1:~$ sudo netstat -talnp|grep vmw
[sudo] password for drodiger:
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 11800/vmware-hostd
tcp 0 0 0.0.0.0:902 0.0.0.0:* LISTEN 11773/vmware-authdl
tcp 0 0 127.0.0.1:8307 0.0.0.0:* LISTEN 11800/vmware-hostd
tcp 0 0 127.0.0.1:443 127.0.0.1:43418 ESTABLISHED 11800/vmware-hostd
tcp 32 0 192.168.41.169:40124 23.202.52.29:443 CLOSE_WAIT 55870/vmware
tcp 0 0 127.0.0.1:43438 127.0.0.1:443 ESTABLISHED 55870/vmware
tcp 0 0 127.0.0.1:443 127.0.0.1:43438 ESTABLISHED 11800/vmware-hostd
tcp 0 0 127.0.0.1:43418 127.0.0.1:443 ESTABLISHED 55870/vmware
tcp6 0 0 :::443 :::* LISTEN 11800/vmware-hostd
tcp6 0 0 :::902 :::* LISTEN 11773/vmware-authdl
tcp6 0 0 ::1:8307 :::* LISTEN 11800/vmware-hostd
tcp6 1 0 ::1:8307 ::1:60424 CLOSE_WAIT 11800/vmware-hostd
tcp6 0 0 ::1:60444 ::1:8307 ESTABLISHED 11800/vmware-hostd
tcp6 0 0 ::1:60464 ::1:8307 ESTABLISHED 11800/vmware-hostd
tcp6 0 0 ::1:8307 ::1:60464 ESTABLISHED 11800/vmware-hostd
tcp6 0 0 ::1:8307 ::1:60444 ESTABLISHED 11800/vmware-hostd
And from server, I can connect back to my laptop without any problems, since 902 is listening
I started manually vmware-authdlauncher, but same issue, even if it shows 902 is listening
drodiger@mainserver:~$ sudo vmware-authdlauncher
drodiger@mainserver:~$ sudo netstat -talnp|grep vmw
tcp 0 0 127.0.0.1:8307 0.0.0.0:* LISTEN 1780389/vmware-host
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 1780389/vmware-host
tcp 0 0 0.0.0.0:902 0.0.0.0:* LISTEN 1759422/vmware-auth
tcp 0 0 127.0.0.1:51504 127.0.0.1:6010 ESTABLISHED 1709860/vmware-tray
tcp 0 0 127.0.0.1:8307 127.0.0.1:57450 CLOSE_WAIT 1780389/vmware-host
tcp6 0 0 :::443 :::* LISTEN 1780389/vmware-host
tcp6 0 0 :::902 :::* LISTEN 1759422/vmware-auth
But, after I connect from laptop, then some of the ports are closed (mainly 443).
drodiger@mainserver:~$ sudo netstat -talnp|grep vmw
tcp 0 0 0.0.0.0:902 0.0.0.0:* LISTEN 1759422/vmware-auth
tcp 0 0 127.0.0.1:51504 127.0.0.1:6010 ESTABLISHED 1709860/vmware-tray
tcp6 0 0 :::902 :::* LISTEN 1759422/vmware-auth
And then I need to restart the vmware-workstation-server service
Same here.
I just tried 15.5.6 and I still get the same error "Unable to connect to the MKS: vim.fault.GenericVmConfigFault". I'm not hosting anything on my Ubuntu laptop at the moment, just using it as a viewer. I just can't remote connect to any other hosted VM's on my network regardless of what OS or Vmware version the host runs.
I have the same issue-- I'm using Workstation 15.5.6 on Windows to connect to Workstation 15.5.0 on Linux.
When I attempt a connection from 15.5.6, I see the following in /var/log/vmware/hostd-<pid>.log on the Linux box (timestamps and other info removed):
Task Created : haTask-14-vim.VirtualMachine.acquireTicket-1422
RecordOp ASSIGN: info, haTask-14-vim.VirtualMachine.acquireTicket-1422. Applied change to temp map.
[RecordAndNotifyChangeInt] No listeners on haTask-14-vim.VirtualMachine.acquireTicket-1422 - bailing out
Issue ticket message: Ticketed 'webmks' connections are disabled for this virtual machine.
AdapterServer caught exception: N3Vim5Fault20GenericVmConfigFault9ExceptionE(Fault cause: vim.fault.GenericVmConfigFault
--> )
Task Completed : haTask-14-vim.VirtualMachine.acquireTicket-1422 Status error
Activation [N5Vmomi10ActivationE:0x00007f247c049970] : Invoke done [acquireTicket] on [vim.VirtualMachine:14]
Arg ticketType:
--> "webmks"
Throw vim.fault.GenericVmConfigFault
That seems to be the source of the fault... but I found no information about what configuration to change to either enable ticketed webmks connections for virtual machines, or how to make Workstation 15.5.6 connect in a way that doesn't use tickets.
Thanks for reporting this issue. We are aware of this issue and trying to resolve it.
Best Regards,
Yan
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.
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?
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.
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.
> 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.
> 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.
they surely exist to minimize support costs
That's not fair to say. The VMware Community (as are most products' support forums) is not here to just "minimize costs" (and I know the type of companies you have in mind) but to filter out the trivial problems, help beginners in the field and solve frequent issues that e.g. are mentioned in the Release Notes and that nobody reads. Cost is always a factor, but it's not in higher priority than customer satisfaction. Yes, Moderators are 100% volunteers, and yes, VMware employees drop by unannounced every day and I am guessing issues reported here that appear to affect many users are promptly escalated to the proper support division. It's all a matter of efficiency.
It's a different model than those used in e.g. open source development, but all it needs to work is good will, trust, optimism, participation and a bit of patience.