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 369041FF138 for ; Tue, 21 Jul 2026 13:59:03 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 0542C214BE; Tue, 21 Jul 2026 13:59:03 +0200 (CEST) From: Erik Fastermann To: pve-devel@lists.proxmox.com Subject: [RFC qemu-server 0/4] remote migrate: extract preconditions and add check endpoint Date: Tue, 21 Jul 2026 13:58:23 +0200 Message-ID: <20260721115827.163442-1-e.fastermann@proxmox.com> X-Mailer: git-send-email 2.47.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 2 AWL -0.063 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) KAM_LAZY_DOMAIN_SECURITY 1 Sending domain does not have any anti-forgery methods RDNS_NONE 1.274 Delivered to internal network by a host with no rDNS SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_NONE 0.001 SPF: sender does not publish an SPF Record Message-ID-Hash: 66OV243VYQMTGWP3GYQCM3USCB4C5C3Z X-Message-ID-Hash: 66OV243VYQMTGWP3GYQCM3USCB4C5C3Z X-MailFrom: efastermann@ruth.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 CC: Erik Fastermann X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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? Open questions (RFC) ==================== Scope of the checks - The checks should stay semi-static, i.e. mostly config-derived, and run quickly, i.e. avoid slow probes such as querying storage contents. But we still want to query the remote, since a precheck that never talks to the target is not very useful. Where/how can we reasonably reduce the number of API round trips to the remote? Where should the checks run? - The source node currently runs the checks with a few local and fast remote API calls. Since we want migrations between major versions to work in a mostly forward- and backward-compatible way (older source to newer target being the typical case), it might be cleaner to run the checks on the remote by sending the relevant local config over. When the remote is newer, it can also run more or patched checks. Of course this would be a larger change, as the general structure currently goes from source to target. - Collecting results from both sides in PDM and comparing there seems wrong: the checks still have to run locally for the real migration, and both paths would then need to agree. We should rather keep a single authority. - 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? Two-phase refactor - The cleaner fix for "checks only run mid-migration" is to extract all preconditions and split execution into two phases. Phase 1 is shared by the precondition endpoint and the migration: it runs all the reasonable checks and builds a plan hash of the queried info. Phase 2 performs the actual migration, ideally with its remaining checks up front and ordered fast-to-slow. This is a large refactor of a critical path, as the cluster migration code is mostly shared with the remote migration. In addition, the cluster migration precondition endpoint can also be refactored, which is an open TODO. Is that the direction we want? Containers - A similar series could later cover remote container migration. What pitfalls should I watch out for there? References ========== [0] https://forum.proxmox.com/threads/pdm-cross-cluster-migration-prerequisites-checklist-i-wish-i-had-before-my-first-attempt.184485 Thanks in advance for the feedback! Erik Fastermann (4): remote migrate: drop ineffective fingerprint auto-detection remote migrate: collect preconditions as structured findings qm: remote-migrate: call API endpoint directly remote migrate: add precondition check endpoint src/PVE/API2/Qemu.pm | 472 +++++++++++++++++++++++++++++-------------- src/PVE/CLI/qm.pm | 128 +----------- 2 files changed, 323 insertions(+), 277 deletions(-) -- 2.47.3