From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 6D22D1FF137 for ; Tue, 17 Mar 2026 12:53:53 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 39932BFCB; Tue, 17 Mar 2026 12:54:05 +0100 (CET) Message-ID: Date: Tue, 17 Mar 2026 12:54:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [pve-devel] [PATCH qemu-server v5 8/9] deprecate freeze-fs-on-backup qga setting To: Thomas Lamprecht , Proxmox VE development discussion , Maximiliano Sandoval References: <20260105121702.20884-1-m.sandoval@proxmox.com> <20260105121702.20884-9-m.sandoval@proxmox.com> <9320e19a-94a9-452a-aedd-eea21a0572bf@proxmox.com> <753dcbdb-6170-4076-b8b6-a1fb3d8907b1@proxmox.com> <723da55e-ff27-4ea6-8163-53e525eb1de7@proxmox.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: <723da55e-ff27-4ea6-8163-53e525eb1de7@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1773748399123 X-SPAM-LEVEL: Spam detection results: 0 AWL -1.062 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 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.408 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.819 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.903 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: Y5ZHLPP727ZKSDY4R5QGQEX7M4ADK6E4 X-Message-ID-Hash: Y5ZHLPP727ZKSDY4R5QGQEX7M4ADK6E4 X-MailFrom: f.ebner@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 X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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.