Tag Archives: VCSA

Email Alerts not sending in vCenter 6.5

Symptoms

  • vCenter (in my case VCSA 6.5 ) is not sending alert emails even though the mail server appears to be configured properly (in the vSphere Web Client this is on the vCenter node under Configure, Settings, General).
  • Network connectivity between vCenter and port 25 on the SMTP server is fine and has been tested.
  • The logs on the SMTP server show no evidence of emails beings sent.
  • When connecting via SSH to the vCenter Server Appliance the sendmail logs are showing errors such as:
    cat /var/log/messages | grep sendmail

    2018-07-14T04:24:46.569978+00:00 my-vc sendmail[21502]: ……: [email protected], [email protected] (0/0),
      delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30528, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0,
      stat=Deferred: Connection refused by [127.0.0.1]
  • Cause

    The “Connection refused by [127.0.0.1]” in the logs is the giveaway here- the settings in the client have not been applied to the sendmail service and vCenter is trying to connect to the localhost as the SMTP server.

    Solution

    Go to the client and reconfigure the mail server to point at something else (it doesn’t have to be a real hostname). Then change it back to the correct settings. Normal alerts will be resumed automatically straight away.  You can test if it works by temporarily adding an additional trigger with a very low threshold to an existing alert with notification action.

    vCenter Mail Settings in vSphere Web Client

    vCenter Mail Settings in vSphere Web Client


    Thanks to vExpert Laurens van Duijin for sending me down the right path with this issue.

How To… Patch VCSA

With VMware vCenter Server Appliance 6.5 patching has become very straightforward and both the vCenter software and the underlying Photon OS can be updated using a simple GUI. This short run through covers patching a single VCSA where the VCSA High Availability has not been configured.

Login to the vCenter Server Appliance admin console at https://my-vcenter-name:5480/

2017-10-03 (1)

Click on Images to Enlarge

Select “Update” from the Navigator menu on the left hand side, and then choose “Check Repository” from the “Check Updates” drop down in the main panel. This will check the VMware website for any new patches.

2017-10-03 (3)
Continue reading

Rolling back a failed VCSA HA deployment

The deployment of High Availability in the vCenter Server Appliance 6.5 is very slick and there’s a great step-by-step walkthrough of how to implement it. However, sometimes things go wrong – in my case a misconfiguration in the underlying network meant that the hosts I was trying to deploy to couldn’t reach each other on the new HA network.

The good news is the smooth Installation process is accompanied by a smooth uninstaller when things have gone wrong. It’s nice to see that this part of the application lifecycle process hasn’t been ignored by the development team at VMware. With the right planning and a bit of luck, you’ll never have to see this yourself- but here’s some example screenshots.

The install has failed, the wizard was unable to configure HA, and we are left with a situation looking like this:

image

The vSphere Web Client is telling me “vCenter HA has an invalid configuration. Click the remove button to destroy the current vCenter HA cluster configuration”. And it is really as simple as that, clicking Remove starts the process- this doesn’t destroy your vCenter environment- just the failed HA attempt – and vCenter reverts back to the model it was using beforehand. We get a nice clear explanation of what is going to be done, details of what manual steps may be necessary, and an option to change our mind.

image

The task proceeds like any other vCenter operation, showing as Completed in the Recent Tasks bar- in my homelab this removal task took just 11 seconds.

image

Once done it was just a case of powering down and removing the defunct Passive and Witness VMs, fixing the pre-existing fault that had caused the error in the first place, and then running the install again.It should end up looking something like this:image

It’s always good to see that development effort has been put into helping the user when something unexpected has occurred and this is a good example of that.

Auto Power On and VCSA Upgrades

VCSA Upgrade

VCSA Upgrade via the Appliance Installer


The vCenter Server Appliance (VCSA) upgrade from 6.0 to 6.5 is a slick, well managed, process. The installer deploys a new appliance, transfers all the settings from the old one (including IP address and identity) and then powers the old appliance VM off. This provides a neat roll-back option if something has gone wrong- you just power down the new appliance and turn the old one back on.

In upgrading my homelab I came across a small gotcha in this however. If you have your old VCSA VM set to auto power on when the host is then the next time you reboot that host (for example when you’ve done a Hypervisor upgrade) the old VCSA will turn on. You could now, like me, be in the situation where two VCSAs are running at the same time and sharing an IP. In a larger environment this is unlikely to happen- the host-based VM Startup/Shutdown feature is largely replaced by HA and DRS rules – but in a smaller setup this is a common practise to ensure that the vCenter comes up when the lab is switched on.

VM Startup and Shutdown

Automatic VM Startup and Shutdown with 2 vCenters


The solution is to switch the Startup behaviour to manual for the old VCSA, and just to make sure disable the virtual NIC on that old VM. Of course once you are happy with the upgrade the old Virtual Machine can be archived/deleted altogether.

Support Bundle taking up log file space on VCSA

Symptoms
The log file disk was nearly full on a vCenter Server Appliance instance, showing a warning message in the vCenter console and the VAMI (Login to https://vCenterHostName:5480). After a bit of investigation (and I’d recommend looking at this article by Brandon Lee and Knowledge Base 2143565 ) I found an old Support Bundle was taking up 2GB of the log disk unnecessarily and tripping the alert threshold.

Solution
SSH into the VCSA using the username root (see KB2143565) and navigate to the folder

/storage/log/vmware/vsphere-client/logbrowser/public/

And look for files named “*_vmsupport.tgz“, check the timestamp on these files and remove any old ones that are no longer required.
Hopefully the warning should clear and the health status should return to green in the vSphere Appliance Management Interface
Healthy VCSA