Lévai, Dániel <[email protected]> writes:
> Turns out the clock stopped every night at the time when backups were > running and thus the VM was paused (saved, or 'managedsaved' if > someone uses libvirt) for a minute. > Not sure why, though; while I was testing pause/resume the clock > didn't stop, it just failed to get synced by ntpd(8). Maybe over time > the drift was too much? >From my experience, ntp daemons will try not to just jump the clock forward or backwards by too great an amount and instead increase or decrease time advancement to try to sync. It's indeed possible you drifted too far for ntpd to handle through this method. You might want to look into installing the Qemu guest agent in OpenBSD vms: https://marc.info/?l=openbsd-ports&m=158936392710472&w=2 Usually these agents handle properly setting the rtc after a suspend/resume cycle of the vm. (That's what the vmmci(4) driver does, for instance, in OpenBSD guests running atop OpenBSD's vmd(8).) > > Anyway, the rather curious thing was ntpd(8) not syncing the clock > properly after resume, so I ended up giving the 'trusted' option to > the server I'm using here. Strangely, it still took quite some time > [1], but in the end it managed to sync - so I guess this should work > in the long run. > > > [1] > Jan 30 11:50:33 ntpd[83421]: peer 148.6.0.1 now valid > Jan 30 11:54:37 ntpd[4758]: adjusting local clock by 23.831836s > Jan 30 11:54:37 ntpd[83421]: clock is now synced > Jan 30 11:54:37 ntpd[83421]: constraint reply from 9.9.9.9: offset 23.653130 > Jan 30 11:57:48 ntpd[4758]: adjusting local clock by 22.879877s > Jan 30 11:57:48 ntpd[83421]: clock is now unsynced > Jan 30 12:01:34 ntpd[4758]: adjusting local clock by 21.754396s > Jan 30 12:04:51 ntpd[4758]: adjusting local clock by 20.774539s > Jan 30 12:08:33 ntpd[4758]: adjusting local clock by 19.670413s > Jan 30 12:12:43 ntpd[4758]: adjusting local clock by 18.426017s > Jan 30 12:17:04 ntpd[4758]: adjusting local clock by 17.127167s > Jan 30 12:21:19 ntpd[4758]: adjusting local clock by 15.857846s > Jan 30 12:21:53 ntpd[4758]: adjusting local clock by 15.688043s > Jan 30 12:25:30 ntpd[4758]: adjusting local clock by 14.613690s > Jan 30 12:29:49 ntpd[4758]: adjusting local clock by 13.323883s > Jan 30 12:33:32 ntpd[4758]: adjusting local clock by 12.204646s > Jan 30 12:34:06 ntpd[4758]: adjusting local clock by 12.036162s > Jan 30 12:35:10 ntpd[4758]: adjusting local clock by 11.712658s > Jan 30 12:36:13 ntpd[4758]: adjusting local clock by 11.412870s > Jan 30 12:39:55 ntpd[4758]: adjusting local clock by 10.308062s > Jan 30 12:43:34 ntpd[4758]: adjusting local clock by 9.208613s > Jan 30 12:44:07 ntpd[4758]: adjusting local clock by 9.048595s > Jan 30 12:47:48 ntpd[4758]: adjusting local clock by 7.950845s > Jan 30 12:49:27 ntpd[4758]: adjusting local clock by 7.460912s > Jan 30 12:53:08 ntpd[4758]: adjusting local clock by 6.360250s > Jan 30 12:56:22 ntpd[4758]: adjusting local clock by 5.385971s > Jan 30 12:56:53 ntpd[4758]: adjusting local clock by 5.241883s > Jan 30 13:01:13 ntpd[4758]: adjusting local clock by 3.951414s > Jan 30 13:04:22 ntpd[4758]: adjusting local clock by 3.009970s > Jan 30 13:07:05 ntpd[4758]: adjusting local clock by 2.201024s > Jan 30 13:11:18 ntpd[4758]: adjusting local clock by 0.937320s > Jan 30 13:12:22 ntpd[4758]: adjusting local clock by 0.613777s > Jan 30 13:13:27 ntpd[4758]: adjusting local clock by 0.285335s > Jan 30 13:14:32 ntpd[83421]: clock is now synced
