How to improve VirtualBox guest time synchronisation after host sleeps/suspends

Introduction

If you find the guest system time greatly out of sync after resuming from suspend, it could be because the VirtualBox Guest Additions default parameters are too lenient. You can change them as described in My solution below.

The symptoms

When the following events occur:

• the VM is running,
• the host enters sleep,
• the host resumes from sleep after a few minutes/hours/days,

the guest’s system time will usually be behind the host’s system by however long the host was in the sleep state, and it often won’t get corrected for several minutes. This can cause confusion, e.g. log entries in the guest won’t be what the user expects.

Similar issues occur if you pause the guest for a while.

The root cause

VirtualBox Guest Additions default threshold for doing a “big jump” time correction (versus slowly slewing the clock) is, IMHO, too high: deltas of 20 minutes¹.

My solution

• adjust VirtualBox Guest Extensions parameter --timesync-set-threshold down from 20 minutes to 30 seconds:

  • in PowerShell, run:

    PS> & "C:\Program Files\Oracle\VirtualBox\VBoxManage.exe" guestproperty set your-vm-name "/VirtualBox/GuestAdd/VBoxService/--timesync-set-threshold" 30000
    

  • shutdown and start the VM

  • you should now find the VM’s clock is synced up within 10 seconds of the host resuming from sleep (see VirtualBox documentation on default value for parameter --timesync-interval)

• Optional: disable systemd-timesyncd in the guest – not because it’s broken or doing any harm, but we simply don’t need it:

  $ sudo systemctl disable --now systemd-timesyncd
  

My configuration

• Oracle VirtualBox 7.0.8 or 7.0.6
• Host: Windows 11
• Guest: Ubuntu Linux 22.04 with latest Guest Additions installed

Other versions could also be affected.

What about NTP / systemd-timesyncd ?

The guest’s systemd-timesyncd (systemd’s NTP client) has a more stringent threshold (0.4 seconds) for “big jump” time correction but it can take up to 30 minutes before it checks for a delta, which is too long for this situation[^2].

NTP on the guest isn’t the right tool to use in this situation. It’s better suited for correcting slow drift on a real system, not for a guest VM running on a host which is already (hopefully) correcting for drift.