From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id A6A3C1FF137 for ; Tue, 17 Mar 2026 12:33:08 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 6F7A3B57A; Tue, 17 Mar 2026 12:33:19 +0100 (CET) Message-ID: <723da55e-ff27-4ea6-8163-53e525eb1de7@proxmox.com> Date: Tue, 17 Mar 2026 12:32:36 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Subject: Re: [pve-devel] [PATCH qemu-server v5 8/9] deprecate freeze-fs-on-backup qga setting To: Fiona Ebner , 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> Content-Language: en-US From: Thomas Lamprecht In-Reply-To: <753dcbdb-6170-4076-b8b6-a1fb3d8907b1@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: 1773747115288 X-SPAM-LEVEL: Spam detection results: 0 AWL -1.077 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: F35L5CCBKHXILGTEMPCHA22OLKNI3X3R X-Message-ID-Hash: F35L5CCBKHXILGTEMPCHA22OLKNI3X3R X-MailFrom: t.lamprecht@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 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. 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... >> 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.