all lists on lists.proxmox.com
 help / color / mirror / Atom feed
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 pve-guest-common v5 3/7] add module to track previously used guest IDs
Date: Tue, 22 Sep 2026 17:55:30 +0200	[thread overview]
Message-ID: <DLLYUBO8G3GZ.GZ9VKQGFQRQR@proxmox.com> (raw)
In-Reply-To: <0ee919d3-7ff6-4905-ae82-c348f8445037@proxmox.com>

On Tue Sep 22, 2026 at 4:22 PM CEST, Fiona Ebner wrote:

[snip]

>> diff --git a/src/PVE/UsedGuestIDs.pm b/src/PVE/UsedGuestIDs.pm
>> new file mode 100644
>> index 0000000..31036ff
>> --- /dev/null
>> +++ b/src/PVE/UsedGuestIDs.pm
>> @@ -0,0 +1,93 @@
>> +package PVE::UsedGuestIDs;
>
> Nit: maybe GuestID as a more general name? That would suggest moving or
> adding other stuff related to guest IDs here in the future. Otherwise,
> the module is quite specific. We would need to rename add_id() to
> add_used_id(), read_list() -> list_used_ids() for clarity then.

I think I'd also prefer PVE::GuestID here to avoid possibly having
another module later on or having to refactor this one. Will adapt for
v6!

>
>> +
>> +use strict;
>> +use warnings;
>
> Nit: I now this got picked up from before, but it would be nice to use
> v5.36; and function signatures for new modules.

will adapt for v6, thanks!

>
>> +
>> +use PVE::Cluster qw(
>> +    cfs_lock_file
>> +    cfs_read_file
>> +    cfs_register_file
>> +    cfs_write_file
>> +);
>> +
>> +my $FILENAME = 'used-guest-ids';
>> +
>> +my $parse_id_list = sub {
>
> Nit: If writing with a signature, use 'my sub', and similarly for the
> other two private functions.

will also be updated for v6, thanks!

>
>> +    my ($filename, $raw) = @_;
>> +
>> +    my $used_ids = {};
>> +
>> +    return $used_ids if !defined($raw);
>> +
>> +    for my $line (split(/\n/, $raw)) {
>> +        next if $line =~ m/^\s*$/;
>> +
>> +        if ($line =~ m/^(\d+)$/) {
>> +            $used_ids->{$1} = 1;
>> +        } elsif ($line =~ m/^(\d+)-(\d+)$/) {
>> +            my ($start, $end) = ($1, $2);
>> +            if ($start > $end) {
>> +                warn "skipping reversed range in $filename: $line\n";
>> +                next;
>> +            }
>> +            $used_ids->{$_} = 1 for $start .. $end;
>
> Nit: we could be smarter and avoid adding every single ID to the hash
> (with a lot of (past) guests that can become a non-trivial cost), and
> instead track ranges. Instead of having a public read_list() function
> then, there could be a check_id_unused() function. When writing out the
> file we can still merge adjacent ranges.

Thanks for pointing this out! I think the range approach is a good idea!
Should we have a public function that returns the end of a range for a
given guest ID instead of the boolean check_id_unused()? We could then
use it to skip ranges when searching for a free guest ID at
/cluster/nextid instead of invoking cfs_read_file() for each check if a
candidate ID is available. Something like this:

my $i = $lower;
while ($i < $upper) {
    if (defined($idlist->{$i})) { $i++; next; }
    if ($check_unique) {
        if (defined(my $end =
		  PVE::UsedGuestIDs::get_used_range_end($i))) {
            $i = $end + 1;
            next;
        }
    }
    return $i;
}

>
>> +        } else {
>> +            warn "skipping invalid entry in $filename: $line\n";
>> +        }
>> +    }
>> +
>> +    return $used_ids;
>> +};
>> +
>> +my $format_entry = sub {
>> +    my ($start, $last) = @_;
>> +    return $start == $last ? "$start\n" : "$start-$last\n";
>> +};

[snip]




  reply	other threads:[~2026-09-22 15:55 UTC|newest]

Thread overview: 18+ 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-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 [this message]
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

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=DLLYUBO8G3GZ.GZ9VKQGFQRQR@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal