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/pam_tally.so no_magic_root
account required /lib/security/pam_tally.so deny=3
no_magic_root
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
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
vCenter
C:\Documents and Settings\All Users\Application Data\VMware\VMware
VirtualCenter\Logs\*
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)
C:\WINDOWS\Temp\lmgrd.log
VMware Update Manager
C:\Documents and Settings\All Users\Application Data\VMware\VMware
Update Manager\Logs\*
VMware Update Manager UMDS
C:\Windows\Temp\
vmware-downloadservice-log4cpp
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
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
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 "isolation.tools.setinfo.disable = "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.
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 /var/lib/vmware/hostd/stats.
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
