From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id CA3341FF136 for ; Mon, 09 Mar 2026 14:14:31 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 90BC1340C4; Mon, 9 Mar 2026 14:14:24 +0100 (CET) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 09 Mar 2026 14:13:48 +0100 Message-Id: From: "Daniel Kral" To: "Daniel Kral" , "Fiona Ebner" , Subject: Re: [RFC qemu-server 1/1] fix #7053: api: migrate: save and restore migration params for HA managed VMs X-Mailer: aerc 0.21.0-38-g7088c3642f2c-dirty References: <20260225143514.368884-1-d.kral@proxmox.com> <20260225143514.368884-2-d.kral@proxmox.com> <3a550b2b-8164-4bab-9915-89ba65ca2136@proxmox.com> In-Reply-To: X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1773061996171 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.034 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment RCVD_IN_MSPIKE_H2 0.001 Average reputation (+2) 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: 4VXQ4MR2VDNQSYHBG5MHA6W3SIFSF3NB X-Message-ID-Hash: 4VXQ4MR2VDNQSYHBG5MHA6W3SIFSF3NB 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 Tue Mar 3, 2026 at 10:08 AM CET, Daniel Kral wrote: > Thanks for the feedback, Fiona! > > On Mon Mar 2, 2026 at 5:06 PM CET, Fiona Ebner wrote: >> Am 25.02.26 um 3:35 PM schrieb Daniel Kral: >>> As the migrate_vm API request is proxied to the node, where the HA >>> resource is assigned to, this allows the migrate parameters to stored >>> locally while the migration request is passed through the HA stack. >>>=20 >> >> I'm fine with this approach :) > > Nice! > > One design issue here I overlooked at first though is that if a HA > resource has dependent HA resources from a positive resource affinity > rule (which are shown to users either through the migration > preconditions and after initiating the migration), those will not have > the migration parameters passed down... I'm not sure yet if that is > wanted or not, as migrating them is only a side-effect and not all > parameters (e.g. `--with-conntrack-state`) are applicable to both guest > types of course. > > If we want to go for passing them to the dependent HA resources, we > might as well fix this together with #6220 [0] as indexing the migration > parameters by the task rather than vmid would make it possible to store > and retrieve this information in/from a single place. > > But it feels like this is more of a opt-in feature that can be added > later on rather than now as both behaviors seem valid for different use > cases. > [...] > > [0] https://bugzilla.proxmox.com/show_bug.cgi?id=3D6220 Fiona and I discussed this off-list. We came to the conclusion that it would be better to expose the migration of dependent resources (or "resource bundles" as it is called in the dynamic load balancing series for now [0]) either as its own migrate API endpoint or as part of the bulk migration API endpoint than passing them to dependent resources with the migrate_vm API. This is because migrate_vm is only intended to migrate a single guest right now and at least from the web interface view it would make the sense to show the resource bundle members in the bulk migration view instead of as side-effects of a single VM migration. We're not sure yet if users must use the bundle / bulk migration API endpoint for resource bundles in some future release or can still use the migrate_vm though. Otherwise, the migration parameters file is a good mid-term solution, but a more robust solution would be to have per-guest migration options, such that users can control these parameters for each VM and don't have to set them on individual migration requests. That allows users to control which parameters are used even though some automatic migration request is made, e.g., by the HA stack. Fiona also pointed out that the 'with-conntrack-state' option should be set 1 for newly created VMs alltogether (while older VMs can be opt-in later through the per-guest migration options), as this is likely what users want e.g. for the upcoming automatic rebalancing migrations [0]. @Christoph, do you know about any mishaps that could occur if we set 'with-conntrack-state' for the migrations of all new VMs? [0] https://lore.proxmox.com/pve-devel/20260217141437.584852-1-d.kral@proxm= ox.com/