Debian guest clock jumps forward after KVM snapshot restore, causing missed cron jobs and certificate timing errors

Environment

Debian 11 guest running on KVM/QEMU host (libvirt). Guest restored from a saved snapshot while host was migrated between physical nodes. Services include nginx, systemd-timedated, and several scheduled cron jobs for backups.

Symptoms

After resuming from the snapshot, the guest clock is several hours ahead; systemd services that validate certificates fail with 'certificate not yet valid' and several cron jobs did not run at their scheduled times (timestamps in syslog show time jump).

Observations

journalctl shows lines: 'System clock time changed by X seconds' and repeated systemd-timesyncd NTP corrections. 'timedatectl' reports NTPSynchronized=no immediately after resume, and 'hwclock --show' reports older hardware clock time. There are no obvious kernel panics; host logs show the VM was paused for ~1 hour during migration.

Already attempted

Manually ran 'sudo timedatectl set-ntp true', forced a sync with 'sudo ntpd -q' and 'sudo hwclock --hctosys' (repro vs. host), restarted affected services; a full VM reboot restored normal time sync but was not always possible in production windows.

Question

What is the safest way to prevent large time jumps in guests restored from snapshots or paused during host operations, and how to recover without full reboot when a time step breaks certificate- or scheduler-dependent processes?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 1w ago• Trouble ID

Most likely causes

Host paused/suspended the VM for extended time; on resume the guest clock was advanced or not reconciled with real time. 95%

Guest uses hardware clock that was not updated when the snapshot was taken, leading to inconsistent rtc/hwclock values at resume. 80%

Misconfigured NTP/systemd-timesyncd that delays or refuses a step correction until network is fully up. 75%

Summary

Large guest clock jumps typically occur when a VM is suspended or snapshotted and the guest clock (hwclock or kernel timebase) diverges from real time on resume. systemd-timesyncd may step time or refuse immediate synchronization if NTP is not yet reachable. Some services (or TLS libraries) are sensitive to non-monotonic jumps.

Suggested Fixes

Diagnostic step 1

Short-term recovery without full reboot: allow systemd-timesyncd/chrony to step time by making NTP reachable. If service-blocking problems persist, temporarily stop time-sensitive services, run 'sudo timedatectl set-ntp false' then 'sudo ntpdate -u <ntp-server>' (or 'chronyc -a makestep' if using chrony) to force a step, then restart services. These commands are reversible.

Diagnostic step 2

Prefer chrony on virtualized guests: install and enable chrony which handles large time steps and suspend/resume better than systemd-timesyncd in many environments.

Diagnostic step 3

Enable paravirtualized clock synchronization: install/enable the guest agent or hypervisor-specific tools (qemu-guest-agent) so the host can notify guests on resume to resync the clock.