Currently the semantics of filesystem freezing via the guest agent have corner cases that make it difficult to deal with for management applications especially with windows guests.

The main issue is that the internal 'frozen' state may not correspond to the actual state of the system if it is modified outside of guest agent's control.

This can happen manually, but according to Kubevirt developers on Windows the filesystems are thawed automatically after some timeout by windows itself. This is problematic because it's hard to control if required operations finished within the time when the filesystems were frozen. It also makes the guest-fsfreeze-status command useless because that only reports the internal state and not the state of the actual system.

As the guest agent is running in guest os context libvirt by default employs a timeout on replies from the guest agent. While the timeout can be controlled, it can happen that the command times out before reporting to the user/management app. It would be great if the guest agent could deliver events if the state of the filesystems changes. Libvirt could then forward the event to the management layer above. (This is a nice to have; polling the state should be fine)

https://gitlab.com/libvirt/libvirt/-/issues/706
https://issues.redhat.com/browse/RHEL-24046

TL;DR:
1) guest-fsfreeze-status should report the actual state of the filesystems, not just the internal states which can differ
2) having events for freeze and thaw would be great so that management can be notified of changes (nice to have)