vCenter 5.1 delay when opening vm console

[rvdl]

Last week we updated our vCenter Server from 5.0 to 5.1. And since that moment we experience some delay while opening vm console windows.

We used to have a black screen for about 1 or maybe 2 seconds before we got to see our vm console screen.

But now we have to watch a black screen  9 to 10 seconds before we get to see our vm console.

Has anyone got any ideas what i can do to speed up this process?

One weird thing i noticed.

In the vCenter database we used to have the following tables.

VPX_HIST_STAT1

VPX_HIST_STAT2

VPX_HIST_STAT3

VPX_HIST_STAT4

But now i see these tables are not here anymore, instead i see a lot of new tables.

VPX_HIST_STAT1_1

VPX_HIST_STAT1_2

VPX_HIST_STAT1_3

etc.

and also

VPX_HIST_STAT2_1...

VPX_HIST_STAT3_1...

VPX_HIST_STAT4_1...

etc

I have no idea if this have something to do with each other, but i can't check the fragmentation of the performance history anymore.

use vCenter5
go
dbcc showcontig (VPX_HIST_STAT1)
go

Gives error: Msg 5239, Level 16, State 1, Line 1
Unable to process object ID 2102298549 (object 'VPX_HIST_STAT1') because this DBCC command does not support objects of this type.

Any help would be appreciated, thank you.

[tpenn]

Thank you!  Editing the identity source to use ldap instead of ldaps worked for us as well.

[A_Alexander]

The ldap setting wasn't causing the delay I experianced, because the delay was happening when I was directly connected to the ESXi host bypassing any SSO crazyness.

In case a future reader is also having the delay when directly connecting to ESXi boxes, the solution that fixed my problem was adding DNS names to each ESXi host, then creating the corresponding A and PTR records in my DNS server.

Since these ESXi boxes were also part of a vCenter instance, I had to remove each host and re-add it via hostname before the lag also cleared up within vCenter.

With ESXi 5.0 we were able to run everything without DNS, and just used IP addresses for all connections.  Apparently 5.1 does not like that, and without the DNS set up all sorts of strange errors can pop up.

[jaredp]

Our environment is setup completely by DNS names, but we too were experiencing horrible lag.  I had tried spinning the vCenter SSO component off onto its own VM but it barely helped things at all.  Then I switched to using LDAP instead of LDAPS but again there wasn't a noticeable improvement.

The last thing I did was remove the local system (the SSO VM) from the list of default domains under Sign-On and Discovery -> Configuration.  As soon as I hit save, the console delay was reduced back down to about 2 seconds, which I can live with.

[godbucket]

Having the same issues. My case with VMware was opened for the performance graphs taking an extremely long time to load/draw (anything above 'realtime' of course). They recommended I query the VPX_HIST_STAT tables to find fragmentation, then defrag "the 4 VPX_HIST_STAT tables" but as you say... they're gone!!! Now there's hundreds of them, each named with an underscore and a number at the end. Need to get this done quick. Thanks for the quick response VMware

[Doxey]

For anyone currently still looking for a workaround -

Try logging into the vSphere client session by manually typing in your credentials rather than using the Windows Session check box.

[rvdl]

Logging in by manually typing the credentials is an excellent workaround for me too. I just tried it and it works. In that case you do not have to change any settings at all. Good job.

[chiendinhtran]

We have the same problem after upgraded ESXi 5.0 to 5.1.0a. After some testing we found a solution how to work around it. For us it was the SSO that was the problem. So our work around here is to uncheck "Use Windows session credentials" and log in with domain\user and it turn out to work just fine. Hope this will help

[JakeP]

Logging in manually worked here as well. I logged in to the web client as admin@system-domain, added our domain to the default domains, and then moved it to the top of the list in hopes that it would speed up the search. It did remedy having to specify the domain at login, but did not resolve the issue of having to log in manually for normal console speed. I'll open a case as well today.

[rvdl]

I just got a response from a very friendly and helpful VMware employee.

The problem we are experiencing is known and documented in the following KB http://kb.vmware.com/kb/2037408.

The fix is currently expected in vSphere 5.1 Patch 01 which is due by the end of December 2012.

Also the change in the VPX_HIST_STAT tables structure is normal in vCenter 5.1 according to this VMware employee.

The in-house DBA confirmed that with the new table layout in vCenter 5.1 there is no need to defrag the multiple VPX_HIST_STAT tables anymore because they hold a very small amount of information at a time compared to the old 4 tables.

So for now just be patience and let's hope that the upcoming patch will indeed solve our problem.

[MKguy]

I went into the edit identity source screen and saw noticed the Primary server URL and Secondary server URL were using ldaps://ldapservername1:3269 and ldaps://ldapservername2:3269.
So my next thought was, there must be a delay with the ssl connection.
Again my hunch was right.
I changed the Primary server URL from ldaps://ldapservername1:3269 to ldap://ldapservername1:389
Clicked Test Connection and he was quite fast with an approval notification.

Port 3269 is the Global Catalog service on a Domain Controller. Has anyone tried to use regular LDAPS on Port 636 for the identity sources?

This still preserves security and encryption as opposed to cleartext LDAP on port 389 and should work just as well.

Is there a specific reason why it defaults to connecting to the Global Catalog service in the first place?

[dUbVice]

Very same issue. 15 sec delay usually at the minimum, with the console sometimes never changing from the all black screen. The only fix at that point is to select a completely different vm and try to view it's console, and then switch back and try again. Or sometimes I have to minimize vSphere and click on another program, then come back and repeat.

Hopefully reverting vSphere back to 5.0 will help...

[Sato001]

I found solution here that complete

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

http://my-virt.alfadir.net/2012/11/15sec-delay-to-display-vmware-remote-console-when-client-is-not-c...

[chicagom]

I seems to be a known issue, regarding "Use Windows session authentication"

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

PS. running VMware vCenter Server 5.1.0b didn't fixed the problem for me

[lfunk]

Upgrading to 5.1b did not work for me either.

Changing the default domain did not work, nor did the LDAP vs LDAPS

The only thing that makes a difference is logging in without using the Windows session credentials.

[Gizmooz]

Even without using the Windows session credentials, after some time the console stops working.

the only options is to close vcenter client and start it again.

grz,

geert

[rmarul]

Sato001's solution worked for me. It actually sped up tons of tasks I wasn't even aware were slow in Windows.

Thank you!

[LesikL]

Sato001 - great thanks! http://my-virt.alfadir.net/2012/11/15sec-delay-to-display-vmware-remote-console-when-client-is-not-c... - this is really helpfull !!!

[KeithTudge]

We are on VMware vCenter Server 5.1 Update 1a and the issue still remains.

[rmarul]

Did you try to disable the root certificate update in the registry? This has fixed it for me 100% of the time.

[ragmon]

VMware KB: Virtual machine remote console screen takes up to a minute to display

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