Proxmox VE 8.4.14 - Chrony Not Syncing Time

msw1970

New Member
Oct 26, 2025
2
0
1
Hi

I'm having some trouble getting the Proxmox hosts in a 2 node cluster to sync their time via chrony. I have the following setup...

2 Windows Domain Controllers - The primary domain controller (owner of the FSMO role) is configured to sync it's time from uk.pool.ntp.org using NTP. This is syncing successfully. The second domain controller is configured to sync it's time from the first domain controller using standard windows time sync (NT5DS).

I then have 6 x Ubuntu 24.04 servers all configured to sync their time, using chrony, from the 2 domain controllers. All 6 are successfully syncing their time.

The 2 nodes in the Proxmox cluster are also configured to sync their time from the same 2 domain controllers, using an identical chrony.conf file as the 6 Ubuntu servers, however, neither of them is able to successfully sync their time.

The output of chronyc sources -v shows both domain controllers as unusable dispite at least one of them having a reachability register of 377 which indicates that a valid reply was received for all from the last eight transmissions. (See below)

Code:
root@PROXMOX01:~# chronyc sources -v

  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current best, '+' = combined, '-' = not combined,
| /             'x' = may be in error, '~' = too variable, '?' = unusable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \
MS Name/IP address         Stratum Poll Reach LastRx Last sample              
===============================================================================
^? wgb01dc1001.internal.web>     2   8     7    73  +310.7s[+310.7s] +/- 7628ms
^? fd72:2959:1aa6:b7d1:a1f9>     3   4   377     3  +310.4s[+310.4s] +/-  15.5s

And the output of chronyc tracking shows

Code:
root@PROXMOX01:~# chronyc tracking
Reference ID    : 00000000 ()
Stratum         : 0
Ref time (UTC)  : Thu Jan 01 00:00:00 1970
System time     : 0.000000027 seconds slow of NTP time
Last offset     : +0.000000000 seconds
RMS offset      : 0.000000000 seconds
Frequency       : 492.022 ppm fast
Residual freq   : +0.000 ppm
Skew            : 0.000 ppm
Root delay      : 1.000000000 seconds
Root dispersion : 1.000000000 seconds
Update interval : 0.0 seconds
Leap status     : Not synchronised

Does anyone know any way to get this working successfully??
 
Welcome to the Forum!

Out of curiosity I "googled" some longer time and haven't found a reason / a solution. I'm out of ideas apart from this:

you have written that the chrony.conf files in the PVE nodes are identical to these in the Ubuntu servers.

Is there any chance that there is an additional file that is introducing a difference to the configurations? I mean that there are subdirectories in /etc/chrony/ and there might be additional files...

Another idea is: would you mind posting the configuration files? (In the CODE tags - to preserve the formatting).
Maybe someone will spot something unusual.
 
Here's the chrony.conf from a working Ubuntu server

Code:
# Welcome to the chrony configuration file. See chrony.conf(5) for more
# information about usable directives.

# Include configuration files found in /etc/chrony/conf.d.
confdir /etc/chrony/conf.d

# This will use (up to):
# - 4 sources from ntp.ubuntu.com which some are ipv6 enabled
# - 2 sources from 2.ubuntu.pool.ntp.org which is ipv6 enabled as well
# - 1 source from [01].ubuntu.pool.ntp.org each (ipv4 only atm)
# This means by default, up to 6 dual-stack and up to 2 additional IPv4-only
# sources will be used.
# At the same time it retains some protection against one of the entries being
# down (compare to just using one of the lines). See (LP: #1754358) for the
# discussion.
#
# About using servers from the NTP Pool Project in general see (LP: #104525).
# Approved by Ubuntu Technical Board on 2011-02-08.
# See http://www.pool.ntp.org/join.html for more information.
#pool ntp.ubuntu.com        iburst maxsources 4
#pool 0.ubuntu.pool.ntp.org iburst maxsources 1
#pool 1.ubuntu.pool.ntp.org iburst maxsources 1
#pool 2.ubuntu.pool.ntp.org iburst maxsources 2
server wgb01dc1001.internal.websternet.org.uk iburst
server wgb01dc1002.internal.websternet.org.uk iburst

