Johnny Zhang
By default, users can try to log into a Linux or in this case ESX server as many time as they want. Someone can sit there all day try to crack the password or just write up a script let it do the trick. You can change the behavior by add the following lines to /etc/pam.d/system-auth:

auth required /lib/security/ no_magic_root
account required /lib/security/ deny=3

This will lock out the user after 3 attempts
(Keep in mind you might want to give more than 3 attempts before lock users out, just in case you forgot your password)

You can also setup the log to monitor it after this

To create the file for logging failed login attempts, execute the following commands:
touch /var/log/faillog
chown root:root /var/log/faillog
chmod 600 /var/log/faillog

Note: This will only work with VI3 since PAM on Redhat 5 (where ESX 4.x service console based on) does not work with those options

Johnny Zhang
There are times you just want to find where are all those logs are (Don't we all hope all the logs in a centralized location for us?)

Here are the list of default log locations for vCenter and some of the plug-ins

C:\Documents and Settings\All Users\Application Data\VMware\VMware

Web server component of VirtualCenter
C:\Program Files\VMware\Infrastructure\VirtualCenter Server\tomcat\logs\*

License manager (For vCenter which manage the ESX 3.x servers)

VMware Update Manager
C:\Documents and Settings\All Users\Application Data\VMware\VMware
Update Manager\Logs\*

VMware Update Manager UMDS

VMware Enterprise Converter
C:\Documents and Settings\All Users\Application Data\VMware\VMware
Converter Enterprise\Logs\*

VMware Guided Consolidation
C:\Documents and Settings\All Users\Application Data\VMware\VMware
Capacity Planner\Logs\*

Vi client
C:\Documents and Settings\\Local Settings\Application Data\VMware
Johnny Zhang
If you are on a ESX host service console (ESX 3.x or ESX 4.0), you want to run a quick summary on the data stores this host can see, but either don't have access to VI client or just simplely lazy to launch it, you can get that by typing
vmware-vim-cmd hostsvc/datastore/listsummary

You can got more about a specific datastore by
vmware-vim-cmd hostsvc/datastore/info datastore_name
Johnny Zhang
Some guest OS processes can send information to ESX or ESXi hosts via vmware tools, it's called setinfo messages, those messages will write to VM's configuration file known as .vmx file. If you want to restrict this, you can add " = "True"" on your .vmx file.
Please keep in mind after you set this, you will not see the VM's ip adress, DNS name etc from either ESX server or vCenter since those information will not pass to the host through vmware tools.
Johnny Zhang
Anyone work with ESX server would know sometimes you need to restart hostd service on the ESX server to "refresh" information on ESX. Normally we do this by typing "service mgmt-vmware restart"
However, sometimes this is not good enough. Every time you restart hostd it will map to 4 files under
If any of those file got corrupted by any reason, restart hostd will not help. Every time when hostd restart called, the service will check if those files exist, if not it will create them before starting the service. So we can remove those files to make sure hostd service starts from scrach
"rm -rf /var/lib/vmware/hostd/stats/*" Make sure you are in the right direct tory when you run the rm command especially with the -rf switch
Johnny Zhang
There are many useful log files on a ESX server to help you find what cause a problem. However, there may be to many of them how do you know which one to look at? I will base on my own experiences to explain what I think is important. I will start with HA logs. HA is configured on vCenter. However, once configured it will function without vCenter. It will build it's own HA domain (This domain always use the name 'vmware'). If you have more than 5 servers in a HA cluster, there will be 5 primaries and the rest will be secondary. The log file location after ESX 3.5 U2 is at /var/log/vmware/aam directory
The most impportant log would be "vmware_server_name.log". You can find many HA related info or errors from here.
Even with 5 primaries, there will be only one cluster manager which is the one holding all the rules. You can find which one is the cluster manager by

less vmware_server_name.log | grep -i "VMWareClusterManager submitted to run on node "| uniq
You can see how HA changed the cluster manager from host to host, and the last record is the current manager.
You can also find out if there was a isolation event happened by
less vmware_bs-bcs-h132.log | grep -i ISOLATED
When HA detect heartbeat failure on one host, it will try to find out if this is a agent failure or host failure. The isolation event will only trigger when there is a host failure. HA does this by ping the host after the heartbeat is gone
less vmware_bs-bcs-h132.log | grep -i "Ping Node results:"
When the host replys the ping it will mark as ALIVE. When the host is not responding it will mark as DEAD and HA event will trigger. (More to come in the future)
There was an error in this gadget