VMware Cloud Community
alwynstrydom
Contributor
Contributor

Cannot synchronize host "host name" Operation timed out.

Hallo

We have 2 customers on vSphere 4.1 on the VC(Virtual Centre) and on the ESX side.

They both keep on getting the below error:

“Cannot synchronize host "host name" Operation timed out.”

Checked time settings on all hosts and the VC and all seems to be in order. Swap file partition is at 10Gb and the ESX service console memory at 800mb, so no problems there.

Most of the time a simple restart of the management interface on the affected host resolves the issue, but we would not like to resort to this all the time as a admin might not be available to do so.

Most all ESX hosts are loaded from scratch. They were 1st removed from VC and then formatted and then pulled back in, so certificates should not be an issue.

This is especially a pain in the one environment with View 4.5 and about 500 desktops.

Hope someone can help me out of this misery. L

Thanks.

Reply
0 Kudos
10 Replies
kjb007
Immortal
Immortal

How busy are the hosts?  When this occurs, have you checked how busy your host cpu0 actually is?

-KjB

vExpert/VCP/VCAP vmwise.com / @vmwise -KjB
Reply
0 Kudos
alwynstrydom
Contributor
Contributor

Hallo

The entire environment is busy due to the fact that it is used for VMware View.

But all hosts's CPU usage never goes above 60%

Regards

Reply
0 Kudos
kjb007
Immortal
Immortal

I've seen similar problem in the past.  In my case, if I kept getting a repeat issue on a particular host, I would disconnect the host, log into the host console, remove the vcenter and ha agents completely (rpm -e VMware-aam-haa-2.2.0-1; rpm -e VMware-vpxa-4.1.0-258902), remove the vpxuser (userdel vpxuser).

Then go back to vcenter, and reconnect the host.  This will reconnect to the host, add a new vpxuser, and reinstall the vcenter and ha agents.  This should get you to a clean vcenter/ha client install.

-KjB

vExpert/VCP/VCAP vmwise.com / @vmwise -KjB
Reply
0 Kudos
alwynstrydom
Contributor
Contributor

Hallo

Funny that this should happen on ESX hosts that has been removed from VC and then format and reloaded.

I ran the below commands once or twice on the hosts that was affected to restart the management agents:

service mgmt-vmware restart

service vmware-vpxa restart

SEEMS like the issue has now disappeared.

Regards

Reply
0 Kudos
gdavid
Enthusiast
Enthusiast

I am also having this issue on 1 host as of yesterday.

will either of these

service mgmt-vmware restart

service vmware-vpxa restart

disconnect my guest machines? right now i can get to all my guests via RDP etc. but the host/VMs are not manageable via the vsphere GUI.

thanks

GD

Reply
0 Kudos
alwynstrydom
Contributor
Contributor

Hallo George

Noup, only retart's the management interface. You will need to connect to the host in VC again thou.

Regards

Reply
0 Kudos
dagrichards
Contributor
Contributor

This issue was causing vmotion failures, and timeouts whne attempting to configure the very host the Virtual Center was hosted on.

running

service mgmt-vmware restart

service vmware-vpxa restart

and reconnecting the host from Virtual Center did in fact make the errors go away and solve the time outs and vMotion issues to go away.

50 Commando Man points for you.

Reply
0 Kudos
tws-carlh
Contributor
Contributor

Hi KJB,

I have the same problem,I have ESX4i

I restrted management service with services.sh restart command.

But it fixed the problem just for 20 minutes ,the problem came back again,

Can I remove the vcenter and ha agents completely (rpm -e  VMware-aam-haa-2.2.0-1; rpm -e VMware-vpxa-4.1.0-258902), remove the  vpxuser (userdel vpxuser). on working hours,

Dose it affect any VMs or the guest itself?

Is the command the same for ESX4i ?

Many thanks

Reply
0 Kudos
kjb007
Immortal
Immortal

Those steps don't work for ESXi.  See http://vmwise.com/2011/03/21/when-a-reconnect-is-not-enough/

-KjB

vExpert/VCP/VCAP vmwise.com / @vmwise -KjB
Reply
0 Kudos
ericwilliams
Contributor
Contributor

Something you may want to try next time is to hop on your suspect ESXi host at the physical console and restart the management agents.  This is, to me, an easier way (at least faster) of doing the exact same thing described in previous posts.

Reply
0 Kudos