From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id 632ED1FF0ED for ; Fri, 31 Jul 2026 16:44:58 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 211AE2154E; Fri, 31 Jul 2026 16:44:58 +0200 (CEST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Fri, 31 Jul 2026 16:44:54 +0200 Message-Id: From: "Daniel Kral" To: "Erik Fastermann" , "Fiona Ebner" , Subject: Re: [RFC qemu-server 0/4] remote migrate: extract preconditions and add check endpoint X-Mailer: aerc 0.21.0-182-g3a1473130cd0-dirty References: <20260721115827.163442-1-e.fastermann@proxmox.com> <2b01d1e2-56e8-47ef-986f-99f16ea1a93f@proxmox.com> In-Reply-To: X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1785509085070 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.216 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_LOW -0.7 Sender listed at https://www.dnswl.org/, low trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: JAQBSSZWVUDNMR6PHIZJWIAA6RJXJK6E X-Message-ID-Hash: JAQBSSZWVUDNMR6PHIZJWIAA6RJXJK6E X-MailFrom: d.kral@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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 discussio= n >>> so far. >>> >>> Motivation >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> 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 su= ch >>> 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 wha= t >>> was validated. >>> >>> What the series does >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> 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 sam= e >>> 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? >>=20 >> For the intra-cluster endpoint we also collect information for each >> node, not just for a single target. >>=20 > > Right, I phrased that badly: I meant collecting the findings per node,=20 > so the shape would be a map from node to findings list rather than a=20 > single list. > > One argument for the flat-list shape that I should have made up front:=20 > It looks like the web UI already reduces the endpoint output to this=20 > shape in window/Migrate.js which builds migration.preconditions, a list= =20 > of { text, severity: error|warning } objects. > > Reworking the intra-cluster endpoint is out of scope for this series=20 > though. I only want the findings shape designed so it can be reused=20 > 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 :)