VMware Cloud Community
spham68
Contributor
Contributor

Guest OS constantly reconfigure themselves when viewing hostd.log caused CPU0 peg at 80%

All,

Does anyone come across where ESX host CPU0 is pegging at 80% constantly and COS is used lots of CPU? It is due to the VMs that are being reconfiguring themselves when tail the hostd.log file.

The only the way I could stop the reconfiguring from occuring was to vmotion to different host and back.

Running ESX 3.5U1 with DRS and HA enable and VC 2.5U1

Any ideas.

Thanks,

Steve

0 Kudos
3 Replies
weinstein5
Immortal
Immortal

When you say reconfigure, what do you mean? COS is using alot of CPU it is bound to CPU0 that is why you have a high load - other things to check are you running anything in the COS? Also do you have many VIM Console open this to will cause high resource consumption in the COS -

If you find this or any other answer useful please consider awarding points by marking the answer correct or helpful
0 Kudos
spham68
Contributor
Contributor

This is what I saw when tail the hostd.log and caused the cpu0 to peg and it dropped when those machines vmotion to diffferent host and back.

State Transition (VM_STATE_ON -> VM_STATE_RECONFIGURING)

State Transition (VM_STATE_RECONFIGURING -> VM_STATE_ON)

State Transition (VM_STATE_ON -> VM_STATE_RECONFIGURING)

State Transition (VM_STATE_RECONFIGURING -> VM_STATE_ON)

State Transition (VM_STATE_ON -> VM_STATE_RECONFIGURING)

State Transition (VM_STATE_RECONFIGURING -> VM_STATE_ON)

State Transition (VM_STATE_ON -> VM_STATE_RECONFIGURING)

State Transition (VM_STATE_RECONFIGURING -> VM_STATE_ON)

State Transition (VM_STATE_ON -> VM_STATE_RECONFIGURING)

State Transition (VM_STATE_RECONFIGURING -> VM_STATE_ON)

State Transition (VM_STATE_ON -> VM_STATE_RECONFIGURING)

State Transition (VM_STATE_RECONFIGURING -> VM_STATE_ON)

0 Kudos
uga_mike
Contributor
Contributor

I had the same problem. I originally setup my VCS/VIM on an internal IP (because it was managing ESX 2.5 hosts at the time and didn't have net-worthy features). After upgrading the hosts to 3.5 from 3.0.2, the same usage issue happened shortly after tinkering with the update features. Turns out, if the vmware update services are setup and assigned to the ESX hosts, and the VCS can't get to the internet to check updates, it throws hostd into a state of frenzy in changing the guest OS states (not exactly sure why). Enabling a routable IP for the VCS server and pulling updates seems to have fixed my problems. I also unassigned any baselines attributed to the hosts just in case it was also causing problems (just until I put VCS on the net).

I need to do research on it yet, but one thing that would have drastically helped in this situation would be to change the maxsize of the hostd.log for the rotation to be larger or perhaps keep more of them. In my case, by the time I found the problem, the state change errors had altered every single one of the hostd-#.logs and gave me very little to work with in tracking down the issue.

-HTH.

0 Kudos