Re: [RFC qemu-server 0/4] remote migrate: extract preconditions and add check endpoint

[Fiona Ebner <f.ebner@proxmox.com>]

Am 31.07.26 um 3:42 PM schrieb Erik Fastermann:
>> Am 21.07.26 um 1:58 PM schrieb Erik Fastermann:
>>> - Running the checks over the Tunnel command instead would add a new
>>>    command that older endpoints do not understand. Both here and for the
>>>    API, a capability/feature endpoint could help: source and/or target
>>>    query what each supports for a migration, and older versions fall
>>>    back to the current checks. Is that worth introducing now?
>>
>> The capability negotiation can be done via a new tunnel command, see:
>> https://lore.proxmox.com/pve-devel/b072f9d7-
>> b0f8-41fc-8c37-7ea90798aa1b@proxmox.com/
>>
>> It should be possible to issue the capabilities command to the target
>> and detect if the target side understands it (look at the error message
>> to see if unknown or failed for other reasons) and otherwise it's too
>> old and has no capabilities at all.
>>
> 
> That direction makes sense to me. Concretely:
> 
> - Add a capabilities tunnel command, plus a precondition tunnel command
> in which the source sends the relevant config and the target runs the
> checks it can answer better than the source can.
> 
> - The existing source-side checks stay. They are still the only thing
> that runs against a target without the capability, so removing them
> would mean no checks at all for new -> old migrations.
> 
> - New checks that need target-side knowledge go through the new command;
> new checks that are purely source-config-derived go into the shared
> helper this series adds.
> 
> - The new tunnel commands are issued by the precondition endpoint.

As well as the actual migration later.

> 
> - That leaves the current series structurally as-is, with your feedback
> applied, and the tunnel work follows on top.
> 
> What do you think about this?

Sounds good to me :)