When running a DragonFlyBSD system as a guest OS virtual machine under the Bhyve hpervisor running under FreeBSD as the host I ran into an issue where the clock on the DragonFlyBSD vm was way off and had to do a coarse time adjustment shortly after boot.
Dec 2 11:04:03 dragonflybsdvm dntpd[541]: issuing COARSE offset adjustment: -21598.706669s, 02-Dec-2021 11:04:03.591
This caused things like WireGuard to fail do to the large time adjustment. So WireGuard had to be restarted, which was a pain. WireGuard has trouble if the clock changes while it is running.
It turns out that DragonFlyBSD was assuming that the clock was set to local time, whereas Bhyve was setting it to UTC. Bhyve defaults to setting the clock to UTC in later versions. (This may actually be the vm-bhyve utility that has this default– see below).
The simple solution was to modify the conf file for the vm to set the clock to localtime instead of UTC.
I use vm-bhyve to manage my virtual machines. So the fix is easily achieved in the conf file for the DragonFlyBSD vm:
#other config options like cpu/memory and network settings. ... utctime="no" ...
That’s all you have to do (do a full shutdown of the vm, and start it back up to see the change, rebooting the vm will not affect the change). Just put that line in the conf file that you use when running the vm utility from vm-bhyve.
From the manpage for vm (part of vm-bhyve):
utctime As of version 1.2, vm-bhyve defaults to yes for this option. This causes bhyve to try and set the guests RTC clock to UTC rather than the host's time. I consider this more consistent, and should produce the correct time in the guest as long as the timezone is correctly set. Additionally, some guests actually expect a UTC realtime clock. If you require bhyve to use the host's time, as it would by default, explicitly set this to no.
So there is your solution if the time is not coming up right in your DragonFlyBSD vm. Likely some other guest OSes expect the local time as well. So this may help you fix clock offset issues with other virtual machines under Bhyve on FreeBSD.
Another Solution: Another option would be to tell the guest OS, in this case DragonFlyBSD, that the CMOS clock is set to local time, and not to UTC. This is done simply by creating the file /etc/wall_cmos_clock
root@dragonflybsd# touch /etc/wall_cmos_clock
From the DragonFlyBSD adjkerntz manpage:
... If the file /etc/wall_cmos_clock exists, it means that CMOS clock keeps local time (MS-DOS and MS-Windows compatible mode). If that file does not exist, it means that the CMOS clock keeps UTC time. The adjkerntz utility passes this state to the machdep.wall_cmos_clock kernel variable. ...
So there you have two options to fix the clock issues on your virtual machines.