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.
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.