From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <pve-devel-bounces@lists.proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id 841521FF195 for <inbox@lore.proxmox.com>; Fri, 7 Mar 2025 14:41:08 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 1F5201BF25; Fri, 7 Mar 2025 14:41:01 +0100 (CET) Message-ID: <ccfe0047-532a-438c-99d4-10d98e7f86f6@proxmox.com> Date: Fri, 7 Mar 2025 14:40:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Fiona Ebner <f.ebner@proxmox.com> To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>, Dominik Csapak <d.csapak@proxmox.com> References: <20250213131716.3062383-1-d.csapak@proxmox.com> <20250213131716.3062383-17-d.csapak@proxmox.com> <ad55dab2-8218-4063-9e8b-1a76963d6fe8@proxmox.com> Content-Language: en-US In-Reply-To: <ad55dab2-8218-4063-9e8b-1a76963d6fe8@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL -0.043 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.001 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.001 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.001 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 URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [nodes.pm] Subject: Re: [pve-devel] [PATCH manager v6 3/5] bulk migrate: include checks for live-migratable local resources X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" <pve-devel-bounces@lists.proxmox.com> Am 07.03.25 um 14:30 schrieb Fiona Ebner: > Am 13.02.25 um 14:17 schrieb Dominik Csapak: >> those should be able to migrate even for online vms. If the mapping does >> not exist on the target node, that will be caught further down anyway. >> >> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com> >> --- >> no changes in v6 >> PVE/API2/Nodes.pm | 13 +++++++++++-- >> 1 file changed, 11 insertions(+), 2 deletions(-) >> >> diff --git a/PVE/API2/Nodes.pm b/PVE/API2/Nodes.pm >> index f504e1b1..f5484280 100644 >> --- a/PVE/API2/Nodes.pm >> +++ b/PVE/API2/Nodes.pm >> @@ -2331,9 +2331,18 @@ my $create_migrate_worker = sub { >> $invalidConditions .= join(', ', map { $_->{volid} } @{$preconditions->{local_disks}}); >> } >> >> + # for a live migration all local_resources must be marked as live-migratable >> if ($online && scalar($preconditions->{local_resources}->@*)) { >> - $invalidConditions .= "\n Has local resources: "; >> - $invalidConditions .= join(', ', @{$preconditions->{local_resources}}); >> + my $resource_not_live = []; >> + for my $resource ($preconditions->{local_resources}->@*) { >> + next if $preconditions->{'mapped-resource-info'}->{$resource}->{'live-migration'}; >> + push $resource_not_live->@*, $resource; >> + } >> + >> + if (scalar($resource_not_live->@*)) { >> + $invalidConditions .= "\n Has local resources not marked as live migratable: "; >> + $invalidConditions .= join(', ', $resource_not_live->@*); >> + } >> } >> >> if (my $not_allowed_nodes = $preconditions->{not_allowed_nodes}) { > > Should we rather not add those to the "local_resources" result in the > first place? I.e. in check_local_resources() we know whether it's a live > migration or not based on the $state argument. > > And towards the end of that function we could... > >> if ($k =~ m/^hostpci/) { >> my $entry = parse_property_string('pve-qm-hostpci', $conf->{$k}); >> if (my $name = $entry->{mapping}) { >> $add_missing_mapping->('pci', $k, $name); >> my $mapped_device = { name => $name }; >> $mapped_device->{'live-migration'} = 1 >> if $pci_map->{ids}->{$name}->{'live-migration-capable'}; >> $mapped_res->{$k} = $mapped_device; >> } >> } >> # sockets are safe: they will recreated be on the target side post-migrate >> next if $k =~ m/^serial/ && ($conf->{$k} eq 'socket'); > > ...do "next if live-migration" and not even add it. Or rather, next if !missing mapping && (!$state or live-migration). I.e. also not adding them for offline migration to the local resources in the first place. AFAIU, local_resources/loc_res was intended to be the current blockers for the offline or online migration at hand. Can we go back and align the behavior to that meaning? Currently, we add mapped devices even if they are not blockers. Do we already rely too much on that? > >> push @loc_res, $k if $k =~ m/^(usb|hostpci|serial|parallel)\d+$/; > _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel