Re: Chrony client on host with server running in LXC on same host
Joachim Tingvold <joachim-5aLZm4DENTRWk0Htik3J/[email protected]> Tue, 03 Feb 2026 20:32:31 +0100
| Newsgroups | gmane.comp.time.chrony.user |
|---|---|
| Message-ID | <[email protected]> |
--=_MailMate_08CADE09-D1CF-4598-8ED2-1E09A47C2EDE_= Content-Type: text/plain; charset=UTF-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit 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 --=_MailMate_08CADE09-D1CF-4598-8ED2-1E09A47C2EDE_= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <!DOCTYPE html> <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/xhtml; charset=3Dutf-8"= > </head> <body><div style=3D"font-family: sans-serif;"><div class=3D"markdown" sty= le=3D"white-space: normal;"> <p dir=3D"auto">On 3 Feb 2026, at 15:31, Miroslav Lichvar wrote:</p> <blockquote style=3D"margin: 0 0 5px; padding-left: 5px; border-left: 2px= solid #777777; color: #777777;"> <p dir=3D"auto">The ability to run independently from the system clock is= possible in<br> theory, and it's a planned feature for the next chrony version, but<br> nothing concrete yet.</p> </blockquote> <p dir=3D"auto">It would be awesome if chrony gets support for some kind = of decoupling from the system clock (regardless if chrony is running on t= he host or in a container of some kind).</p> <blockquote style=3D"margin: 0 0 5px; padding-left: 5px; border-left: 2px= solid #777777; color: #777777;"> <p dir=3D"auto">My suggestion would be to run the server together with th= e client on<br> the host. If that's not possible, run the server in a virtual machine,<br= > which has its own clock.</p> </blockquote> <p dir=3D"auto">I hadn=E2=80=99t thought of the VM-approach in terms of h= aving the ability to decouple it from the host clock. Thanks for that sug= gestion.</p> <p dir=3D"auto">Apparently there are some config required on certain virt= ualization systems to properly decouple the VM from the host clock. A fri= end 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 latt= er, it seems you need to set =E2=80=9C-rtc base=3Dutc,clock=3Dvm=E2=80=9D= for the VM clock to be properly decoupled from the host.</p> <p dir=3D"auto">For Proxmox, this can be achieved by using the following = command:</p> <p dir=3D"auto">qm set <VM ID> --args "-rtc base=3Dutc,clock=3D= vm"</p> <blockquote style=3D"margin: 0 0 5px; padding-left: 5px; border-left: 2px= solid #777777; color: #777777;"> <p dir=3D"auto">A client synchronizing to other time sources and a separa= te server<br> instance running on the same host using the -x option is ok. There is<br>= no loop.</p> </blockquote> <p dir=3D"auto">That was my =E2=80=9Cplan B=E2=80=9D-approach; run chrony= <em>without</em> 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=E2=80=99= t run any chrony instance at all on those two hosts.</p> <p dir=3D"auto">However, if you want to move the LXC-containers around (l= ive-migrate or similar), that becomes more tricky, since =E2=80=9Call the= other=E2=80=9D hosts <em>is</em> 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).</p> <p dir=3D"auto">--<br> Joachim</p> </div> </div> </body> </html> --=_MailMate_08CADE09-D1CF-4598-8ED2-1E09A47C2EDE_=-- -- To unsubscribe email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org with "unsubscribe" in the subject. For help email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org with "help" in the subject. Trouble? Email [email protected]