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