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

["Daniel Kral" <d.kral@proxmox.com>]

On Fri Jul 31, 2026 at 3:42 PM CEST, Erik Fastermann wrote:
>> Am 21.07.26 um 1:58 PM schrieb Erik Fastermann:
>>> This series reworks how the QEMU remote-migration precondition checks
>>> are structured and exposes them through a new endpoint, so blockers and
>>> warnings can be surfaced before a migration is started rather than
>>> mid-flight.
>>>
>>> It is deliberately sent as an RFC: the change touches a critical path,
>>> and the larger direction (see the open questions below) matters more
>>> than the current diff. Thanks to @Fabian Gruenbichler for the discussion
>>> so far.
>>>
>>> Motivation
>>> ==========
>>>
>>> Today the checks run at the very start of a remote migration and abort
>>> on the first error via die. Two problems follow:
>>>
>>> - Many prerequisites are not checked up front at all; they only surface
>>>    once the migration is already running, e.g. local/mapped devices or a
>>>    VNC clipboard that is not live-migratable. A user fixes one blocker,
>>>    retries, and hits the next. A forum user collected a checklist of such
>>>    prerequisites [0] (thanks @Arthur Bied-Charreton for pointing this
>>>    out).
>>>
>>> - The qm CLI wrapper only ran a subset of the checks the API path ran,
>>>    so direct API callers (e.g. the web UI) and the CLI disagreed on what
>>>    was validated.
>>>
>>> What the series does
>>> ====================
>>>
>>> 1. Drop the ineffective fingerprint auto-detection.
>>>
>>> 2. Extract the checks into a validate_remote_migrate_preconditions
>>>     helper.
>>>
>>> 3. Register the remote-migrate command against PVE::API2::Qemu
>>>     directly and drop the CLI wrapper, so CLI and API run the exact same
>>>     checks.
>>>
>>> 4. Add a remote_migrate_vm_precondition endpoint that runs the checks
>>>     without starting a migration and returns the full findings list. It
>>>     reuses the same helper as the migrate endpoint, so the precheck
>>>     cannot drift from what is actually enforced.
>>>
>>> The precondition results are returned as a flat list of findings. Does
>>> this shape look reasonable, and could a similar structure be reused for
>>> the intra-cluster migration precondition endpoint?
>> 
>> For the intra-cluster endpoint we also collect information for each
>> node, not just for a single target.
>> 
>
> Right, I phrased that badly: I meant collecting the findings per node, 
> so the shape would be a map from node to findings list rather than a 
> single list.
>
> One argument for the flat-list shape that I should have made up front: 
> It looks like the web UI already reduces the endpoint output to this 
> shape in window/Migrate.js which builds migration.preconditions, a list 
> of { text, severity: error|warning } objects.
>
> Reworking the intra-cluster endpoint is out of scope for this series 
> though. I only want the findings shape designed so it can be reused 
> there later.

Just as a heads-up: As part of deriving node affinity rules from the
intra-cluster migration blockers / constraints, I'm working on a patch
series for the intra-cluster part at the moment.

This is done to infer such constraints automatically for HA resources,
but allows us to broaden some CRS functionalities as the load balancing
mechanism to non-HA resources as well without burdening users to encode
all these constraints manually as affinity rules.

Though there we need the functionality to derive these constraints for
all guests (VMs and LXCs) and all cluster nodes at once and need to know
if any of the required configs have changed so we don't need to
reevaluate all these cluster-wide constraint checks every CRM round.

So I suppose the structure for these might be quite different from the
ones for the intra-cluster checks, but as you said this is out-of-scope
of your patch series, I just wanted to give a heads-up :)