# Use time sources from DHCP.
sourcedir /run/chrony-dhcp

# Use NTP sources found in /etc/chrony/sources.d.
sourcedir /etc/chrony/sources.d

# This directive specify the location of the file containing ID/key pairs for
# NTP authentication.
keyfile /etc/chrony/chrony.keys

# This directive specify the file into which chronyd will store the rate
# information.
driftfile /var/lib/chrony/chrony.drift

# Save NTS keys and cookies.
ntsdumpdir /var/lib/chrony

# Uncomment the following line to turn logging on.
#log tracking measurements statistics

# Log files location.
logdir /var/log/chrony

# Stop bad estimates upsetting machine clock.
maxupdateskew 100.0
maxdistance 16.0

# This directive enables kernel synchronisation (every 11 minutes) of the
# real-time clock. Note that it can’t be used along with the 'rtcfile' directive.
rtcsync

# Step the system clock instead of slewing it if the adjustment is larger than
# one second, but only in the first three clock updates.
makestep 1 -1

# Get TAI-UTC offset and leap seconds from the system tz database.
# This directive must be commented out when using time sources serving
# leap-smeared time.
leapsectz right/UTC

And from one of the PVE nodes

Code:
# Welcome to the chrony configuration file. See chrony.conf(5) for more
# information about usable directives.

# Include configuration files found in /etc/chrony/conf.d.
confdir /etc/chrony/conf.d

# Use Debian vendor zone.
#pool 2.debian.pool.ntp.org iburst
server wgb01dc1001.internal.websternet.org.uk iburst
server wgb01dc1002.internal.websternet.org.uk iburst

# Use time sources from DHCP.
sourcedir /run/chrony-dhcp

# Use NTP sources found in /etc/chrony/sources.d.
sourcedir /etc/chrony/sources.d

# This directive specify the location of the file containing ID/key pairs for
# NTP authentication.
keyfile /etc/chrony/chrony.keys

# This directive specify the file into which chronyd will store the rate
# information.
driftfile /var/lib/chrony/chrony.drift

# Save NTS keys and cookies.
ntsdumpdir /var/lib/chrony

# Uncomment the following line to turn logging on.
#log tracking measurements statistics

# Log files location.
logdir /var/log/chrony

# Stop bad estimates upsetting machine clock.
maxupdateskew 100.0
maxdistance 16.0

# This directive enables kernel synchronisation (every 11 minutes) of the
# real-time clock. Note that it can't be used along with the 'rtcfile' directive.
rtcsync

# Step the system clock instead of slewing it if the adjustment is larger than
# one second, but only in the first three clock updates.
makestep 1 -1

# Get TAI-UTC offset and leap seconds from the system tz database.
# This directive must be commented out when using time sources serving
# leap-smeared time.
leapsectz right/UTC

There's nothing in the subdirectories under/etc/chrony/ except README files
 
Hi msw1970,

the configuration file content would be very helpful, as well as everything relatet to the namereaolution. Are the Ubuntu VMs part of the domain?

There could be several reasons, why chrony is not accepting the provided sources as valid. (e.g. DCs Firewall rules, name resolution issues or a required minum amount of time sources,)

I personally would not like to make my hypervisors depended on the workload, due to segregation of duties from security perspective. Anyways in a test setup or a setup with specific requirements, that might be fine.

BG, Lucas
 
maxdistance 16.0
This directive is one of the not default directives in your config.
I'm not saying it is bad. I admit I'm not sure after checking the manual if I understand its meaning.
I have never used it. In my Ubuntu workstation and in my PVE host it isn't used at all.
And the machines always synchronize to the Internet sources quickly and easily without it.

I would start with the default settings, at least I would omit maxdistance and check whether the situation improves itself without this directive.