From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id 4A5AB1FF0AB for ; Wed, 23 Sep 2026 16:10:12 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 802B12161E; Wed, 23 Sep 2026 16:10:08 +0200 (CEST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 23 Sep 2026 16:10:04 +0200 Message-Id: Subject: Re: [PATCH many v5 0/7] add option to prevent suggesting previously used VMIDs From: =?utf-8?q?Michael_K=C3=B6ppl?= To: "Fiona Ebner" , =?utf-8?q?Michael_K=C3=B6ppl?= , X-Mailer: aerc 0.22.0 References: <20260921155410.938337-1-m.koeppl@proxmox.com> In-Reply-To: X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1790172604209 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.501 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust 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: AWVN3UYLGKWTFNIHR27HE63AMKV723RG X-Message-ID-Hash: AWVN3UYLGKWTFNIHR27HE63AMKV723RG X-MailFrom: m.koeppl@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: On Tue Sep 22, 2026 at 5:02 PM CEST, Fiona Ebner wrote: [snip] > 2. Recording every second ID can lead to a file larger than the 1 MiB > pmxcfs limit and then every operation will fail regardless of whether > the feature is turned on or not. > > 3. Remote migration uses destroy_{lxc_container,vm} directly if the > 'delete' parameter is set. > > For the second point, an example is: > [I] root@pve9a1 ~# expr $(seq 100 2 1000000 | wc --bytes) / 1024 / 1024 > 3 > This is unlikely to happen with regular operation of course, because we > always suggest the lowest free one, but it can't be ruled out. Not > entirely sure what to do about it, but it would be good if we can avoid > the issue. Maybe start dropping gaps and merging anyways if we get close > to the limit? At the very least, we might consider making the failure > non-critical if the feature is turned off. Pondered a bit on this and my suggested approach would be to have 2 thresholds at 512KiB and 768KiB, where write_id_list would warn for the "soft" threshold and start closing gaps at the "hard" threshold? That would give users fair warning to follow the suggested unique guest IDs and would potentially resolve the problem over time if ranges are merged as a result of it. What do you think? I'd make it non-critical if 'unique' is turned off in any case. > > While looking through the last point, I also noticed that 'qm importovf' > is still a place where we create a new config, so should be recording > the new ID. Maybe we even want to use make sure all places use the > create_and_lock_config() method and do it at the beginning of that? That > might be the cleanest and most future-proof.