1322200 - Cannot launch remote console due to "Could not locate vmware-authd executable"

Status: RESOLVED WONTFIX

(Infrastructure & Operations :: Virtualization, task)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Today I tried to connect to one of our Linux VMs in SCL3 by using the remote console from within vSphere. In this case it is mm-ub-1404-32.qa.scl3.mozilla.com.

Doing so ends-up with a black window and the following message after a timeout:

"Unable to connect to the MKS: Could not locate vmware-authd executable."

Comment 1

[Chris Knowles [:cknowles]]

Forgive me if this response is jetlagged and makes little sense -

you make reference to using "remote console" - this is not the best method - as it seems just not to work very well.

Better methods for opening a console are:
1) On the VM you're interested in, click the picture of the console - this should open a new tab with the console.
2) On the VM you're interested in, click "Actions" and then click on "Open Console" - this should open a new tab with the console.

If those aren't working for you, Greg and I are at the work week - and would be happy to see what you're seeing - Let us know and we can try to arrange a time to meet up.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Option 1) is exactly what I'm doing to launch the remote console. Sadly I'm not at the work week, so I cannot show it directly to you.

Comment 3

[Chris Knowles [:cknowles]]

Can you try option 2?  

2) On the VM you're interested in, click "Actions" and then click on "Open Console" - this should open a new tab with the console.

As that shouldn't open a "remote console" which has a specific meaning in VMware land - there should be a link for "open remote console" under the picture.  

If that doesn't work - I'll have to do some more research and try getting back to you.  With the work week going on, our time is bit constrained - but I'll see if I can't make some headway.

What OS are you coming from - so I can see about finding similar sufferers.

Comment 4

[Chris Knowles [:cknowles]]

And another question I should have asked - are you able to connect to *any* of your VM's consoles?

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Interesting. Option 2) indeed works. In difference to option 1) it doesn't open the console via the "VMWare Remote Console" application outside of the browser, but shows it inside a browser tab. My OS is Mac OS X 10.11.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Sadly I cannot use the clipboard to copy and paste data via that way, but so far I could use SSH to do the edits, so it's not a hard-blocker for me. 

And to answer your question in comment 4, the same behavior with launching the remote console happens with other VMs including Windows.

Comment 7

[Chris Knowles [:cknowles]]

OK, yeah, the remote console app just needs way more access to the environment than seems prudent or necessary - I'm surprised that the clicking on the console image tries to open remote console, it doesn't for my mac.

I'll look into this some more, but the initial reading I'm doing seems to imply that this is a regular problem folks have with VMRC, and to use the other methods to open a console. 
 
Either way, clipboard wouldn't work, didn't know that was the overall goal.   

The work around of just using the Actions menu should work for you.  I will get back to you next week if I can find a good way of making it work for you.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I do not click the VM image, but the link "Open Remote Console" right below. I also have to add that the remote console was working fine for me not that long ago. So I assume maybe a recent update of the ESX infrastructure or a hardened security policy caused this regression?

Comment 9

[Chris Knowles [:cknowles]]

Alright - I can state that there hasn't been an update to the ESXi/vCenter systems for the last month or two.  

I am not aware of any changes to the firewalls that would affect this either.

From your error message, the links I'm finding refer to needing TCP ports 902/903 open to all of the ESXi hosts, which would lead to a series of ongoing maintenance issues, particularly considering that the web based console gets you access to the console, without that special access.

And as far as I'm aware, the port 902/903 access has never been granted to any of our users.  

Our recommendation is to use the web based console.

Comment 10

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Btw. I found a support document which describes how to activate copy/paste:
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1026437

Comment 11

[Chris Knowles [:cknowles]]

Yes, that option *could* be turned on - however, there are reasons why we haven't, I'd be interested in a discussion about reasons to go against that idea...

As the article mentions, the default off setting is done for security reasons 
Also, if we turn it on across the board by using the ESXi settings - would lead to concerns with upgrades and continued function.

For linux hosts, the ability to SSH in and do things, leads to console only being required for emergency/breakfix work - which is usually around getting SSH working again, so you can get in and do ore convenient work
For Windows hosts, similar work path, just replacing "SSH" with "RDP".

So, while I understand that clipboard access to the VMs would be convenient - it's by no means required, and it's against VMware best practice to turn it on.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I fully understand the above and would be ok, if you all decide against this. Meanwhile I found a command which I can issue for DISPLAY=:0 via the SSH shell to actually cause the necessary gsettings entry to be updated. So I don't have to use the X connection anymore.

Comment 13

[Chris Knowles [:cknowles]]

Alright - further reading hasn't gotten me past the problems with enabling remote console (the need to keep access to every user of console to every ESXi host) and the problems with clipboard enabling (similar needs for maintaining settings across ESXi reboots, and recommended security practice by VMware.)

That, combined with a working centralized web based console, and your workarounds - leads me to reso/wontfix this ... please poke at me if you have anything that you can't workaround, or questions.