Server time drift on FreePBX HyperV VM

I have FreePBX running as a VM in HyperV. The timezone is correct in the WEB GUI. It’s was trouble free for months, but just recently the server time has drifted by a couple of minutes. Initially the time synchronization service was turned on in HyperV. In troubleshooting the issue I can’t tell if ntpd or chronyd is supposed to be responsible for the freepbx server time. I would prefer to either just have the HypverV host be responsible for the time, or sync the server clock to the local pfsense firewall which is also providing NTP. I have tried setting the time synchronization in HyperV integration services on and off and the problem seems to occur either way. So I guess the real questions would be should I use the HyperV integration services at all for the freepbx server time, and if not, which service on the freepbx server is responsible for the server time? I’m not a linux guru at all, so please be kind regarding explanations. Thanks for any help in advance.

You should normally synchronise the VM host and use its capabilities for synchronising the guests; time can run at variable rates in VMs, although a VM that has significant variation in the time rate will result in excessive jitter,

1 Like

Most likely it’s your host that is drifting and feedback is pushing the FreePBX Instance.

This is a HUGE bug with Hyper-V and we usually see it when we have Domain Controllers running as VM’s on Hyper-V and the tech forgets to uncheck “Time Sync Services” under the VM settings - because Domain Controllers are the authoritative time servers for any domain, if the Hyper-V Host is a joined member server, it’s asking the DC for a time sync - and then feeding a time adjustment back to the DC through integration - so you get into a race condition - we have seen some setups lose more than an hour in a day!

So, simple solution is to NOT have the Hyper-V host feed time information to the VM, instead have the VM sync to external time servers and the problem should go away.

1 Like

Thanks for the responses guys. In this case, the Hyper-V host is syncing with an external time source. There is a VM running as a DC in this environment and it is set to sync to said host, and the host is part of the domain. I’ve read this solution is acceptable as well, so long as the host is looking to an external source for NTP the VM’s (those set to use integration services) should all be in sync. And in this case they are. All the other VM’s (9 in total) are fine except for FreePBX. That’s what is sort of confusing.

If I did decide to set the DC as the clock source, and uncouple all other VM’s from the host and point everything at the DC, what service in FreePBX is responsible for syncing with it? Is it ntpd or chronyd? And would it be as simple as putting the IP of the DC in the conf file for that perspective service and restarting it. Thanks.

lsof -i :123

1 Like

Yeah, that’s the current configuration… What’s strange is that all the other VM’s are sync’d with the host except for FreePBX. It’s the only one that’s drifting. Hence why I was going to just unsync it from the host and either sync it by ip to the router or an external source. I’m just confused as to which service in FreePBX is responsible for the server time. Thanks.

lsof -i :123

will show any service running the time protocol, if they are working or not is another matter

1 Like

Thank you dicko… So it’s chronyd according to the result, and a service status check confirms it is running. So if the VM is not using integration services to sync, is it as simple as putting the ip of an internal or external NTP provider in the chrony.conf file and restarting the service? Thanks.

and making sure the firewall passes it as running is not quite the same as working :wink: . Using an Internal ntp server might be counter productive in a HyperV environment if you think about it :slight_smile:

1 Like

Yeah, firewall is passing NTP just fine… And the FreePBX server is now syncing with an external source. I’m still a bit confused though. There is no pool listed in the etc/chrony.conf file… Which is puzzeling as it’s pulling from a list of 4 external sources. Also, when I try to put a local server entry into the file, and restart the service, it doesn’t seem to change a thing. It’s still pulling from the same four external sources. It’s as if no matter what is in the etc/chrony.conf file it’s ignoring the entry. Am I missing something obvious here? The following is the chrony.conf file…

 # These servers were defined in the installation:
# server gateway iburst
# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
server 10.0.20.1

# Record the rate at which the system clock gains/losses time.
driftfile /var/lib/chrony/drift

# Allow the system clock to be stepped in the first three updates
# if its offset is larger than 1 second.
makestep 1.0 3

# Enable kernel synchronization of the real-time clock (RTC).
rtcsync

# Enable hardware timestamping on all interfaces that support it.
#hwtimestamp *

# Increase the minimum number of selectable sources required to adjust
# the system clock.
#minsources 2

# Allow NTP client access from local network.
#allow 10.0.20.1/16

# Serve time even if not synchronized to a time source.
#local stratum 10

# Specify file containing keys for NTP authentication.
#keyfile /etc/chrony.keys

# Specify directory for log files.
logdir /var/log/chrony

# Select which information is logged.
#log measurements statistics tracking

https://www.tecmint.com/install-chrony-in-centos-ubuntu-linux/

1 Like

I appreciate it, but I’ve already been through all of those commands. Again, it’s almost as if chrony is ignoring the chrony.conf file and pulling from a different source or something. It’s not system breaking or anything, just confusing.

Found it… It doesn’t use etc/chrony.conf for it’s configuration, it’s using etc/sangoma_chrony.conf… This is where the changes for the time server need to be made. Thanks for the help dicko.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.