Otto Moerbeek wrote: > So it looks like the hyperv0 sensor is giving wrong information occasionally. > > As a workaround, you can try to disable the sensor line in ntpd.conf. > After that, set the time to something a bit behind the real time and > reboot. That should give you proper time (in automatic mode, ntpd will > only jump the clock forward).
This occurred on a VM that I was preparing to run in production with Ansible, and part of that preparation involves a reboot after disabling smtpd. The workaround I've implemented is to put "rcctl disable ntpd" into my install.site script in siteXX.tgz for future deployments. If this VM were important, rdate may also help repair the system clock. > I like your suggestion to also subject sensors to constrainst, I'll put > in on my todo list. > > Having said that, a sensor providing rogue time is bad, so can you > tell more about yout VM host? I might try to reproduce (and fix) the > sensor bug before doing the constraint thing. The Hyper-V host is a year-old Windows 10 Pro workstation running build 10.0.17763.805. It had only been up for about 8-9 days when this issue manifested on one of the VMs. It's the first time I've ever seen something like this happen to a VM's clock. I noticed that overall VM performance was fairly poor that day -- I run Ansible from a VM and the playbook I use to configure OpenBSD VMs was taking 4 hours to complete -- and the CPU utilization was consistently high, so I restarted the host today and the playbook finished in about 2 hours 45 minutes, so high load on the Hyper-V host may be a factor. I paused this affected VM before restarting the host in case it warrants further investigation. Toby
