Time Zone Mismatch in Metrics Due to vApp Deployment Properties Defaulting to UTC in VCD and vROps.

Products

• VCF Operations/Automation (formerly VMware Aria Suite)

Issue/Introduction

• While VCD and vROps nodes may be configured for GMT+7, metrics in some environments default to UTC (GMT+0) because the vApp deployment properties were not correctly initialized to the local time zone.
  
  
• In VMware Aria Operations, the time and date may display incorrectly in these fields:
  • Reports
  • Metrics
  • Notifications
    
    
• The time fails to display correctly despite having the NTP server settings configured correctly.
  
  
• In the analytics log file you see entries similar to:
  
  2015-09-17 08:53:08,335 WARN [P2P message reader for quotes(vRealize Ops Analytics-<UUID>:4918)<v4>:10002 on port 34,625 ] com.vmware.vcops.analytics.gemfire.GemfireCommunicator.beforeCreate - FORWARD_DATA_ALT_REGION region exceed the maximum number of entries. Rejecting put in region FORWARD_DATA_ALT_REGION
  
  
• The cost calculation background task executes twice daily instead of the expected single daily execution. This behavior is typically observed in the background task history within the Aria Operations Console and can lead to inconsistencies in MTD (Month to Date) cost metrics. Below Image represent a Cost Monitoring dashboard in Aria Operations, specifically tracking the Effective Month-to-Date (MTD) Cost for a specific resource group or cluster the cost calculation is running twice a day.

 

Note: The preceding log excerpts are only examples. Date, time, and environmental variables may vary depending on your environment.

 

Environment

VMware Aria Operations 8.x (formerly vRealize Operations)

Cause

• This issue occurs when the NTP server settings were not configured during the initial setup or caused by a timezone mismatch across the cluster nodes. When cluster nodes operate on disparate time zones (for example, a mix of UTC and IST), the cost calculation service triggers locally based on each node's system time. This results in multiple triggers at different intervals across the cluster.

Resolution

Workaround to update the /etc/localtime file to the correct city in the desired time zone.

Step 1: Verify Time Zone Configuration.

Before making changes, verify the current system time and timezone on all nodes in the cluster:

1. Establish an SSH session to each VMware Aria Operations node using root credentials.

2. Check the current system date and time: date

3. View detailed timezone configuration: timedatectl

Step 2: Standardize Node Time Zones.

1. Log into the VMware Aria Operations admin UI as the local admin user.
   
   
2. Click Take Offline under Cluster Status.

Note: Wait for Cluster Status to show as Offline.

3. Log in to the desired node as root via SSH or Console. 
   
   
4. Take the backup of /etc/localtime

cp /etc/localtime /etc/localtime.bak

     5. Delete the current localtime file by running this command:

rm /etc/localtime

     6. Get a list of the time zone locations and cities by running the following command, and noting the desired timezone location and city:

ls -l /usr/share/zoneinfo/

     7. Set the time zone by running this command. Replace location and city with the location and city noted in step 6.

ln -s /usr/share/zoneinfo/location/city /etc/localtime

Example: ln -s /usr/share/zoneinfo/America/city /etc/localtime

     8. Reboot the node for the changes to take effect.

     9. Repeat steps 3-7 on all desired nodes in the cluster.

   10. Log into the VMware Aria Operations admin UI as the local admin user.

   11. Click Bring Online under Cluster Status.

Note: Wait for the Cluster Status to show as Online.