On 3/10/25 14:21, Fiona Ebner wrote:
Am 10.03.25 um 13:52 schrieb Dominik Csapak:
On 3/7/25 14:40, Fiona Ebner wrote:
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.csa...@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?
hmm i can try that, but i have a question on how to handle some situations:
there are the following possibilities (if I didn't forget one):
* non-mapped hostpci device -> local resource
* mapped hostpci device with no live migration capabilities -> local
resource + mapped
I'd only add it to local resources if $state is set too, i.e. if it is a
live migration. If it's mapped and if it's an offline migration, don't
add it.
* mapped hostpci device with live migration capabilities -> mapped only
did I understand you correctly?
I.e. local resources should only contain the config keys that are actual
blockers for the migration at hand, which differs when it's online or
offline.
ok makes sense, did a quick test here, and it seems the UI handles it already
gracefully,
(we ignore the local_resources for mapped devices alread) but wouldn't that be
a 'breaking' change,
since we did return the devices in the 'local_resources' list until now?
I'm not saying that the change would be bad, but the current description and
results would not
indicate to an api user that it's only for blocking migrations, as the current
description is
"List local resources e.g. pci, usb"
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
