Technical Anshu
Tutorials Blog
🕐 VM Time Sync

Ubuntu Virtual Machine Time Wrong After Snapshot Restore or Resume

You restore a snapshot from two weeks ago and the VM wakes up believing it is two weeks ago - because, from its clock's point of view, it is. A virtual machine's clock is a file and a host setting, not a crystal. Here is how to make it tell the truth again, and stay true.

✍️ Technical Anshu🐧 Ubuntu⏱️ 6 minute read
🎥 Watch the full video - every Ubuntu time fix shown live, step by step

A physical PC's clock ticks in hardware even while the machine is off. A virtual machine has no hardware - its clock is whatever the host tells it at boot, plus whatever its sync tools correct afterwards. Pause the VM, restore a snapshot, or let the host sleep, and the guest's sense of 'now' rewinds or stalls with it. The fix is not a settings hunt; it is understanding that a VM clock has two possible masters - the host, and NTP - and making them agree on who is in charge.

Terminal - a VM just restored from a two-week-old snapshot
$ timedatectl Local time: Fri 2026-10-09 18:02:41 IST Universal time: Fri 2026-10-09 12:32:41 UTC RTC time: Fri 2026-10-09 12:32:41 Time zone: Asia/Kolkata (IST, +0530) System clock synchronized: no NTP service: active RTC in local TZ: no
The guest woke up with the snapshot's date and time, and sync has not yet corrected it. Example values showing the classic rewind - the date is plausible, just old.
1

Why Virtual Clocks Rewind and Stall

  1. Snapshot restore - the guest clock is part of the saved state, so the VM resumes at the moment the snapshot was taken
  2. Pause and resume - a suspended VM does not tick; on resume it can be minutes or days behind in one step
  3. Host sleep - if the host machine slept, its guests inherit the confusion until something corrects them
  4. Boot time - at power-on the guest reads its starting time from the host, so a host with a wrong clock hands the error down before NTP can object

None of this is an Ubuntu bug. It is what "virtual hardware clock" honestly means.

2

Install the Guest Tools - the Host's Channel Into the VM

Every hypervisor offers guest tools that include a time channel from host to guest. Install the set that matches your host:

  1. VMware: sudo apt install open-vm-tools (add open-vm-tools-desktop on graphical VMs)
  2. KVM and Proxmox: sudo apt install qemu-guest-agent - and note the host still seeds the clock at boot; NTP does the ongoing work
  3. VirtualBox: install the Guest Additions from the Devices menu while the VM runs
  4. Hyper-V: the time synchronization integration service is built into the Linux kernel support - it is enabled or disabled on the host, in the VM's Integration Services settings

Without guest tools, the host has no way to nudge a running guest's clock at all.

3

Check Whether Host Sync Is On - VMware Example

  1. Inside a VMware guest with tools installed, ask: vmware-toolbox-cmd timesync status
  2. If it reports disabled and you want the host to keep this guest honest, enable it: sudo vmware-toolbox-cmd timesync enable
  3. Host sync shines right after resume and restore - it corrects the guest immediately instead of waiting for the next NTP poll
  4. On other hypervisors the same switch lives in the VM's settings on the host, not inside Ubuntu

If your guest corrects itself within seconds of a restore, host sync is already doing this job.

4

The One-Master Rule - Host Sync or NTP, Not a Fight

Here is the fault behind most "VM time keeps jumping back and forth" reports:

  1. Host sync pulls the guest to the host's time sense; NTP pulls it to the internet's
  2. If the host itself is wrong or drifting, the two masters disagree - and the guest clock visibly steps forward and back as each takes its turn
  3. Choose deliberately: NTP as master for servers and any VM whose timestamps matter (logs, builds, certificates)
  4. Host sync as master is fine for throwaway desktop VMs - then consider turning guest NTP off with timedatectl set-ntp false so nothing argues
  5. What you must not do is leave both fighting and go hunting for a bug that is actually an argument

One clock, one master. Say it before every VM time fix.

5

The Restore Routine - Force One Clean Correction

Just restored a snapshot or resumed an old VM? Run this short routine instead of waiting:

  1. Check the damage: timedatectl - note how far off the date and time are
  2. Restart the sync client: sudo systemctl restart systemd-timesyncd
  3. On chrony-managed VMs, demand a step correction: sudo chronyc makestep, then read chronyc tracking
  4. Wait a few seconds and re-check timedatectl - synchronized should say yes with today's date
  5. Only then open the apps that care - browsers will complain about certificates and logins while the date is wrong, and those errors vanish once the clock is true

Make this a habit and snapshot restores stop producing phantom "internet is broken" reports.

🕐 Host first, honestly: if every VM on one host has time trouble, the host's own clock is the prime suspect. Fix the host's time, and half the guest problems were never the guests' fault.

Watch the Complete Video Guide

The video shows the restore-and-rewind problem live, plus the guest-tools checks that bring a VM's clock back to today.

Watch Full Video
❓ Common Questions (FAQ)

Why does my VM show the snapshot date after a restore?

The guest clock is part of the state a snapshot saves. Restoring the snapshot restores that moment's time as well. Guest tools with host sync, or NTP catching up after boot, correct it - if neither is active, the VM keeps living in the snapshot's day.

Host sync or NTP - which should a VM use?

NTP for anything whose logs, certificates or schedules matter, because it answers to real time rather than to the host's health. Host sync is fine for casual desktop VMs. The mistake is running both when the host clock is unreliable - they fight, and the guest clock steps back and forth.

My VM loses a few minutes every day even while running. Why?

A busy virtual CPU gets scheduled in bursts, and the guest clock can drift under load, especially on an overloaded host. NTP or chrony inside the guest corrects this continuously - chrony is the better fit for VMs because it handles irregular ticking and big corrections well.

This guide is based on the Technical Anshu Ubuntu time fix video - stuck on any step, ask in the video comments and you will get an answer.