This morning I faced a strange issue in my vSphere Lab when a wanted to login to VAMI interface – of course to install the newly released “vSphere 6.7 U1” update.
I opened the VAMI URL for my Platform service controller (PSC): https://<FQDN>:5480 and typed in my root credentials as a normally would. However, the only thing that showed on the screen was a message saying: “Unable to login”.
After this I tried to type in my password multiple times to make sure that I was actually typing in the correct one, but still, I just got the same error message.
Next, logically step for me was to try to same credentials on the console of the PSC, so I opened my vCenter (that actually still worked!), located my PSC and accessed the console from there. At my first attempt my root password was actually rejected (I might type it in wrong) but second attempt actually let me log in.
From there I saw the message “[ERROR]: Failed to connect to service.” and that gave me a clue that some services was not running as intended!
In the console, I tried to list all the services using this command:
And there I could actually see that “applmngt” and “vmware-statsmonitor” services was actually stopped.
I typed the following command to start all services that where not in the running state:
service-control --start --all
After that, login on the VAMI web interface worked again! Hooray!
Thanks. That helped :-).
I also encountered this problem following the update of 18.104.22.16800 to 22.214.171.12400
The solution to start the services manually works.
But if I restart vCenter Server Appliance, the same problem occurs.
It is not a definitive solution …
With best regards.
applmgmt service is in charge of VAMI web interface. If the service stop you can not log in. So just enter the cmd [ service-control –start applmgmt ] and you are good to go.
Same issue here after upgrading from 126.96.36.19900 to 188.8.131.52000 (or 184.108.40.206000 which has the same issue):
root@photon-machine [ ~ ]# service-control –status
applmgmt vmcam vmware-imagebuilder vmware-mbcs vmware-netdumper vmware-rbd-watchdog vmware-statsmonitor vmware-vcha vsan-dps
lwsmd pschealth vmafdd vmcad vmdird vmdnsd vmonapi vmware-analytics vmware-certificatemanagement vmware-cis-license vmware-cm vmware-content-library vmware-eam vmware-perfcharts vmware-pod vmware-postgres-archiver vmware-rhttpproxy vmware-sca vmware-sps vmware-sts-idmd vmware-stsd vmware-topologysvc vmware-updatemgr vmware-vapi-endpoint vmware-vmon vmware-vpostgres vmware-vpxd vmware-vpxd-svcs vmware-vsan-health vmware-vsm vsphere-client vsphere-ui
Starting the services manually indeed solves the issue temporarily. I then also upgraded to 220.127.116.11100, same issue.
Did anyone find why they don’t start automatically anymore? I opened a case at VMWare…
I haven’t seen the problem in the newer version – but please post the solution from VMware support, when you get it 🙂
They don’t have a solution. “Try to reboot and see if it works now that you were able to login”. And if it still doesn’t work, open a new ticket to re-enable automatic start. As it’s a RHEL/CentOS base (I think) I should be able to solve that one 🙂
And indeed only applmgmt is needed, so: service-control –start applmgmt
Ok, I had a useful reply this time, which solved the issue. The problem is that applmgmt depends on vmware-statsmonitor which has a too short start timeout. The solution was to edit /etc/vmware/vmware-vmon/svcCfgfiles/statsmonitor.json, and add
“ApiHealthFile” : “/var/vmware/applmgmt/statsmonitor_health.xml”,
+ reboot and done, problem solved.
Thanks for the follow up.
Thanks for this Steven. I had the same problem recurring after a reboot and your solution of adding the timeout has fixed it!
Hi – the VMware KB (68149, linked by Mike T below) also suggests changing the timeout in /etc/vmware/vmware-vmon/svcCfgfile/applmgmt.json to 600 (the line already exists, but the default timeout is 60s). I found I needed to make both changes to fix the issue for me.
Official VMware KB on this, worked for me. https://kb.vmware.com/s/article/68149
Indeed, the solution provided in the VMware KB works.
On the other hand, the modifications explained in the KB have to be redone with each update of vCenter since the files are overwritten during the update.
Thank you! worked like a charm. Appliance 18.104.22.168000.
Same Issue here, Same resolution. Applied the Vmware KB solution to avoid this issue for the future reboot of VCSA.
superb, it worked.. well explained…
Hi, I just did an upgrade of my production VCSAs from 6.7.0 11727113 to 6.7.0 Appliance 6.7 U3f (6.7.0.
15976728 released April 9, 2020) and I would like to thank you, the “service-control –start –all” got VAMI back up and running.
Thanks, worked like a charm!
Had to do this after upgrading to 22.214.171.124000
Thank you! That got me out of a bind.