VMware Cloud Community
rvdl
Enthusiast
Enthusiast

vCenter 5.1 delay when opening vm console

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.

Reply
0 Kudos
40 Replies
KlausK
Contributor
Contributor

I am seeing the same problem after my upgrade. Unfortunately I have to find a solution still.

Reply
0 Kudos
JurijC
Contributor
Contributor

Same here, except that the delay can get up to a minute or so.

Reply
0 Kudos
Bigi201110141
Enthusiast
Enthusiast

Same here. Is this a scam to force us to move to the Web Version?

Reply
0 Kudos
JurijC
Contributor
Contributor

Hope not, because if we thaught the Client was slow, Webclient is like drinking concrete through a straw.

Reply
0 Kudos
JurijC
Contributor
Contributor

I was unfair to Webclient, I allocated more RAM to the vCenter appliance (2GB -> 4GB) and now it runs much smoother!

(Yes, I know, that the default configuration is 8GB, but that is just a bit too much for managing 3 hosts with 25 VMs)

Reply
0 Kudos
Hrrflck
Contributor
Contributor

Same here. Getting complaints from the users even, something I'm not used to. Will try opening a support case, see if that helps.

Reply
0 Kudos
ashleyw
Enthusiast
Enthusiast

yep same here on v5.1. All hosts running v5.1, all VMs runing HW level 9, all VMware tools up to date.

Only hack we've found is to close the vSphere client and reopen it again, then the console screen is visible again.

Yeah it makes things very difficult for us with our 11x5.1 hosts, and about 400 VMs.

The web client is too clunky for us at this stage.

Reply
0 Kudos
doubleH
Expert
Expert

Thank you for your message. I am currently out of the office and will return October 1.

For support related issues please contact the IT Service Desk servicedesk@camhydro.com or x2700.

Thank you

Heath

If you found this or any other post helpful please consider the use of the Helpfull/Correct buttons to award points
Reply
0 Kudos
Bigi201110141
Enthusiast
Enthusiast

Anyone have any updates on this? vSphere 5.1 Client is pretty much unusable now.

Reply
0 Kudos
Tapas201110141
Contributor
Contributor

I am also facing the same problem. Please help somebody.

Reply
0 Kudos
eiokolo81
Contributor
Contributor

I am also facing the same issue. I took one of my 5.1 hosts out of vCenter and tried to switch  between VM's and I still had a 10 sec delay with the console display.  Downgraded the same host to ESX 5.0 U1 and the delay was gone. Then, I  joined the 5.0 host to the vCenter 5.1 infrastructure and the delay  started again. I have a case open with customer support, but it's not going very far...

Reply
0 Kudos
rvdl
Enthusiast
Enthusiast

Unfortunately I still haven't found a solution yet.

But i did find out that when i connect the vSphere Client 5.1.0 (786111) to the ESXi 5.1.0 host (799733) the delay when opening a VM console is back to normal (1 or 2 seconds). While opening the same VM console via the vCenter Server 5.1.0 (799731) the delay is about 9 or 10 seconds.

I did a dbcc indexdefrag on all the VPX_HIST_STAT tables. The Logical Scan Fragmentation was over 95% and is now below 10%.

The problem however did not go away.

We also noticed that when we used HP dataprotector to connect to vCenter, it took a long time to generate a list of Virtual Machines.

Maybe it hasn't got anything to do with it, but still, it feels strange.

Our vCenter Server is a Virtual Machine with 8GB RAM (we tried 16GB, but with no performance increase), 4 CPU, 50GB System HD and 40GB Data HD.

We use 1 nic with ipv4 preferred over ipv6.

To set ipv4 preferred over ipv6 we made the following changes in the registry.

You need to create a 32 bit DWORD called "DisabledComponents" nder "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters".

Give it the value "0x20"

