Does this happen for local users?
Is this integrated into Active Directory?
How are the identity sources set up?
What happens if you remove all identity sources except for the default (localos and vsphere.local) ones? (Perform a snapshot before or be sure to note down your vCenter permissions).
Thanks for the reply!
This is an entirely standalone VMSA using all embedded services. There is no AD integration, etc. All of the users exist on the VMSA as local users and are the same ones that were carried over from the previous 5.1 instance of this server.
So, basically, I'm already dealing with strictly localos sources.
This delay does NOT happen when logging in from the vSphere client on Windows. This is strictly happening using the web client.
I'll add, too, that my gut feeling is that something under the hood is spinning until it times out... then letting the user in. I could be wrong, but that's how it feels.
Question is, where to check for this or related misbehavior...
Can you give permission to one @vsphere.local user to see if it is different?
I also think that something might run into a timeout.
Just to be sure you did not point any other vCenter Servers to the SSO of this appliance?
Can you recreate the issue and attach the log entries from the ds.log, vpxd.log, sts logs and virgo logs for that time frame?
As you are not experiencing the issue in the C# client I would deem SSO and Inventory Service not guilty, as well as so first log should be the virgo log to look at.
Actually, I think I just found on the timeout issue.
Watching the virgo logs, I see immediate successful authentication. It then hangs for precisely the time that it takes for this to timeout / hang:
[2014-03-08 01:58:21.014] [INFO ] vc-service-pool-5251 70001976 100026 200008 com.vmware.vise.vim.extension.VcExtensionManager Downloading plugin package from https://x.x.x.x:8543/vdp-plugin-package.zip
The x.x.x.x IP in there is my redaction, but it represents the IP of a long-retired VDP vm appliance that hasn't been in use for ages. It's odd that this never affected our last version or two of VMSA, but it's appearing to rear its head here as of 5.5 in the form of this timeout. Since that IP and host are no longer valid, the download it's attempting has to timeout before things proceed:
[2014-03-08 02:01:30.391] [ERROR] vc-service-pool-5251 70001976 100026 200008 com.vmware.vise.vim.extension.VcExtensionManager Error unzipping https://x.x.x.x:8543/vdp-plugin-package.zip to directory /var/lib/vmware/vsphere-client/vc-packages/vsphere-client-serenity/com.vmware.vdp-188.8.131.52, check if the server process has Write Permission on this machine. java.net.ConnectException: Connection timed out
The completion of the login happens immediately after that timeout and error above (about 3 minutes if you look at the timestamps).
So... problem found. Now, I need to figure out how the heck to solve it. I've not yet found a way to disable this VDP dependence.
Ah! Nevermind. I did some more digging and found this VDP removal procedure:
That worked like a charm. Login is back to normal now.
Hope this helps others if they encounter the problem!
Gonna dig a little on Monday if we have some known issues in that regard