[Feature] Handle VM clock desynchronisation if host sleeps

[Ignat]

For the time being, the only way to handle this scenario is to run alpine restart. This introduces really annoying overheads when using macpine VMs for development work that relies on constant apt/apk updates.

I'm trying to think of some "low-key" ways of synchronising clocks without forcing the user to install a daemon on their host..

[Max Zinkus]

hmm, we could get the host system time and machineConfig.Exec(<set the instance system and hardware clock>)? That still requires an SSH round trip but should be quick if the instance is running.

If the user wants continuously synchronized time, an ntp daemon in the guest is a very standard approach. A cron task could also solve it maybe? Or we run a daemon on the host which syncs time in the instances periodically, but that seems even more heavy-weight.

[Ignat]

I will give an ntp daemon a go.

The main issue for me is running any kind of devops environment after my Mac was asleep. I get certificate error, which is only solved if a macpine instance is restarted, syncronising the clocks.

I did consider setting guest time to host via Exec, but I'm not sure it would solve the sleeping problem...

[Max Zinkus]

That totally makes sense and sounds like it would be tedious & frustrating. I have had some better luck with chronyd when I reduced the frequency of synchronizations up from the default.

[Ignat]

I've added some docs on including openntpd inside an instance. But can be pretty straightforward with:

apk update; apk add openntpd
rc-update add openntpd default
rc-service openntpd start

I wonder if it's worth including this at launch or should we leave it up to the user?

[Max Zinkus]

If you do setup-alpine, it walks you through installing your choice of ntp daemon including chrony and others, so maybe left to user?

A fresh alpine install also prompts you to run setup-alpine to complete the install

[Max Zinkus]

While it'd be nice to have a clean, efficient solution to this, I think that ntp can do the job that it's meant to do at least mostly well enough. The only other thing I can think of would be configuring a runlevel hook that forces an ntp sync (if ntp is set up) upon wake/unpause/start, but a user could add this relatively easily if they wanted.