Hosting a Public NTP Server on a Proxmox VM: Good or Bad Idea?
Time is a silent pillar of any infrastructure: TLS, logs, replication, Kerberos — everything relies on a reliable clock. At RDEM Systems, we operate a public NTP pool , part of which runs on Proxmox VMs. Here is our real-world feedback.
Clock drift in VMs: why it happens
On a bare-metal server, the OS has direct access to the hardware clock (RTC, TSC). In a VM, things are different: the hypervisor virtualizes the clock. The CPU is shared among multiple VMs, and each one only receives its cycles in slices. The result: the VM clock can drift.
Bare-metal vs VM: clock access
Bare-metal
Virtual machine
The main drift factors in a VM: steal time (shared CPU), live migration (VM pause), and suspend/resume.
This clock drift is manageable for most use cases — provided you use the right synchronization tool.
To understand the concrete impacts of a desynchronized clock, read our article Why NTP accuracy is critical in virtualized environments (fr) : invalid TLS certificates, Kerberos failures, replica corruption — the consequences are very real.
Chrony vs ntpd vs systemd-timesyncd
Three NTP daemons coexist in the Linux ecosystem. Their behavior in VMs differs significantly.
| Criterion | Chrony | ntpd | timesyncd |
|---|---|---|---|
| Resync after suspend | Fast | Slow (minutes) | Average |
| NTP server mode | Yes | Yes | No |
| Time step (makestep) | Native | -g flag | N/A |
| Burst mode | iburst | iburst | No |
| NTS (Network Time Security) | Yes | No | No |
| VM suitability | Excellent | Passable | Client only |
Verdict: For an NTP server in a VM, Chrony is the obvious choice. It was designed for environments where the clock drifts (VMs, laptops, containers). It resynchronizes in seconds after a live migration, whereas ntpd can take several minutes. Moreover, Chrony is the only one to support NTS (Network Time Security) , the security extension for the NTP protocol.
Optimal Chrony configuration for a public NTP server in a VM
Here is a /etc/chrony/chrony.conf configuration tailored for a public NTP server hosted on a Proxmox VM. Each directive is commented.
The key directive for VMs is makestep 0.1 5: it allows Chrony to forcefully correct the clock if the offset exceeds 100ms during the first exchanges — typically after a reboot, migration or suspend.
Visit ntp.rdem-systems.com to see our public NTP pool in production, powered by this configuration.
VM vs LXC vs bare-metal for hosting NTP
The choice of hosting type directly impacts NTP service quality. Here is a comparison:
| Criterion | VM (KVM) | LXC | Bare-metal |
|---|---|---|---|
| Clock | Virtual (kvm-clock) | Shared with host | Direct hardware |
| Independent Chrony | Yes | No (host clock) | Yes |
| PPS / GPS access | No | No | Yes |
| Typical accuracy | ~0.5–2 ms | = host accuracy | < 1 µs (with PPS) |
| Recommended stratum | 2 or 3 | Not suitable (no control) | 1 (with GNSS) |
| Live migration | Causes a jump | N/A | N/A |
| Isolation | Full | Partial | Full |
Why not LXC?
An LXC container shares the host's clock: it cannot run its own NTP daemon independently. If the host drifts, the container drifts too. To serve NTP to external clients, you need a clock you control — meaning a VM or bare-metal.
The honest verdict
Proxmox VM: perfect for Stratum 2/3
- ~1 ms accuracy — sufficient for 99% of use cases
- TLS, Kerberos, logs, replication: no issues
- Chrony compensates clock drift automatically
- Easily redundant (multiple VMs on different hosts)
Bare-metal: required for Stratum 1
- Direct access to GNSS receiver (GPS, Galileo)
- PPS signal via GPIO or serial port
- Sub-microsecond accuracy required
- Hardware interrupts without virtualization
Our experience: the RDEM Systems NTP pool
At RDEM Systems, we operate a public NTP pool that combines both approaches:
Architecture of the ntp.rdem-systems.com pool
Raspberry Pi + GNSS
VM Proxmox + Chrony
The Stratum 1 provides the absolute time reference. The Stratum 2 VM relays distribute time to clients.
This hybrid architecture allows us to combine the absolute accuracy of bare-metal GNSS with the flexibility and redundancy of Proxmox VMs. Site details, the autonomous AS206014 network and the history since 2005 are documented on our NTP infrastructure page .
You can check your machine's synchronization directly from our website. And for NTP security, see our page on NTS (Network Time Security) .
Best practices for NTP on a Proxmox VM
Operational checklist
- Install qemu-guest-agent in the VM: allows Proxmox to communicate with the VM (fsfreeze, clean shutdown)
- Chrony on the host too: the Proxmox hypervisor must itself be synchronized — a reliable hardware clock benefits all VMs
- Monitor the offset: watch
chronyc tracking— an offset > 10ms is a warning sign - Reliable NTP sources: prefer well-known Stratum 1 servers (PTB, NIST, your own GNSS) rather than the public pool alone
- Minimum 3 sources: Chrony can detect and exclude a faulty source with at least 3 upstream servers
- Aggressive polling in VMs:
minpoll 4 maxpoll 6(16s–64s) compensates for more frequent drift - Test after live migration: verify that Chrony resynchronizes within seconds after a VM move
Summary table
| Scenario | Recommendation |
|---|---|
| Public NTP Stratum 2/3 | Proxmox VM + Chrony — reliable and flexible |
| NTP Stratum 1 GNSS | Bare-metal required — PPS access needed |
| Enterprise internal NTP | VM more than sufficient |
| High-frequency trading | Bare-metal + PTP — sub-µs accuracy |
| Simple NTP client | VM, LXC or bare-metal — all suitable |
| NTP daemon in LXC | Not recommended — clock shared with host |
Frequently asked questions
Official documentation
To dive deeper into the concepts covered in this article:
Related articles
Our 3-2-1 backup strategy
PBS, deduplication, verify jobs and ransomware protection across 4 datacenters.
Migrating from VMware to Proxmox
Complete guide: methodology, tools and pitfalls to avoid.
GPU, USB & PCI Passthrough on Proxmox
IOMMU, VFIO, groups, ROM BAR — the complete guide.
Docker on Proxmox: VM, LXC or Docker-in-LXC?
Performance, security and use case comparison.
Need a time-synced Proxmox infrastructure?
We deploy and monitor NTP servers, configure Chrony on your Proxmox clusters, and operate a public NTP pool that you can use freely.