- New free VMware tool: Virtual Machine Desired State Configuration (VMDSC) - Fri, Oct 22 2021
- VMware vSAN Automatic Rebalance vs. Proactive Rebalance - Fri, Oct 15 2021
- VMware Tanzu Services overview - Fri, Oct 8 2021
I recently wrote a detailed post about this migration. But it also is important to know what to do immediately following the migration. There are some management tasks that you should carry out right after you upgrade to VCSA.
We'll be accessing the VCSA via the Virtual Machine Management Interface (VMMI), using a format similar to this: https://ip_of_vcsa:5480. For the connection, use the root credentials you entered during the migration.
The VCSA VAMI user interface also enables monitoring of the VCSA itself. You can monitor memory, CPU, network, or virtual disks. Recently, VMware also introduced the ability to monitor the capacity of the internal disks.
In the past, when a disk was filled up with logs, for example, the VCSA just stopped working and you would be unable to log in to troubleshoot.
Now you'll receive a warning within the vCenter Server that your VCSA disk's capacity has reached its limit, which will help you to take action before further problems arise. One does not always work within the VAMI UI, which in most cases is used just sparingly, for updates or occasional monitoring.
NTP server settings ^
One of the first things to do after upgrade to VCSA is to make sure that your NTP servers are correctly set up. The best practice is to provide an NTP pool if you're not running an isolated environment.
Go to Time, click the Edit button on the right, and enter an NTP server for your region. You can enter multiple NTP servers, separated by a comma. It's recommended to have at least four sources for accuracy.
If you're running it in an isolated environment, you'll most probably need to use host-based synchronization. However, use it only as a last resort as NTP is more reliable and accurate.
While you're there, make sure you've set the correct time zone for your region. In the Time zone pane, click Edit. From the Time zone drop-down list, select a location or time zone and click Save.
Password expiration settings ^
When you first install VMware VCSA, the root password is set to expire every 90 days. It is possible to enter an email address to receive a notification about the expiration. In my opinion, however, this isn't enough. In some scenarios, the email entered isn't used within the organization or there has been a change in the IT management.
If you have a system where this information is wrong or simply not set, you'll never get notified about the expiration, since there is no other notification provided by VMware through the VCSA UI. I think they should add some kind of second notification from within the vCenter Server about the root password expiration of the VCSA appliance.
Next, configure the password expiration settings. Go to Administration and click the Edit button next to the password expiration settings.
The prompt shows you a dialog box where you can either completely disable password expiration (not recommended) or you can provide password validity during X days.
The maximum length is 9999 days and the minimum is 1 day. The system won't let you enter any value outside this range. The root password for VCSA is only used for maintenance tasks, such as patching or monitoring the health of the VCSA itself.
vCenter backup configuration ^
You can set a backup of the VCSA configuration so if you need to reinstall the VCSA, you can then restore this configuration and be up and running quickly. For the past several versions of vSphere, VMware has improved this feature so that it now includes a scheduler and new backup protocols.
You can send those file-level backups to a remote file server or NAS device, using any of the following protocols:
Before making a backup, you must set it up and configure it so your VCSA can access it. Depending on your environment and possibilities, there are plenty of choices. Although VMware just released this feature, I tested it in my lab and one of the protocols I used was FTPS. I used Filezilla Server software installed on a Windows system. It can easily be set up in no time.
The backup options are accessible through the Backup menu on the left. Just click Configure to enter the backup server details and configure a schedule. You should use an IP address instead of the FQDN for the remote location, and just a user name, not a UPN, for credentials.
As you can see, there are many options. Within the custom schedule, you can check just a few days a week. The normal schedule allows you to choose daily or weekly.
Note the possibility of encrypting your backups. Another possibility is to have an exception and not backup Stats, Events, and Tasks, thereby reducing the space needed for your backups.
Note: You can also set up a scheduled backup of VCSA via the software you're currently using for backing up your VMs. If you encounter a problem with your VCSA and it becomes unavailable, you'll need to point the restore to an individual ESXi host as a destination of the restore.
Forward the logs to a syslog server ^
One important thing to do regarding logging the activity of your VCSA is to set up a syslog connection to your syslog server. There are many syslog solutions on the market. You can enable what's called "remote streaming" of VCSA logs to a remote syslog server. Only the newly generated events are streamed to the remote syslog server.
All syslog messages start with a specific prefix, so if your syslog server receives streams from multiple destinations, you can distinguish the VCSA events from other syslog messages by their Event prefix.
Since vSphere 6.7, the VCSA supports up to three different syslog targets. Your IT team might have people specializing in security while others are just general admins, so separating them might make sense in some environments.
As you can see, there are quite a lot of tasks you have to handle after migration to VCSA. VMware has done a great job providing a simple web-based UI that has all the necessary tools and options built in. Depending on the environment you're working in, you can use a different set of protocols or tools to configure reliable file-level backups with daily, weekly, or custom schedules.
Password expiration settings, NTP, and time zone are among the first options to verify and check. The remote syslog server is most likely optional, but nice to have, especially if used in conjunction with some other software such as Log Insight, Splunk, or Runecast. These can extract the events and provide machine learning capabilities, allowing you to detect anomalies and upcoming problems easily.