general/other Time Synchronization Issue with Different FreeBSD Versions on Nutanix AHV

[roomn]

Hello,
I am using FreeBSD as the Guest OS on a VM on Nutanix AHV.
When I run different versions of FreeBSD on the same Nutanix AHV cluster, the times on the two VMs become unsynchronized.
Could someone explain why this might be happening?

• AOS: 6.5.3

• VM
  • Guest OS: FreeBSD 12.1
  • Timezone (set during VM creation in Prism): Asia/Tokyo
  • Guest OS Timezone: JST-9 (output of tail -n1 /etc/localtime)
  • Result of date command: 9 hours ahead of the correct Japan time.
• VM2
  • Guest OS: FreeBSD 12.3
  • Timezone (set during VM creation in Prism): Asia/Tokyo
  • Guest OS Timezone: JST-9 (output of tail -n1 /etc/localtime)
  • Result of date command: correct Japan time

The conditions are the same except for the FreeBSD version.
I have observed the same phenomenon in FreeBSD versions 12.3 and later.
Both VMs were created using the following image: FreeBSD-XX.X-RELEASE-amd64.qcow2.xz from this link.
http://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/VM-IMAGES/

 

[gpw928]

Nine hours ahead of "correct Japan time" is 18 hours ahead of Greenwich -- suggesting that one VM "system clock" had JST time rather than Greenwich time. For each host, please show us the full output of:

echo $TZ
tail -n1 /etc/localtime
cat /var/db/zoneinfo
TZ="" date
date

 

[SirDice]

Note that the entire FreeBSD 12 major branch has been EoL since December 2023 and is not supported any more.

Unsupported FreeBSD Releases

FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms.

www.freebsd.org

 

[roomn]

Thank you for your comment, gpw928. I executed the command you told me.

VM

• Guest OS: FreeBSD 12.1
• Timezone (set during VM creation in Prism): Asia/Tokyo
• Guest OS Timezone: JST-9 (output of tail -n1 /etc/localtime)
• Result of date command: 9 hours ahead of the correct Japan time.

This is the result of "VM". I executed this command at 3:50 PM Japan time on October 4th.

VM2

• Guest OS: FreeBSD 12.3
• Timezone (set during VM creation in Prism): Asia/Tokyo
• Guest OS Timezone: JST-9 (output of tail -n1 /etc/localtime)
• Result of date command: correct Japan time

This is the result of "VM1". I executed this command at 4:11 PM Japan time on October 4th.

 

[gpw928]

The shell to use when executing those commands is /bin/sh (not csh(1)).

I'm going to skip looking for the root cause, and go straight to the fix.

Are you running any sort of external time synchronisation?

If your FreeBSD VMs can reach the Internet, you can use ntpd(8) to fix the problem.

Setting these values in /etc/rc.conf and rebooting should sync your time correctly:

ntpd_enable="YES"
ntpd_sync_on_start="YES"

For virtual machines which can be "suspended" for any reason you should add the following to /etc/ntp.conf:

tinker panic 0                          # VirtualMachine

 

[roomn]

Thank you for your reply. I recognize that the command you provided is effective in resolving the issue. However, I need to solve the problem in an environment where NTP cannot be used. In such cases, I am aware that placing or deleting /etc/wall_cmos_clock depending on the hardware clock’s time zone can address the issue. What I most wanted to know is why this change in the hardware clock occurred due to the FreeBSD version upgrade. Do you have any ideas about the cause?

 

[gpw928]

It's not forensically possible to condider all the combinations that may have led to your situation. FreeBSD 12 is end of life, and your hypervisor is an opaque participant.

However, you have identified the root cause of the problem.

When you initially install FreeBSD you get asked if the "system clock" is running GMT (a.k.a. Zulu) time or local time.

/etc/wall_cmos_clock is created if you answer "local".

I can't be more specific about the mechanism or what might happen in the context of the upgrade process.

I expect that your hypervisor is supplying "JST-9" time for the "system clock"

Is that configurable on the hypervisor side?

If not, I expect that the correct configuration for both systems would be to have /etc/wall_cmos_clock present.