From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 50E299AC42 for ; Mon, 22 May 2023 17:00:24 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 13F2032E6B for ; Mon, 22 May 2023 17:00:24 +0200 (CEST) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Mon, 22 May 2023 17:00:23 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 437A6402E9 for ; Mon, 22 May 2023 17:00:22 +0200 (CEST) Message-ID: <8e72aa37-9d4b-3e1e-f8bc-3a9a6d14cbce@proxmox.com> Date: Mon, 22 May 2023 17:00:21 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Content-Language: en-US To: Proxmox VE development discussion , Aaron Lauterer References: <20230512124043.888785-1-a.lauterer@proxmox.com> <20230512124043.888785-6-a.lauterer@proxmox.com> From: Fiona Ebner In-Reply-To: <20230512124043.888785-6-a.lauterer@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.004 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 NICE_REPLY_A -0.091 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pve-devel] [PATCH container v2 5/6] migration: only migrate volumes used by the guest X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2023 15:00:24 -0000 Am 12.05.23 um 14:40 schrieb Aaron Lauterer: > When scanning all configured storages for volumes belonging to the > container, the migration could easily fail if a storage is not > available, but enabled. That storage might not even be used by the > container at all. > > By not doing that and only looking at the disk images referenced in the > config, we can avoid that. > We need to add additional steps for pending volumes with checks if they > actually exist. Changing an existing mountpoint to a new volume > will only create the volume on the next start of the container. > > The big change regarding behavior is that volumes not referenced in the > container config will be ignored. They are already orphans that used to > be migrated as well, but are now left where they are. > > Signed-off-by: Aaron Lauterer > --- > src/PVE/LXC/Migrate.pm | 47 +++++++++++++++--------------------------- > 1 file changed, 17 insertions(+), 30 deletions(-) > > diff --git a/src/PVE/LXC/Migrate.pm b/src/PVE/LXC/Migrate.pm > index ccf5157..8e11be7 100644 > --- a/src/PVE/LXC/Migrate.pm > +++ b/src/PVE/LXC/Migrate.pm > @@ -195,6 +195,17 @@ sub phase1 { > > return if !$volid; > > + # check if volume exists, might be a pending new one > + eval { > + PVE::Storage::path($self->{storecfg}, $volid); > + }; > + if ($@ =~ m/^unable to parse/) { I'd really like to avoid such manual error message matching, especially across package boundaries. PVE::Storage::path() calls parse_volume_id(), but that also works for storeid:1 for example, so not triggering an error for such pending changes. PVE::Storage::path() then calls the plugin's path(), but the plugin can use whatever error message it likes, so matching for something specific only covers certain plugins. Can't we just filter out the yet-to-be-created volumes by matching the NEW_DISK_RE? > + $self->log('info', "volume '$volid' does not exist (pending change?)"); > + return; > + } elsif ($@) { > + die $@; > + } > + > my ($sid, $volname) = PVE::Storage::parse_volume_id($volid); > > # check if storage is available on source node (...) > + # first all volumes referenced in snapshots > foreach my $snapname (keys %{$conf->{snapshots}}) { > &$test_volid($conf->{snapshots}->{$snapname}->{'vmstate'}, 0, undef) > if defined($conf->{snapshots}->{$snapname}->{'vmstate'}); > PVE::LXC::Config->foreach_volume($conf->{snapshots}->{$snapname}, $test_mp, $snapname); > } > > + # then all pending volumes > + if (defined $conf->{pending} && %{$conf->{pending}}) { Style nit: please use parentheses for defined > + PVE::LXC::Config->foreach_volume($conf->{pending}, $test_mp); > + } > + > # finally all current volumes > PVE::LXC::Config->foreach_volume_full($conf, { include_unused => 1 }, $test_mp); >