On Sun, Mar 15, 2015 at 7:50 PM, Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> wrote: > On Sun, Mar 15, 2015 at 07:47:46PM +0100, Kay Sievers wrote: >> On Fri, Mar 13, 2015 at 8:25 PM, Michael Marineau >> <michael.marin...@coreos.com> wrote: >> > Greetings, >> > >> > Currently systemd-timesyncd.service includes >> > ConditionVirtualization=no, disabling it in both containers and >> > virtual machines. Each VM platform tends to deal with or ignore the >> > time problem in their own special ways, KVM/QEMU has the kernel time >> > source kvm-clock, Xen has had different schemes over the years, VMware >> > expects a userspace daemon sync the clock, and other platforms are >> > content to drift with the wind as far as I can tell. >> > >> > I don't know of a robust way to know if a platform needs a little >> > extra help from userspace to keep the clock sane or not but it seems >> > generally safer to try than to risk drifting. Does anyone know of a >> > reason to leave timesyncd off by default? Otherwise switching to >> > ConditionVirtualization=!container should be reasonable. >> >> Sounds reasonable. Until someone has a better or clear idea how to >> solve that reliably, I turned the option around. > What about adding > > ConditionVirtualization=!kvm ?
Even there, things like leap seconds are not covered. And I'm not sure if the "paravirtualized clock" is always configured. I guess it's safest bet to just keep timesyncd running, until someone knows for sure when we can optimize it away for which environment. Kay _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
