I’ve never been a huge fan of agents in the Service Console. Too many times I’ve seen hosts fail because of an agent that had a memory leak etc. Now it seems that running the HP IM agents causes your ESX 3.5 U2 to become unavailable after a certain amount of time.
The errors that appear:
0 Z root 8536 3673 0 79 0 – 0 nct> Aug05 ? 00:00:00 cimservera
0 Z root 8537 3673 0 79 0 – 0 nct> Aug05 ? 00:00:00 cimservera
0 Z root 8543 3673 0 78 0 – 0 nct> Aug05 ? 00:00:00 cimservera
0 Z root 32350 3673 0 79 0 – 0 nct> Aug06 ? 00:00:00 cimservera
0 Z root 32351 3673 0 79 0 – 0 nct> Aug06 ? 00:00:00 cimservera
0 Z root 32352 3673 0 79 0 – 0 nct> Aug06 ? 00:00:00 cimservera
0 Z root 32353 3673 0 78 0 – 0 nct> Aug06 ? 00:00:00 cimservera
HStrydom on the VMTN forum posted the following:
I am having the same issue. What happens after 17 days is that there are about 32000 of these processes. ESX has a max value of +- 32000 PID’s. Thus when all have been used up, one cannot SSH into the server, log in from the console or the ESX server disconnects from VC.
Also we have HP servers with the HP agents loaded. Our Dell servers does not have this problem.
Have a look at your cron log, /var/log/cron & cron.1. you might see that some of the job have not run. Also look in your /var/log/messages. There is a lot of login failures.
In other words, if you see the same thing happening call HP and let’s hope they release a fix soon! And in the meanwhile start thinking about ESXi, it’s problems like these that makes you think about why you even need a Service Console in the first place.
Jim S says
I was just about to install the HP agents on my test ESX servers. Thanks for the heads up as now I’ll wait for a new release before I test the waters.
James says
Yep, I agree I dont have HP Server however agree ESXi is the one to standardize on though if possible. What is the “Service Console” actually good for?
1) Installing additional Management Agents
2) Backup software
3) Looking at TOP ?
4) Looking at Storage ?
1&2 should really be disallowed and as for 3/4 you could really do this via the VI Client anyways so what are some other reasons to having a “Console” From what I understand any VI License can be applied to ESXi so? Question is To Console or Not to Console ???
Rob Mokkink says
I don’t like agents on ESX too. I am still waiting for the new release of Nworks, so that the hardware can be monitored agentless.
I also have zero shell scripts etc. running on ESX these days, everything is done with powershell remotely.
Dave Convery says
This isn’t something new with the SIM agents. Ever since ESX 3.0 came out and HP released an agent, there has been SOMETHING wrong with each version. HP’s response is to upgrade the firmware and agent version. You get to the highest level of each and there is a new problem. I have heard about the cimservera stuff for a while now…
John says
OK – question though. How are we going to make the ESXi systems UPS aware?
I just bought a big Symmetra box but even at 43% load I only get 35 minutes of run time.
Everett Alvarez says
I was in an HP enviroment and we ran into multiple issues with HP agents running on ESX. As previously posted before they told us to upgrade the firmware and etc….. So boo for agents running in esx…
-everett
Susan Larden says
Heads up on this – the answer is within your SIM console set the WBEM user id and password under system protocols to be a valid user on the esx host. This seems to resolve the issue. By default it uses a domain account that has been set as a global account to use
Awinkel says
I agree with Susan. Today I had the same issue and after making a local account at the ESX servers and changing the config of SIM anything seems to work fine. But the rest of the day I keep my fingers crossed. 😉
See also this topic: http://communities.vmware.com/thread/159728?tstart=0
Duncan Epping says
@ john: via a perl or powershell script from within a VM or the VC it should be possible if you have a IP-Enabled UPS.
Geir Ingebrigtsen says
I must agree with Susan as well.
While agents on the Service Console is not always a good thing, this time the problem clearly lies with the Pegasus service in ESX, and not with the agents from HP.
In other words – we must wait for VMware to create a patch, and meanwhile configure our SIM servers correctly.
Jason Boche says
Duncan FYI:
VMware KB article: Feature by feature comparison of ESX versus ESXi
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006543
Duncan, do you have an email address that you could give me? Thank you, Jas
Dean says
Are you using HPSIM 8.1? 8.1 is required for 3.5 U2
http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?swItem=MTX-62350b0bf98a442fb3c1cb1154&lang=en&cc=us&idx=0&mode=4&