From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id C58E61FF13F for ; Thu, 18 Jun 2026 14:36:32 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 9A23317D28; Thu, 18 Jun 2026 14:36:32 +0200 (CEST) Date: Thu, 18 Jun 2026 14:35:57 +0200 From: Arthur Bied-Charreton To: Jakob Klocker Subject: Re: [PATCH manager/qemu-server 0/2] fix #5032: sync guest time after restore from saved state Message-ID: References: <20260612122942.181958-1-j.klocker@proxmox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260612122942.181958-1-j.klocker@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1781786099435 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.761 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [proxmox.com,qemuconfig.pm,qemuserver.pm,agent.pm] Message-ID-Hash: 5IYSIKQGODOH4THOEFLIEHYHDSEKL6PU X-Message-ID-Hash: 5IYSIKQGODOH4THOEFLIEHYHDSEKL6PU X-MailFrom: a.bied-charreton@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: pve-devel@lists.proxmox.com X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Fri, Jun 12, 2026 at 02:29:40PM +0200, Jakob Klocker wrote: > This series adds a new agent option set-time-on-resume to > automatically synchronize the guest clock via the QEMU Guest Agent > after operations that can leave the guest time stale. The option is > enabled by default when the QEMU Guest Agent is configured. > > When a VM is restored from a saved state (hibernation or snapshot with > RAM), the guest clock continues from the point the state was saved and > no longer matches wall-clock time. The same skew can appear after > creating a snapshot of a running VM. For guests whose OS does not > correct this on its own, the drift persists until the next NTP sync (if > any), which can cause problems for time-sensitive workloads. > > This series introduces the set-time-on-resume agent option and triggers > a guest-set-time call: > * after restoring a VM from a saved state or snapshot with RAM > * after taking a snapshot > > The option is exposed in the VM configuration GUI so it can be toggled > per guest. > > This series depends on [0] being applied first. > > [0] https://lore.proxmox.com/pve-devel/20260612100758.116697-1-j.klocker@proxmox.com/T/#u > > Link: https://bugzilla.proxmox.com/show_bug.cgi?id=5032 > > > qemu-server: > > Jakob Klocker (1): > fix #5032: qemu: sync guest time on resume and snapshot of saved state > > src/PVE/QemuConfig.pm | 7 ++++++ > src/PVE/QemuServer.pm | 10 ++++++++ > src/PVE/QemuServer/Agent.pm | 47 +++++++++++++++++++++++++++++++++++++ > 3 files changed, 64 insertions(+) > > > pve-manager: > > Jakob Klocker (1): > fix #5032: ui: qemu agent: add set-time-on-resume option > > www/manager6/Utils.js | 2 ++ > www/manager6/form/AgentFeatureSelector.js | 18 ++++++++++++++++++ > 2 files changed, 20 insertions(+) > > > Summary over all repositories: > 5 files changed, 84 insertions(+), 0 deletions(-) > > -- > Generated by murpp 0.12.0 > I tested the two paths calling guest-set-time. Skew after restore: I set up a guest with kvm-clock & NTP enabled. I took a snapshot of it with RAM, waited a minute and rolled the VM back to the snapshot. Before applying this series, I observed a transient clock skew on the VM which was corrected shortly after. After applying, there was no observable clock skew. Skew after snapshot: This was a bit trickier to test. I edited /sys/devices/system/clocksource/clocksource0/current_clocksource from kvm-clock to tsc, however I was not able to observe any skew in the guest after taking snapshots. I then added a sleep to pve-qemu to force longer freezes during snapshots, still could not reproduce the skew. I ended up just disabling NTP (`timedatectl set-ntp false`) in the guest and setting a wrong date with `date -s`. I then saw that, before the patch, the time stayed wrong in the guest after a snapshot, whereas after the patch, it was corrected by the guest-set-time command. Not very familiar with that part of the code, but FWIW the code looks good to me as well. Left two minor comments on the patches (not blockers) Consider this series: Reviewed-by: Arthur Bied-Charreton Tested-by: Arthur Bied-Charreton