VCSA7 : No healthy upstream!

 I think many of us saw something like the following error when the deployment operation of VCSA7 has been finished. First of all, I decided to go directly through the VAMI and check the health of services, but everything worked correctly. Truly some of them are healthy with a warning, but after a restart, all of them are healthy, but sadly the problem still exists, even after restart the vCenter server. I searched inside the log files and nothing especially found that is related to this matter. 

You know if you type the IP address of the vCenter server, it will be redirected to the FQDN (if you set it correctly meantime of the deployment phase), So I decided to investigate more inside the "/etc/hosts" then create a backup and change the primary file's content, changing each line of IP/FQDN combination to the IPv4 and IPv6 loopback address form and also replace the "localhost" instead of FQDN, Something like the following picture.

 

 

Finally, after the second restart, the mentioned warning is gone.

Detecting source of ESXi login failure

  Sometimes we may encounter unexpected or unknown login issues for the ESXi hosts and see some errors like the "remote access for ESXi local user account 'root' has been locked for 900 seconds after xx failed login attempt" in the vSphere client. In most cases we know they are related to the changing credentials and forgot to set them again on the connected solutions, like Backup servers or Monitoring systems. But what can we do if we couldn't find the reason for the login failure?! What should we do if we couldn't reach the real source of the problem? Is it related to a wrong credential truly, or is it a part of a hacking operation (like password guessing)?

  We know there are many log files (/var/log or /scratch/log) for the ESXi host, and with respect to the troubleshooting purposes, they are very useful to discover and realize each aspect of problematic situations. So for this mentioned issue, we can go to the following log (hostd.log) file and investigate the depth of its details.

# grep Rejected /var/log/hostd.log

or 

# cat /var/log/hostd.log | grep Rejected

After you find the source of credential rejection, then you can manually understand the root cause. Is it related to an attack preparation or forgotten password changing operation?

VMware ESXCLI: how to upgrade and patch

In this video by using ESXCLI, I teach how to upgrade the ESXi host in the CLI environment. Also, I install a VIB Bundle file in the host. Hope gonna be helpful for you all.