On 3 Feb 2026, at 15:31, Miroslav Lichvar wrote:
The ability to run independently from the system clock is possible in theory, and it's a planned feature for the next chrony version, but nothing concrete yet.
It would be awesome if chrony gets support for some kind of decoupling from the system clock (regardless if chrony is running on the host or in a container of some kind).
My suggestion would be to run the server together with the client on the host. If that's not possible, run the server in a virtual machine, which has its own clock.
I hadn’t thought of the VM-approach in terms of having the ability to decouple it from the host clock. Thanks for that suggestion.
Apparently there are some config required on certain virtualization systems to properly decouple the VM from the host clock. A friend of mine mentioned he needed to do some very specific steps in VMware, and I also found that to be true for QEMU/KVM. Specifically for the latter, it seems you need to set “-rtc base=utc,clock=vm” for the VM clock to be properly decoupled from the host.
For Proxmox, this can be achieved by using the following command: qm set <VM ID> --args "-rtc base=utc,clock=vm"
A client synchronizing to other time sources and a separate server instance running on the same host using the -x option is ok. There is no loop.
That was my “plan B”-approach; run chrony _without_ the -x flag inside the ntp1+2 LXC containers, and allow those two LXC containers to set the time of the host (by giving the two LXC containers the CAP_SYS_TIME capability), and then simply don’t run any chrony instance at all on those two hosts.
However, if you want to move the LXC-containers around (live-migrate or similar), that becomes more tricky, since “all the other” hosts _is_ running a chrony client, making the VM-approach the better choice (or at least the most flexible, since all the hosts are equally configured, and the two VMs can be moved around if-need-be without having to change anything on the hosts).
-- Joachim
