From: "Michael Köppl" <m.koeppl@proxmox.com>
To: "Fiona Ebner" <f.ebner@proxmox.com>,
"Michael Köppl" <m.koeppl@proxmox.com>,
pve-devel@lists.proxmox.com
Subject: Re: [PATCH many v5 0/7] add option to prevent suggesting previously used VMIDs
Date: Wed, 23 Sep 2026 16:10:04 +0200 [thread overview]
Message-ID: <DLMR851TSIEJ.117RKMIPDHX5@proxmox.com> (raw)
In-Reply-To: <ce0a8af6-4fc3-4487-994d-36350fca0d0a@proxmox.com>
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.
next prev parent reply other threads:[~2026-09-23 14:10 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 15:54 [PATCH many v5 0/7] add option to prevent suggesting previously used VMIDs Michael Köppl
2026-09-21 15:54 ` [PATCH pve-cluster v5 1/7] cluster files: add used-guest-ids Michael Köppl
2026-09-22 14:22 ` Fiona Ebner
2026-09-21 15:54 ` [PATCH pve-cluster v5 2/7] datacenter config: add unique-next-id to schema Michael Köppl
2026-09-22 14:22 ` Fiona Ebner
2026-09-22 14:43 ` Michael Köppl
2026-09-23 7:48 ` Fiona Ebner
2026-09-23 8:01 ` Fiona Ebner
2026-09-23 8:18 ` Fiona Ebner
2026-09-21 15:54 ` [PATCH pve-guest-common v5 3/7] add module to track previously used guest IDs Michael Köppl
2026-09-22 14:22 ` Fiona Ebner
2026-09-22 15:55 ` Michael Köppl
2026-09-23 7:52 ` Fiona Ebner
2026-09-21 15:54 ` [PATCH qemu-server v5 4/7] api: record VM ID as used on creation, cloning, and destruction Michael Köppl
2026-09-22 14:33 ` Fiona Ebner
2026-09-21 15:54 ` [PATCH pve-container v5 5/7] api: record CT " Michael Köppl
2026-09-21 15:54 ` [PATCH pve-manager v5 6/7] close #4369: api: optionally only suggest unique IDs Michael Köppl
2026-09-22 14:33 ` Fiona Ebner
2026-09-21 15:54 ` [PATCH pve-manager v5 7/7] close #4369: ui: add datacenter option for unique VM/CT IDs Michael Köppl
2026-09-22 15:02 ` [PATCH many v5 0/7] add option to prevent suggesting previously used VMIDs Fiona Ebner
2026-09-23 8:13 ` Fiona Ebner
2026-09-23 14:10 ` Michael Köppl [this message]
2026-09-23 15:56 ` Fiona Ebner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DLMR851TSIEJ.117RKMIPDHX5@proxmox.com \
--to=m.koeppl@proxmox.com \
--cc=f.ebner@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox