On Mon, Sep 17, 2018 at 4:20 AM, Rick Payne <ri...@rossfell.co.uk> wrote:
> On Mon, 2018-09-17 at 01:41 +0300, Nadav Har'El wrote: > > I have a wild guess, but I'm not a big clock expert, and I'm CCing > > Glauber who might have better ideas. > > > > My guess is that you have ntp running in the *host*, but not in the > > guest (we don't have an ntp client for OSv), and somehow this is > > causing this drift in wall-clock time between the two. My guess (and > > again, this is a guess, I don't know if that's true), that the > > adjtime / adjtimex / ntp_adjtime or whatever system call that ntp > > uses to gradually adjust the time in the host, doesn't cause the same > > adjustment to be propagated to the guest by the paravirtual clock > > mechanism (which probably relies on the clock frequency being fixed, > > while adjtime tweaks it a bit). > > So I'm on a boat, and no NTP server - however you seem to have nailed > it. > On one hand, it's great that we understand this now, but on the other hand it's very sad that although the host keeps accurate time (or at least thinks that it does), it cannot just pass it to the guest (via kvm-clock) as we always implicitly assumed that it does. It seems to me (but again, I'm not an expert on this), that if QEMU or KVM is unable to track the host ntp's adjtime() modifications, it needs to modify the *wall clock* value periodically to track the host's changing notion of how long ago the epoch was. I suspect that this issue is not specific to OSv guests, and will also occur on Linux guests which do not run ntpd inside them. If this is indeed the case (and it would be great if you could verify this), I think we should ask from advice from the KVM experts on the KVM mailing list, what can be done. Popular wisdom on the web suggests that you must run an ntp client on your guest as well, and with some effort we can get some ntp client (e.g., chrony working on OSv). But in the long run, that would be sad for KVM - if KVM has the opportunity to pass the guest a perfectly accurate clock (based on ntp running in the host) it would be a waste not to seize that opportunity, and I wonder if there's a reason why not. > > > > > You can verify this guess by stopping the ntpd/chronyd demon in the > > host and seeing if the drift remains or goes away. > > I turned off the systemd timesync (timedatectl set-ntp off) and now it > all works perfectly. > Wow, it's so sad to see that systemd took over yet another stand-alone daemon. Yet another nail the coffin of the Unix philosophy :-( -- You received this message because you are subscribed to the Google Groups "OSv Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to osv-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
