Re: [pve-devel] [PATCH qemu-server v5 8/9] deprecate freeze-fs-on-backup qga setting

[Fiona Ebner <f.ebner@proxmox.com>]

Am 17.03.26 um 12:31 PM schrieb Thomas Lamprecht:
> Am 17.03.26 um 10:40 schrieb Fiona Ebner:
>>> why not just make this an alias for the new (superset) property?
>> If we think most people set the property because the VM had issues with
>> freezing, which are not actually limited to the backup case, then having
>> it be an alias can be sensible. I do think this is the case, but it
>> might still be surprising to some people. We could also wait until PVE
>> 10 to have it become an alias or...
> 
> I mean the option is also made for that assumption, isn't it? Because
> otherwise we would need to make it a "flag list" (sorta like the
> features for LXC config) to actually provide full control on when  to
> freeze and when not.

Yes, it is made for that assumption.

> As a boolean flag with just the name changed it IMO intended to be a
> superset of the backup one, as introducing then a specific flag for clone,
> snapshot, replication, ...? would be much better solved by a flag list,
> that then would also avoid users wondering for when this is actually done,
> as that can be seen by the selected options. But not a must to do now,
> mostly also because that needs some dedicated handling as the qemu-server
> was already released...

The only operation where skipping freeze might make sense for
performance reasons (and not for the reason that the guest has issues
with it) is replication, which was also requested in Bugzilla. For that,
a flag for the replication job seems more fitting to me.

>>> And you certainly *cannot* remove this in PVE 10, doing so will break
>>> restoring previous backups!
>> ...just translate the option to the more general one in
>> restore_update_config_line() and/or parse_config(), then we could drop
>> it from the schema.
> 
> That needs to be remembered though, with the current comment and how
> this was applied I rather doubt that doing so was on the radar... And,
> while that can be done, it's not like it's without implication, as
> backup and restoring that again on an older PVE would make it fail
> even if one did not change the VM at all. Not something we (can) provide
> hard guarantees for, but certainly not something I want to actively break,
> especially without good reason.

I'm sorry and I agree that removing the old option in PVE 10 might not
be the best approach.