nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

VMware ESX CPU - big & bad value after Orion 9.1 SP2

lchance

do i need to open a support case for this? notice the CPU util is at 16,274% after i applied 9.1 SP2 ...hmmmmmm

Find more posts tagged with

Accepted answers

Karlo.Zatylny

Hi,

Yes. Through much investigation and testing with customers and VMware, we have determined that the information we are receiving from ESX 3.0.X and previous versions is not accurate. ESX 3.5 is the only version that gives the right information, so that is what we are officially supporting. Hopefully this is not crushing news, but the error is not on our part now with 9.1 SP2.

Thanks

All comments

Wingren

We have the same problem... We also got a High CPU on our ESX-server after SP2.

mark_wiggans

It would probably be best if you did open a ticket.

DirtySouth

I'm also getting an EXTREMELY high CPU utilization on one of my ESX boxes after attempting to install SP2. I wasn't actually able to complete the upgrade though due to some other unknown reasons.

Karlo.Zatylny

Please let us know what version of ESX you are using. We have seen some incorrect values from 3.0.2 and previous, simply because those are the values we are getting back from the ESX server. However, we would like to clarify with VMware if anyone is seeing these numbers on 3.5.0.

Also, the reason you are seeing this on the gauge now, is that we now match the gauge up with the graph of CPU utilization graph (shown lower on the ESX details page by default). The gauge and chart should match. Please let us know if this is not the case.

Thanks

lchance

Machine Type	IOS Version
VMware ESX Server	2.5.0
	2.1.1
	2.5.2
	3.0.1 ---- BAD
	3.5.0
	3.0.0 ---- BAD
	3.5.0
VMware Inc.	nothing returned
VMware ESX Server	2.5.1

Mars

Hi i am having the same issue!!

We are monitoring 33 ESX servers
Version 3.0.1 --> 3 out of 5 have this issue
Version 3.0.2 --> No issue's
Version 3.5.0 --> No issue's

By the way before the update from 9.1 SP1 to to SP2 this issue was not seen on any of them.

For the examle seen today:
Host has a CPU usage of 2089%
On this host are 5 virtual machines with a cpu share of 32,41%, 12,79%, 32,41%, 9,6 % and 12,78%

Added a screenshot from same host (CPU usage percent) made by the VM infrastructure client:

Mars

Anybody news on this topic?

Karlo.Zatylny

Hi,

Thanks

gwsample

I am running ESX 3.5.0 build 130757 on 10 ESX hosts, and up until this morning had not seen this issue. I am running NPM 9.1 SP3.

This morning, I put one of my hosts in maintenance mode, which caused about 6 VM's to be vmotioned to other hosts. After doing this, I have two ESX hosts with CPU usage over 100%. One is at 1861% and another at 275%.

Karlo.Zatylny

Hi,

Please open up a ticket so that we can get diagnostics and I can take a closer look at your issue. Please reference this thwack thread in your support call.

Thanks.

frank_fung

I am running ESX 3.02 and didn't have a problem until Solarwinds Technical support suggested that I apply a service pack to a web site error problem. Now Solarwinds is telling me that a problem that their service pack caused isn't support on my version of ESX server.

Update for Case #78403 - "orion website error"

Thank you for contacting Solarwinds Support. This issue is dealing with an Orionweb.dll file that is not recognizing 2009. The following hotfix will correct that specific .dll file as well as other corrections.

Please apply the SP3 which contains the fix for this issue. Here is the FTP link:

ftp://ftp.solarwinds.net/Orion/ServicePack/Orion9.1-SP3.zip

Message History
-----Original Message-----
From: 1 '
Sent: Wednesday, January 28, 2009 12:01 pm CST (GMT-06:00)
Subject: orion website error

I am getting the below error or similar error when drilling down to details on CPU and memory utilization on-screen reports.

An error has occurred with the Orion website.

Additional Information
System.ArgumentOutOfRangeException: Year, Month, and Day parameters describe an un-representable DateTime.
   at System.DateTime.DateToTicks(Int32 year, Int32 month, Int32 day)
   at SolarWinds.Orion.Web.Charting.Periods.Parse(String& periodName, DateTime& periodBegin, DateTime& periodEnd, Int32& sampleSize, String& sampleName, Boolean& isCustom) in C:\Source\OrionNPM\DEV\Release\Orion\Core\9.1\OrionCommon\OrionWebAssembly\Charting\Periods.cs:line 305
   at SolarWinds.Orion.Web.Charting.Periods.Parse(String& periodName, DateTime& periodBegin, DateTime& periodEnd) in C:\Source\OrionNPM\DEV\Release\Orion\Core\9.1\OrionCommon\OrionWebAssembly\Charting\Periods.cs:line 419
   at TimePeriodControl.CheckTimePeriodValue(String TimePeriod, String SampleSize)
   at TimePeriodControl.GetTimeRelations()
   at TimePeriodControl.GetInitializeScript()
   at TimePeriodControl.TimePeriodControl_PreRender(Object sender, EventArgs e)
   at System.Web.UI.Control.OnPreRender(EventArgs e)
   at System.Web.UI.Control.PreRenderRecursiveInternal()
   at System.Web.UI.Control.PreRenderRecursiveInternal()
   at System.Web.UI.Control.PreRenderRecursiveInternal()
   at System.Web.UI.Control.PreRenderRecursiveInternal()
   at System.Web.UI.Control.PreRenderRecursiveInternal()
   at System.Web.UI.Control.PreRenderRecursiveInternal()
   at System.Web.UI.Control.PreRenderRecursiveInternal()
   at System.Web.UI.Control.PreRenderRecursiveInternal()
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint

frank_fung

I opened a ticket on the CPU ESX problem and was told to delete and re-add the ESX server and that didn't fix the problem. I responded back and haven't heard from technical support. I told Technical suport that they should contact engineering on the problem as well. I

Today I upgraded to the latest service pack and problem still exists.

Thank you for contacting SolarWinds support. Can you try deleting and re-adding one of the ESX servers completely, and see if that fixes it?

Karlo.Zatylny

Hi,

Sorry to hear about your issues. The versions of ESX prior to 3.5 are unreliable with the data they are reporting. Sometimes they are right and other times they are incorrect. So the SP was targetted at fixing what was wrong with ESX 3.5 issues, which might have caused problems with your ESX version.

I believe the problem will continue to exist as long as you are running the non 3.5 versions of ESX server and we are actually unable to reliably provide a fix since we can't rely on accurate data from the device.

Please let me know if there is anything else we can do to help.

dstj

I'm running ESX 3.5 on Orion NPM 9.1 SP3 and still seeing issues with CPU stats...

FormerMember

Upgrade to SP4 and then open a Support ticket.

Mars

Denny,

Without wanting to judge you're comments, in the release notes from SP3 and SP4 there is no mentioning resolving any ESX problems. The last ESX issue was addressed in SP2

Reading this topic their is a statement that things should be addressed after SP2 so i don't understand you're comment.

If Solarwinds is not monitoring ESX and all its features correctly (meaning more than just one version) than just say so. It is not wrong to say it is still under investigation or in development; it creates maybe even more understanding and feedback.

I am getting the impression we are just getting different answers on the different topics.

Greetings,

dstj

i upgraded to SP4 and still bad CPU values.

I'll try to open a ticket later if/when i find the time.

dstj

...mind you i should perhaps give it more time ?

Last week's bad values (a spike) is still there, but nothing since.

gwsample

seems that the values over 100% only happen when I vmotion VM's between the ESX hosts, and the levels drop back to normal after 5-10 minutes.