• ESX disconnects randomly from VirtualCenter
• ESX disconnects when performing VI Client tasks from VirtualCenter.
• Tasks randomly timeout after a long idle time
• “An error occurred communicating to the remote host” pops up.

The article refers to an issue with vCenter Update 3 in combination with firewalls using state-ful inspection. The problem occurs because of SOAP timeouts, and this behavior did not exist in VC 2.0.x or 2.5 GA, as they used a different mechanism to communicate with ESX. The official KB article hasn’t been released yet but a temporary workaround has been published by Richard. If you run into any of the before mentioned issues head over to Richard’s website and try out the workaround until the fix or official KB article is released.

# Active and standby setup and maxActive from 1 to 2
mv /etc/vmware/esx.conf /tmp/esx.conf.bak
/bin/sed -e ’s/net\/vswitch\/child\[0001\]\/teamPolicy\/maxActive = \”1\”/net\/vswitch\/child\[0001\]\/teamPolicy\/maxActive = \”2\”/g’ /tmp/esx.conf.bak >> /etc/vmware/esx.conf

So as you can see, a “sed” command changed the maxActive from 1 to 2. But I rather not use these kinds of solutions, editing the esx.conf that is. As of ESX 3.5 U3 that’s not necessary anymore, VMware fixed this issue:

Network adapters lose bonding during scripted installation
The esxcfg-vswitch -L command now works as expected and with the same functionality as in 3.0.x.

During a scripted installation, the following two commands did not result in a bonded pair of active network adapters on virtual switch VS_VM1. Instead, vmnic3 became the active adapter and vmnic4 became the standby adapter.
esxcfg-vswitch -L vmnic3 VS_VM1
esxcfg-vswitch -L vmnic4 VS_VM1

So just use esxcfg-vswitch again and don’t edit the esx.conf anymore!

This document deals about VMware HA clusters and all the advanced options you have with the use cases for these options. And that’s what makes this document very useful, the use cases! So everyone dealing with HA clusters should definitely read this document. Thanks Seva for letting me distribute it, and thanks for a great document!

Issue: After attempting to upgrade to VirtualCenter 2.5 Update 3 using the VirtualCenter Update Wizard, and not the VMware Unified Installer, the VirtualCenter service may fail to start. The issue is caused by an incomplete update of the database information for VirtualCenter resulting in incorrect database versioning, which is verified, and required to be correct, by the VirtualCenter service upon startup.

I’m not gonna post the answer to this problem, cause the article might change over the next day and than this info will be outdated and misleading. So check this KB article for more info.