Highlighted
Contributor
Contributor

Error "Unable to Connect to MKS" after upgrade to VMware Workstation 15.5.5

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:

  • Failed to start server on WebSocket pipe, error 1: Asyncsocket error
  • Expiring webmks ticket ....

Can anyone help? Thank you in advance

69 Replies
Highlighted
Contributor
Contributor

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.

-- Dejan
0 Kudos
Highlighted
Contributor
Contributor

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

-- Dejan
0 Kudos
Highlighted
Enthusiast
Enthusiast

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.

Does anyone know if this effects just upgraded machines or will this problem happen on a brand new ubuntu 20.04 / vmware 15.5.5 clean install?  Or in oher words does it not work out of the box?

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

vim.fault.GenericVmConfigFault

/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| W003: CUIMKS: cui::MKS::OnAcquireAbort (55770F594EC0): vim.fault.GenericVmConfigFault

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 had tried going back to 15.5.1 but as many others have found, had problems with it looking for old kernel source to compile.
  •   I noticed that trying to connect to my Ubuntu as the server from one of the windows machines or even itself resulted in a vmware server crash.
    •   after said crash I had to systemctl start both services
      • vmware.service
      • vmware-workstation-server.service
  • There were errors pertaining to the server-side crash in /var/log/vmware/hostd.log:

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

Highlighted
VMware Employee
VMware Employee

Moderator: Rather than posting long log dumps, please consider using the Attach function in the bottom-right of the post creator:

Screenshot 2020-06-08 at 16.39.55.png

0 Kudos
Highlighted
Enthusiast
Enthusiast

Sorry about that - I didn't notice the attach until just now.

Highlighted
Contributor
Contributor

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.

-- Dejan
0 Kudos
Highlighted
Contributor
Contributor

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:

  • "could not connect to port 903"
  • "could not connect to pipe \\.\pipe\vmware-authdpipe within retry period"

port 903 is not available/used on the PC which is sharing the VMs. Maybe this an issue?

Highlighted
Contributor
Contributor

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

-- Dejan
0 Kudos
Highlighted
Contributor
Contributor

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

-- Dejan
0 Kudos
Highlighted
Enthusiast
Enthusiast

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.

0 Kudos
Highlighted
Contributor
Contributor

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.

0 Kudos
Highlighted
VMware Employee
VMware Employee

Thanks for reporting this issue. We are aware of this issue and trying to resolve it.

Best Regards,

Yan

Highlighted
Contributor
Contributor

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.

0 Kudos
Highlighted
Contributor
Contributor

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?

0 Kudos
Highlighted
Enthusiast
Enthusiast

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.

0 Kudos
Highlighted
Contributor
Contributor

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.

0 Kudos
Highlighted
VMware Employee
VMware Employee

> 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.

Highlighted
Contributor
Contributor

> 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.

0 Kudos
Highlighted
Hot Shot
Hot Shot

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.