3

I'm tasked with rebuilding a LAN server that's serving as the NTP server for hundreds of client machines. Unfortunately, it's on a virtual machine, and as demonstrated by questions like What are the limits of running NTP servers in virtual machines? that's far from ideal.

However, in current circumstances, this is what I have to work with, until the hundreds of machines relying on this server have been reconfigured for a more robust NTP setup, somewhere in the future.

Fortunately, the clients don't rely on millisecond accuracy. I've been planning on running Chrony on the new server, configuring it to use four local stratum 2 servers.

I'm new to NTP serving, and new to Chrony. What server-side settings would you consider essential for this situation? The goal is to minimize inaccuracy given the fundamental constraints of running an NTP server on a virtual machine in the first place.

JK Laiho
  • 195
  • 9

1 Answers1

5

The question you linked to is a good example of received wisdom in an established answer becoming so out-of-date as to be just plain wrong for the majority of use cases. Running NTP servers in VMs on modern hypervisors with modern guest kernels is not usually problematic. On a LAN, VMs can achieve sub-millisecond accuracy (I just checked a few of my own VMs and they were all sub-0.5 ms). Many of the public pool servers run in VMs.

To your question:

  1. Verify that your kernel has correctly autodetected the clock source: grep . /sys/devices/system/clocksource/clocksource*/[ac]*clocksource. This is typically tsc for bare metal, and Hyper-V, KVM, and Xen have clock drivers which are named for their hypervisor (hyperv_clocksource_tsc_page, kvm-clock, and xen).
  2. If you're running under KVM or Hyper-V, you can configure a local PTP driver which provides additional accuracy. See https://docs.microsoft.com/en-us/azure/virtual-machines/linux/time-sync and https://opensource.com/article/17/6/timekeeping-linux-vms for more details (the latter is a worthwhile read explaining all of the recent improvements which make timekeeping in VMs much better than it used to be). TL;DR for chrony config: refclock PHC /dev/ptp0 dpoll -2
  3. Four peers is a minimum for accurate timekeeping - better to add the public NTP pool or some additional Internet-based sources (time.apple.com is one I often use) and benefit from both more peers and automatic replacement.
  4. Don't have your new VM as the only time server in your network. Set up your own local equivalent of the pool, where you provide multiple NTP servers for all clients via a multi-valued DNS entry, and have each of these sources peer with 4-10 lower-stratum sources.
  5. If you have a view of the sky (for a GPS receiver) or endless money (for an atomic clock), consider adding a local stratum 1 server which has low latency to your VMs. I use a BeagleBone with a GPS card; there are also many Raspberry Pi-based solutions, and a few affordable off-the-shelf devices, like LeoNTP.
Paul Gear
  • 3,938
  • 15
  • 36
  • 1
    Excellent, thank you. You know, I had a hunch that the information might no longer be current, because of the seeming lack of authoritative sources, but for whatever reason my Google results were pretty much unanimous on "VMs bad". Hopefully this will start popping up in searches for others to find. – JK Laiho Apr 30 '21 at 11:49