From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id 874A31FF0AE for ; Tue, 13 Oct 2026 14:23:39 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id F3D28213BC; Tue, 13 Oct 2026 14:23:35 +0200 (CEST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Tue, 13 Oct 2026 14:22:43 +0200 Message-Id: From: "Daniel Kral" To: "Fiona Ebner" , Subject: Re: [PATCH ha-manager v3 08/21] queue resource motion: support migration options X-Mailer: aerc 0.22.0-10-g6373ac9d2179-dirty References: <20260918160841.128088-1-f.ebner@proxmox.com> <20260918160841.128088-9-f.ebner@proxmox.com> In-Reply-To: <20260918160841.128088-9-f.ebner@proxmox.com> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1791894163896 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.834 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_MED -2.3 Sender listed at https://www.dnswl.org/, medium 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: SWHDE53GD52RE5F2E4CPXTO7FE3SDVQI X-Message-ID-Hash: SWHDE53GD52RE5F2E4CPXTO7FE3SDVQI 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 Sep 18, 2026 at 6:08 PM CEST, Fiona Ebner wrote: > Signed-off-by: Fiona Ebner > --- > > New in v3. > > src/PVE/HA/Manager.pm | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/src/PVE/HA/Manager.pm b/src/PVE/HA/Manager.pm > index 1d9ff36..555ea0d 100644 > --- a/src/PVE/HA/Manager.pm > +++ b/src/PVE/HA/Manager.pm > @@ -294,7 +294,7 @@ sub load_balance { > ); > $haenv->log('info', "auto rebalance - $task $sid to $target ($imbala= nce_change_str)"); > =20 > - $self->queue_resource_motion($cmd, $task, $sid, $target); > + $self->queue_resource_motion($cmd, $task, $sid, $target, {}); > } > =20 > sub cleanup { > @@ -609,7 +609,7 @@ sub read_lrm_status { > } > =20 > sub queue_resource_motion { > - my ($self, $cmd, $task, $sid, $target) =3D @_; > + my ($self, $cmd, $task, $sid, $target, $migrate_options) =3D @_; > =20 > my ($haenv, $sc, $ss, $ns, $compiled_rules) =3D $self->@{qw(haenv sc= ss ns compiled_rules)}; > my $online_nodes =3D { map { $_ =3D> 1 } $self->{ns}->list_online_no= des()->@* }; > @@ -640,7 +640,7 @@ sub queue_resource_motion { > } > =20 > $haenv->log('info', "got crm command: $cmd"); > - $ss->{$sid}->{cmd} =3D [$task, $target]; > + $ss->{$sid}->{cmd} =3D [$task, $target, $migrate_options]; > =20 > for my $csid (@$dependent_resources) { > next if $ss->{$csid}->{node} && $ss->{$csid}->{node} eq $target; > @@ -651,7 +651,7 @@ sub queue_resource_motion { > "crm command '$cmd' - $task service '$csid' to node '$target= '" > . " (service '$csid' in positive affinity with service '= $sid')", > ); > - $ss->{$csid}->{cmd} =3D [$task, $target]; > + $ss->{$csid}->{cmd} =3D [$task, $target, $migrate_options]; The HA resource affinity rule could contain mixed HA resource types, so we cannot pass the same $migrate_options to all of them... e.g. if ct:100 and vm:101 are in the positive resource affinity rule, running ha-manager migrate vm:101 node2 --with-conntrack-state would make the manual migration for ct:100 fail. (Though as 'vm:101' is successfully migrated to node2, ct:100 would automatically be moved to node2 by the HA Manager to make sure the positive resource affinity rule is fullfilled.) I'm not sure how to handle this best, as it could be useful if there are only HA resource of the same type, but at the same time this is quite implicit right now. The migrateall API endpoint doesn't have the option to set the --with-conntrack-state option right now for VMs or other shared parameters such as --bwlimit, etc. > } > } > =20 > @@ -693,7 +693,7 @@ sub update_crm_commands { > "ignore crm command - service already on tar= get node: $cmd", > ); > } else { > - $self->queue_resource_motion($cmd, $task, $sid, = $node); > + $self->queue_resource_motion($cmd, $task, $sid, = $node, {}); > } > } > } else {