Re: [RFC qemu-server 1/1] fix #7053: api: migrate: save and restore migration params for HA managed VMs

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

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.
>>> 
>>
>> 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=6220

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@proxmox.com/