No logging of performance data when VI Client is offline

[pfuhli]

Hey there,

I'm very impressed of the new capabilities VC 2.0 provides. But I have a problem with logging of performance data. It seems that VC is only logging data when my client is running. All the other time the lines of the charts are going to zero. Do I have to configure this at the server?

What do I have to change?

Thanks for your help!

daniel

[pfuhli]

I also installed every patch and tried all the here suggested configs but still I have drop outs.

But look at this official statement KB 5211358

http://kb.vmware.com/vmtnkb/search.do?cmd=displayKC&docType=kc&externalId=5211358&sliceId=SAL_Public

[Noyzyboy]

Well at least they're honest...

Every install I've done since VI3 came out has also got issues. That's about 7 separate VI3 installs. Some upgrades from VC1 some completely fresh installs.

[eliot]

I also installed every patch and tried all the here

suggested configs but still I have drop outs.

But look at this official statement KB 5211358

http://kb.vmware.com/vmtnkb/search.do?cmd=displayKC&do

cType=kc&externalId=5211358&sliceId=SAL_Public

Talks about upgrades - but I have fresh VI3 installs with duff historical performance data.

[Argyle]

jhanekom, great post about the index.

[jhanekom]

VC 2.0.1 Patch 2 has been released and reportedly fixes several database issues.

Check it out here: http://www.vmware.com/support/vi3/doc/vc-201-200702-patch.html

Brief extract:

"The database instances ... supporting VirtualCenter Server have been subject to deadlocks and other performance issues due in part to VirtualCenter's statistics-aggregation (rollup) process. With this release, the statistics-data aggregation process ... has been improved.

Other issues related to statistics collection, such as eliminating duplicate entries in the statistics tables and better managing the Microsoft SQL Server tempdb size, have also been resolved.

The new, improved statistics-rollup procedures also provide several new optional parameters ... Using the parameters, you can modify VirtualCenter's configuration file (vpxd.cfg) to change the frequency and type of rollup, and to put the rollup process in a sleep mode, for example, to reduce resource utilization. See KB 3034858, "Statistics Rollup Stored Procedures Optional Parameters" for information about using the new parameters."

[dinny]

Hiya,

I have now installed the patch - (I can't say whether or not it fixes the SQL performance issues yet).

I did have a few issues with the installation:

In the VI client afterwards - my ESX 2.5.2 servers all connected OK

My ESX 3.01 servers all came up as disconnected - a re-connect failed.

I then did a service mgmt-vmware restart[/i] in the service console.

The reconnect did then work.

However the HA agent still came up as disabled.

Reconfigure for HA[/i] also failed.

Finally - removing HA from the cluster and then re-adding it did seem to work.

HA and DRS are now working fine.

I would be careful about when you install it on an environment with a live HA cluster though - bear in mind you may have to do some work to get it all up and running again.

Dinny

[nadger]

Same thing happened here after the upgrade. It updates all of the hosts with the new VC agent package. On one host I had to manually install the update as would just fail. All reconnected after 5-10 mins I presume due to the upgrade of the agent all needed HA reconfiguring.

[stuten]

I happen to have a VI client connected to the ESX server that was hosting my VC server when VC came back up after the upgrade. Shortly after, the VI client connected to the ESX server starting throwing lots of tasks in the recent tasks pane. I decided to let it calm down before launching a VI client connected to the VC server. Once it calmed I launched into VC and all of my hosts had connected. Two of my hosts (out of 6) had warnings on them that HA had not been enabled. A right click re-enable (reconfigure, or something) and they both came right back.

After the upgrade the SQL server took an entire CPU for about 8 hours. Since then, both CPU and disk usage has been very reasonable and the response of the client is MUCH MUCH better. The graphs acutally paint in short order and so far I've yet to have one time out.

[jhanekom]

I can confirm that with the new update, VMware now use index hints in their SQL queries to make use of the existing indexes they have in the database. (Previously the indexes were there, but were not being used, which is why the suggestion of creating additional indexes helped so much.)

This dramatically increases performance on larger installations. It would seem that this change is done on the server side, as the index hints are used even when using a VC2.0.1 patch 1 client.

There is still some potential for improvement by creating a clustered index on VPX_HIST_STAT with the ENTITY_ID and SAMPLE_ID fields (to help reduce overheads in sorting results), but in the majority of cases this probably won't be necessary anymore.

[jhanekom]

Some feedback: I've been running patch live at a production site for a week now. Things look a great deal better.

With the workarounds and indexes I implemented before, I managed to successfully run quite a number of ESX hosts and virtual machines. As we migrated from ESX 2.x to ESX 3.x (and, presumably, more metrics were collected on more VMs), the rollup-problem increased and performance graphs became more and more flaky.

Since the patch, there haven't been any serious problems; my weekly memory utilisation charts no longer look like picket fences and I was able to do away with the tasks scheduled in SQL Agent.

Things look promising indeed...

(The only problem I had in deploying the patch was that my ESX servers wouldn't install the VPXAgent due to being unable to create a temporary directory. You basically have to create /tmp/vmware-root if you're running /tmp on a separate partition. Read here for more details: http://www.vmware.com/community/thread.jspa?messageID=593230#593094)

[pfuhli]

Yeah seems that VMware finally has done good work after our complaining. At this time I can't see any dropouts in my graphs. Performance of the client is much better but could still be improved

Seems that this is the end of this thread?! Many thanks to everybody contributing information here!!

Cheers

daniel