vCenter 5.5 Web Client Login - Authenticating hangs for minutes...

[amahler]

I just finished an upgrade on the VCSA from the latest 5.1 to, I assume, the latest 5.5.0b. Upgrade was shockingly fast and clean and, thus far, the only major thing out of sorts (aside from the missing environment variable for Java causing remote consoles to fail - I fixed that) is the login process.

This is a very simple VCSA running all embedded services (database, SSO) with no outside authentication or other complexities. The few user accounts and passwords appear to have come across just fine as well.

Every login works, but the animated "Authenticating" progress bar hangs on the screen for several minutes before allowing the user access. Once in, things appear to work fine (at their usual level of sluggishness, but no worse than 5.1 ever was for us).

Any thoughts on the source of this interminable hang?

- Aaron

[admin]

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

[amahler]

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.

Thoughts?

- Aaron

[amahler]

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

- Aaron

[admin]

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.

[amahler]

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

Any thoughts?

- Aaron

[amahler · Accepted solution]

Ah! Nevermind. I did some more digging and found this VDP removal procedure:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=203835...

That worked like a charm. Login is back to normal now.

Hope this helps others if they encounter the problem!

- Aaron

[admin]

Gonna dig a little on Monday if we have some known issues in that regard