Still searching for a solution ;-(

Reply
0 Kudos
Bigi201110141
Enthusiast
Enthusiast

Good test Harry. So far nothing from vmware regarding these cases. All open and no resolution in sight.

Reply
0 Kudos
Bigi201110141
Enthusiast
Enthusiast

Anyone have any updates?

Reply
0 Kudos
dutchyis007
Contributor
Contributor

Yeah same issue here. it's a joke. 5.0 console had a 1 maybe 2 second delay. 5.1 has up to 10 sometimes 15 second delay and sometimes it just doesnt open at all. Current workaround for me is to right click and open console which seems to give it a kick.

I'll prob log a case soonish - will post results if there are any

cheers

Reply
0 Kudos
Bigi201110141
Enthusiast
Enthusiast

Yes please log a case. The more noise we make the faster it will get fixed.

But the amount of issues is stagarring. I am not sure if they will be able to fix everything.

Maybee with ESXi 6.0

Reply
0 Kudos
A_Alexander
Contributor
Contributor

I have had a case logged with tech support against this issue for a few days now, and we are still totally lost on how to fix it, or even what is causing the problem.  I started having the same issue as the original poster with slow opening consoles within an upgraded vCenter, but have since discovered that the same problem is recreatable in a new ESXi 5.1.0 install (no need to include vCenter, SSO, or anything else).

I have tried stock VMware 5.1.0 and also the HP build of 5.1.0, both have the problem, but 5.0.0 and 5.0.0U1 both work fine.  I have installed 5.1.0 on numerous pieces of hardware, with diverse networking setups, and the problem is recreatable every time.  I have tried connecting to the ESXi from a Win7 workstation and an XP workstation.  I can not find a single instance in which 5.1.0 does not take 30+ seconds to open up a console.

Here is a brief overview of the fastest way to recreate the problem:

Fresh build using ESXi 5.1.0, installing onto an internal hard drive.  Connect to ESXi using vSphere Client, create a new VM (accept all the defaults).

Before powering on the VM, open a console, it should be nice and fast.

Close the console, power on the VM, open a console, it takes between 25-45 seconds to open.  During that time the window is listed as not responding, and other applications on my workstation are hung as well.  After the obligitory 30+ second wait, the console opens and everything returns to normal.

You don't need to mount an image for the VM and you dont need an OS installed, just a powered on VM.  I even edited the settings of a VM and removed the NIC, the HD, the CDROM, and the Floppy and the 30+ second lag is still there.

I can't find anything unusual in my local workstation logs, nor the ESXi logs, nor the VM's logs.  If anyone has any suggestions on what else to try it would be much appreciated, as my local users are all upset with this new "better" version causing a 30+ second delay every time they open a console.

Reply
0 Kudos
Bigi201110141
Enthusiast
Enthusiast

This is something they can see and test themselves instead of wasting customer time trying to troubleshoot and collect logs.

This issues happens on a standard vanilla install on any brand Server.

How can this not be caught during QA?

Reply
0 Kudos
rvdl
Enthusiast
Enthusiast

Right i think i have finally found some breakthough here.

I read the documentation again about Login Behavior When You Use vCenter Simple Install.

You can find it here http://pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.vsphere.upgrade.doc%2FGUID-3BDE41A9-...

So that made me think it could be SSO that is nagging here.

It turned out my hunch was right.

Original situation (domain user):

I login to vCenter with vSphere Client using (domain name\logon name).

I open a VM console and have to wait about 10 seconds before i see the VM console.

New situation (vCenter Server local user):

I login to vCenter with vSphere Client using (logon name).

I open a VM console and have to wait about 2 seconds before i see the VM console.

There we go, no delay when using local users instead of domain users.

Next step.

I started the vSpere Web Client and logged on with the admin@System-Domain username so that i could configure Sign-On and Discovery.

At the Sign-On and Discovery -> Configuration part i noticed the tab Identity Sources.

There was our Active Directory configuration stored.

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.

Final situation (domain user):

I login to vCenter with vSphere Client using (domain name\logon name).

I open a VM console and have to wait about 3 seconds before i see the VM console.

This is a fine workaround for me.

I have no idea about how insecure the ldap connection between the vCenter Server and our LDAP Server (Domain Controller) is.

But the performance improvements are worth it to me.

Hopefully you can all profit from this until VMware has a solution for us.

It would be nice if a VMware employee could shine his light on this case for us.

Thank you all for your thoughts and help.

Reply
0 Kudos