Re: [PATCH guest-common/manager/qemu-server v3 0/3] fix #5032: add guest time sync via QGA

[Maximiliano Sandoval <m.sandoval@proxmox.com>]

Jakob Klocker <j.klocker@proxmox.com> writes:

> This series adds a new agent option 'sync-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 
> disabled by default and only takes effect when the QEMU Guest Agent is
> enabled.
>
> When a VM resumes with a restored RAM state (waking from hibernation or
> rolling back to a snapshot that includes RAM), the guest clock 
> continues from the point the state was saved and no longer matches 
> wall-clock time. Skews also appears whenever the guest is briefly 
> frozen and resumed - after creating a snapshot, an
> ordinary pause/resume, or the resume step of a live migration. 
>
> When enabled, the option triggers a guest-set-time call:
>  * after resuming from hibernation (suspend-to-disk)
>  * after rolling back to a snapshot that includes RAM
>  * after a live migration
>  * after an ordinary pause/resume
>  * after taking a snapshot
>
> The start, resume and rollback API endpoints also accept a
> 'sync-time-on-resume' parameter that overrides the configured value for
> a single operation. 
>
> The persistent config option is exposed in the QEMU Guest Agent
> configuration GUI, so it can be toggled per guest.
>
> Link: https://bugzilla.proxmox.com/show_bug.cgi?id=5032
>
> changes from v1 to v2 (thanks @Arthur)
> - qemu: adapt warning message in the resume-from-saved-state path
> - ui: reword the agent option label for clarity
>
> changes from v2 to v3 (thanks @Fiona)
> - add sync on pause/resume
> - add override options
> - add print task 
> - adapt formating and naming

Tested:

- Create a new VM (100) without installing/enabling the QGA yet
- Ran: qm set 100 --agent enabled=1,sync-time-on-resume=1
- Took a snapshot with ram: The following line appears in the task logs:

could not sync guest time after snapshot - VM 100 qga command 'guest-set-time' failed - got timeout

- Rollback to the new snapshot, The following line appears in the task journal:

  could not sync guest time after resume from saved state - VM 100 qga command 'guest-set-time' failed - got timeout

- Enabled the guest agent inside the guest
- Did a new snapshot with RAM, the following line appears in the task log:

synced guest clock via guest agent

- Performed a rollback to the latest snapshot. The same line appears in the task log

If one additionally adds the following qemu-guest-agent config:

```
# cat /etc/qemu/qemu-ga.conf
[general]
verbose = 1
```
One can see the following when taking the snapshot:

```
Jul 02 16:56:57 pve qemu-ga[1660]: 1783004217.298332: debug: read data, count: 132, data: {"execute":"guest-sync-delimited","arguments":{"id":2108601}}
Jul 02 16:56:57 pve qemu-ga[1660]: {"arguments":{"time":1783004217540955904},"execute":"guest-set-time"}
Jul 02 16:56:57 pve qemu-ga[1660]: 1783004217.298563: debug: process_event: called
Jul 02 16:56:57 pve qemu-ga[1660]: 1783004217.298572: debug: processing command
Jul 02 16:56:57 pve qemu-ga[1660]: 1783004217.298595: debug: sending data, count: 21
Jul 02 16:56:57 pve qemu-ga[1660]: 1783004217.298644: debug: process_event: called
Jul 02 16:56:57 pve qemu-ga[1660]: 1783004217.298649: debug: processing command
Jul 02 16:56:57 pve qemu-ga[1660]: 1783004217.541002: debug: g_unix_open_pipe() called with FD_CLOEXEC; please migrate to using O_CLOEXEC instead
Jul 02 16:56:58 pve qemu-ga[1660]: 1783004218.501531: debug: sending data, count: 15
```

I cannot not check whether the date was actually set (since the snapshot
didn't take more than a second), but the passed value matches.

```
$ date -d @1783004217  # 1_783_004_217_540_955_904 from above "divided" by 10^9
Thu Jul  2 04:56:57 PM CEST 2026
```

@jakob: One thing that would be nice to improve is the error message
when the guest agent is not enabled inside the guest. Perhaps it is
possible to print a message saying that we skipped the guest-set-time
command because the guest agent was not running, similarly to what we do
for the guest-fsfreeze-freeze calls. However, it might be undesirable to
add yet another guest agent call just to check if it is there though.

Tested-by: Maximiliano Sandoval <m.sandoval@proxmox.com>

-- 
Maximiliano