Technical

Marking clocksource ‘tsc’ as unstable because the skew is too large: fix Proxmox snapshot stutter

Marking clocksource ‘tsc’ as unstable because the skew is too large: fix Proxmox snapshot stutter

Marking clocksource ‘tsc’ as unstable because the skew is too large — that’s the kernel telling you the VM’s timekeeping went sideways, and snapshots are a classic trigger. You pause the VM, snapshot it, resume, and suddenly the console is full of that error and time jumps around. Annoying, but fixable.

Woman using a laptop in a server room, showcasing modern technology and work environment.

Why snapshots break TSC

TSC is a per-CPU counter that’s supposed to tick at a constant rate. When you snapshot a VM, you freeze its state, including the TSC values. On resume, the host’s TSC has kept moving, so the guest sees a huge jump — the skew. The kernel then marks TSC unstable and falls back to a slower clocksource like hpet or acpi_pm, which can cause stutter and time drift.

The quick fix: use a paravirtual clock

Modern Linux guests handle this better with a paravirtualized clocksource. On the Proxmox host, set the VM’s CPU type to host and enable kvm-clock. In the VM’s config file (/etc/pve/qemu-server/<vmid>.conf), make sure you have:

cpu: host,flags=+kvm_pv_unhalt
args: -cpu host,+kvm_pv_unhalt

Actually, kvm-clock is usually enabled by default for Linux guests, but forcing it doesn’t hurt. Inside the guest, check what clocksource is in use:

cat /sys/devices/system/clocksource/clocksource0/current_clocksource

If it says tsc and you still get the error, you can force kvm-clock by adding clocksource=kvm-clock to the guest’s kernel command line. Edit /etc/default/grub and add it to GRUB_CMDLINE_LINUX, then run update-grub and reboot the VM.

Networking equipment with connected cables, showcasing modern technology infrastructure.

Alternative: keep TSC but make it stable

Some workloads need TSC for performance, like low-latency stuff. You can try to keep TSC stable across snapshots by pinning the VM’s vCPUs to physical cores and disabling frequency scaling on the host. That reduces TSC drift, but it won’t eliminate the snapshot pause jump. I’d only go this route if you have a specific reason to avoid kvm-clock.

Check your snapshot method

If you’re using snapshot mode with memory (RAM), the TSC jump is worse because the entire CPU state is frozen. Using snapshot without memory, or a backup instead, avoids the issue for running VMs. For a homelab, I’d just use vzdump backups instead of snapshots for running VMs — less hassle.

Related: if you’re messing with VM configs, you might hit Changing VMID of a VM in Proxmox or other weirdness. And if your console is being a pain, check Proxmox noVNC escape key.

If you’d rather pay for this

Not really a paid product that fixes this — it’s a kernel quirk. You could run VMs on VMware or Hyper-V, which handle TSC differently, but that’s overkill for a homelab. Just switch to kvm-clock and move on.

Leave a comment

Comments are reviewed before they appear. Your email is never published.