After PVE 8to9 upgrade, unable to check guest fs freeze status

[OhmEye]

Hello, I upgraded my 5-node PVE cluster from 8 to 9.2.2 and PBS to 4.2.0. I have a TrueNas Core VM (FreeBSD based) that I made no changes to during the upgrade other than shutting it down for the upgrade, it started normally on the upgraded PVE. The qemu-guest-agent is running and enabled in the VM options, no changes are obvious to me other than upgrading from PVE 8 to 9.

However, my scheduled PBS backup logs warnings for fsFreeze that never occurred under PVE 8. I've seen conflicting information about fsFreeze support for FreeBSD but have been backing up this VM for years without this warning/error and the limited restore testing I did back when setting it up was successful. So now I'm wondering why fsFreeze isn't working after the upgrade to PVE 9 and no changes were made on the guest, any help appreciated!

PVE 8 before the upgrade:

INFO: Starting Backup of VM 101 (qemu)
INFO: Backup started at 2026-05-23 06:00:02
INFO: status = running
INFO: VM Name: serenity
INFO: include disk 'scsi0' 'local-lvm:vm-101-disk-0' 32G
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: snapshots found (not included into backup)
INFO: creating Proxmox Backup Server archive 'vm/101/2026-05-23T10:00:02Z'
INFO: issuing guest-agent 'fs-freeze' command
INFO: issuing guest-agent 'fs-thaw' command
INFO: started backup task 'f4f57d46-21eb-4318-95ce-0d3f561ef5a9'
INFO: resuming VM again
INFO: scsi0: dirty-bitmap status: OK (116.0 MiB of 32.0 GiB dirty)
INFO: using fast incremental mode (dirty-bitmap), 116.0 MiB dirty of 32.0 GiB total
INFO: 100% (116.0 MiB of 116.0 MiB) in 3s, read: 38.7 MiB/s, write: 38.7 MiB/s
INFO: Waiting for server to finish backup validation...
INFO: backup was done incrementally, reused 31.89 GiB (99%)
INFO: transferred 116.00 MiB in 4 seconds (29.0 MiB/s)
INFO: adding notes to backup
INFO: prune older backups with retention: keep-last=3, keep-monthly=1, keep-weekly=1
INFO: running 'proxmox-backup-client prune' for 'vm/101'
INFO: pruned 1 backup(s) not covered by keep-retention policy
INFO: Finished Backup of VM 101 (00:00:04)
INFO: Backup finished at 2026-05-23 06:00:06

PVE 9 after the upgrade:

INFO: Starting Backup of VM 101 (qemu)
INFO: Backup started at 2026-05-24 06:00:02
INFO: status = running
INFO: VM Name: serenity
INFO: include disk 'scsi0' 'local-lvm:vm-101-disk-0' 32G
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: snapshots found (not included into backup)
INFO: creating Proxmox Backup Server archive 'vm/101/2026-05-24T10:00:02Z'
WARN: unable to check guest fs freeze status - Agent error: The command guest-fsfreeze-status has been disabled for this instance
INFO: issuing guest-agent 'fs-freeze' command
ERROR: unable to freeze guest fs - The command guest-fsfreeze-freeze has been disabled for this instance
INFO: starting backup via QMP command
INFO: issuing guest-agent 'fs-thaw' command
ERROR: Agent error: The command guest-fsfreeze-thaw has been disabled for this instance
INFO: started backup task '7e6b3e99-f4eb-40cb-8b6f-57628344b262'
INFO: resuming VM again
INFO: scsi0: dirty-bitmap status: OK (68.0 MiB of 32.0 GiB dirty)
INFO: using fast incremental mode (dirty-bitmap), 68.0 MiB dirty of 32.0 GiB total
INFO: 100% (68.0 MiB of 68.0 MiB) in 1s, read: 68.0 MiB/s, write: 68.0 MiB/s
INFO: backup was done incrementally, reused 31.93 GiB (99%)
INFO: transferred 68.00 MiB in 1 seconds (68.0 MiB/s)
INFO: adding notes to backup
INFO: prune older backups with retention: keep-last=3, keep-monthly=1, keep-weekly=1
INFO: running 'proxmox-backup-client prune' for 'vm/101'
INFO: pruned 1 backup(s) not covered by keep-retention policy
INFO: Finished Backup of VM 101 (00:00:01)
INFO: Backup finished at 2026-05-24 06:00:03

 

[fiona]

Hi,
what version of the guest agent are you running in the VM? What does qemu-ga -D inside the VM say?

 

[OhmEye]

Thanks for the reply! I admit I hadn't investigated the agent due to it working with no errors for years...

root@redacted[~]# qemu-ga -V
QEMU Guest Agent 5.0.1
root@redacted[~]# qemu-ga -D
[general]
daemon=false
method=isa-serial
path=/dev/vtcon/org.qemu.guest_agent.0
pidfile=/var/run/qemu-ga.pid
statedir=/var/run
verbose=false
retry-path=false
blacklist=

 

[OhmEye]

Thanks for the reply! I admit I hadn't investigated the agent due to it working with no errors for years...

root@redacted[~]# qemu-ga -V
QEMU Guest Agent 5.0.1
root@redacted[~]# qemu-ga -D
[general]
daemon=false
method=isa-serial
path=/dev/vtcon/org.qemu.guest_agent.0
pidfile=/var/run/qemu-ga.pid
statedir=/var/run
verbose=false
retry-path=false
blacklist=

 

[fiona]

Doesn't seem to be blocked in the config, but 5.0.1 is a rather old version. Does it work if you manually run
qm guest cmd 101 fsfreeze-status?

 

[OhmEye]

Looks like it's consistent with the error when run manually:

root@redacted:~# qm guest cmd 101 fsfreeze-status
{
   "error" : {
      "class" : "CommandNotFound",
      "desc" : "The command guest-fsfreeze-status has been disabled for this instance"
   }
}

Nothing has changed on the guest since upgrading PVE from 8 to 9, so it seems something has changed with this command in 9

 

[fiona]

The status command was not used previously, but that doesn't explain why your guest agent claims the commands are disabled.

You can check the commandline the qemu-ga process was invoked with with ps aux | grep qemu-ga. What does cat /etc/qemu/qemu-ga.conf say? Did you already restart the guest agent in the VM?

 

[Sunilkumar]

Thanks Fiona. I restarted the guest agent and checked both the runtime arguments and config file. There do not appear to be any blacklist parameters being passed to qemu-ga, and <span>/etc/qemu/qemu-ga.conf</span> is still essentially default with an empty <span>blacklist=</span> entry.

I also verified with:

<span>ps aux | grep qemu-ga</span>
and nothing unusual stands out in the launch parameters.

What seems interesting is that the behavior changed only after upgrading from PVE 8 to 9 while the FreeBSD/TrueNAS guest itself remained untouched, which makes me wonder if newer QEMU/PVE versions are now performing stricter capability checks against older guest-agent implementations.

Given that qemu-ga 5.0.1 is fairly old, I’m leaning toward a compatibility issue between the newer host-side QEMU stack and the older FreeBSD guest agent rather than an actual backup problem. Snapshot backups still complete successfully, but freeze/thaw functionality now appears explicitly blocked instead of silently ignored as before.

I’ll test updating the guest agent package on the TrueNAS side next and report back with results in case it helps others running FreeBSD-based guests on PVE 9.