ohh never mind, i found them in the hostd.log...but what does this mean....
Accepted password for user root from 127.0.0.1
2013-04-08T17:42:07.522Z [6BD0FB90 info 'Vimsvc'] [Auth]: User root
2013-04-08T17:42:07.522Z [6BD0FB90 info 'ha-eventmgr'] Event 52469 : User email@example.com logged in
2013-04-08T17:42:07.568Z [6C043B90 error 'VmwareCLI'] GetPrimitiveParam: Cannot find (help)
2013-04-08T17:42:07.569Z [6C043B90 info 'VmwareCLI'] Dispatch list
2013-04-08T17:42:07.588Z [6C043B90 info 'VmwareCLI'] Dispatch list done
2013-04-08T17:42:07.588Z [6C043B90 verbose 'VmwareCLI'] Result (type vim.EsxCLI.system.process.list.UserWorld) (wsdl ArrayOfVimEsxCLIsystemprocesslistUserWorld) (kind 19)
2013-04-08T17:42:07.774Z [6BE64B90 verbose 'Default'] CloseSession called for session id=5213ec19-cec7-83df-fc17-686f79bdc291
2013-04-08T17:42:07.775Z [6BE64B90 info 'ha-eventmgr'] Event 52470 : User root logged out
2013-04-08T17:42:17.518Z [6BD62B90 verbose 'Ticket 52 b5 5f cb f3 45 4b fa-2f 51 94 02 c9 62 c7 8e'] Ticket invalidated
2013-04-08T17:42:17.984Z [6C043B90 verbose 'Proxysvc Req46910'] New proxy client SSL(TCP(local=10.129.29.18:443, peer=10.106.6.59:53282))
2013-04-08T17:42:17.998Z [6BD0FB90 verbose 'Locale' opID=HB-host-13360@7746-c15d4b98-74] Default resource used for 'counter.virtualDisk.commandsAborted.label' expected in module 'perf'.
2013-04-08T17:42:17.999Z [6BD0FB90 verbose 'Locale' opID=HB-host-13360@7746-c15d4b98-74] Default resource used for 'counter.virtualDisk.commandsAborted.summary' expected in module 'perf'.
2013-04-08T17:42:17.999Z [6BD0FB90 verbose 'Locale' opID=HB-host-13360@7746-c15d4b98-74] Default resource used for 'counter.virtualDisk.busResets.label' expected in module 'perf'.
2013-04-08T17:42:17.999Z [6BD0FB90 verbose 'Locale' opID=HB-host-13360@7746-c15d4b98-74] Default resource used for 'counter.virtualDisk.busResets.summary' expected in module 'perf'.
2013-04-08T17:42:18.019Z [6C043B90 verbose 'ha-license-manager' opID=HB-host-13360@7746-c15d4b98-74] Load: Loading existing file: /etc/vmware/license.cfg
2013-04-08T17:42:18.033Z [6C043B90 verbose 'Default' opID=HB-host-13360@7746-c15d4b98-74] ha-license-manager:Validate -> Valid license detected for "VMware ESX Server 5.0" (lastError=0, desc.IsValid:Yes)
2013-04-08T17:42:33.457Z [6BE64B90 verbose 'SoapAdapter'] Responded to service state request
2013-04-08T17:42:54.747Z [6BD62B90 verbose 'Proxysvc Req46911'] New proxy client SSL(TCP(local=127.0.0.1:443, peer=127.0.0.1:52154))
2013-04-08T17:42:54.765Z [6BDE3B90 verbose 'Ticket 52 76 4e c3 e2 b9 a2 5e-13 35 48 dc 22 42 31 c9'] Ticket issued for root
2013-04-08T17:42:54.768Z [6B974B90 verbose 'Ticket 52 76 4e c3 e2 b9 a2 5e-13 35 48 dc 22 42 31 c9'] Ticket used
Interestingly we just put in a new cluster of DL560 Gen8's and are seeing this occurring on all four of these new hosts. We don't see it occurring on other older generation HP hardware running the same version of ESX, controlled by the same Virtual Centre. Our suspicion is the HP Offline Bundle which I updated on these hosts, to the most recent version whereas the other hosts are running an older version?
I believe that is part of the hp agentless management service (daemon hp-ams). More info about hp-ams can be found here: HP Blogs - HP ProLiant Gen8 Agentless Management Overview - The HP Blog Hub
hp-ams needs to connect to ESXi in order to get some HW/SW info, and it does under the root credential, which is by default logged by ESXi. To make sure it is hp-ams causing it, you can stop it and watch Events and verify they stopped. To stop hp-ams you can run /etc/init.d/hp-ams.sh stop and then /etc/init.d/hp-ams.sh start . More info about these commands on http://h20000.www2.hp.com/bc/docs/support/SupportManual/c03306157/c03306157.pdf
However, I cannot say the number of times it is connecting per minute is normal or not, sorry about this.
Hope that helps a little.
Bingo. I stopped the service, the logging in has stopped. Will have to see what impact this has on stuff like ILO, the health monitoring of the host in Virtual Centre, etc and decide whether we can disable it permanently.
We only use ILO for remote management in the event of a problem with the host and dont use it to scrape alerts out or anything so... I don't think it'll be a big loss for us.
I'm glad it worked. And you have the right idea, i.e., check which impact it will have for you, because even if a SIM server is not used, the hp-ams agentless services still collects HW info for each host and updates vCenter for it, so double check if you can leave it stopped.
Hi, I am in the same position, updated one host to the latest firmware revisions, now I am bombed with an alert every 60sec or so. What did you do in the end, can you suppress the notification?
HP resolved this issue with their latest CIM management agents released in September. See:
This issue occurs when the hostd process in each ESXi/ESX host reports all logins made to the system. This is an expected behavior.
There are three components involved:
Hostd. This sends an event for each login attempt.
Note: The hostd process cannot be configured to stop or combine login events.
Application. This is installed on the ESXi/ESX host via the hostd process over TCP ports 80 and 443.
Note: As these applications are all running on ESXi/ESX, they may access hostd more frequently than external applications, thus generating a large
number of login events.
vCenter Server database. Events are collected and stored for each hostd agent sending events.
Note: vCenter Server does not automatically combine login events. This can cause the events tables to grow and fill the database. An alarm or alert does
not trigger in vCenter Server.
The ESXi/ESX root account handles system changes required by vCenter Server. The vpxd service communicates the instructions to hostd and the root account on the local ESXi/ESX host, then executes the instructions.
These messages can be related to any of the vCenter Server or host related tasks and are benign.
In a default configuration of ESX Server host there is no process that repeatedly logs in as noted above in the Symptoms. Generally these repeated logins are caused by a custom script or third party management software installed on the service console.
Usually these programs are logging in to check the status of an entity from within ESX Server host. To resolve the events the recommended course of action is to talk to the vendor of the product. In the interim, disabling the agents stops the events from appearing.
To work around this issue, stop the CIM agent on the host.
If that does not resolve the issue then check the logs and find the cron job which is causing the issue. This event coincides with the root login attempts.