[pve-devel] [PATCH manager v6 3/5] bulk migrate: include checks for live-migratable local resources

[Dominik Csapak]

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.csapak at 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"