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 AD6C91FF0AE for ; Tue, 13 Oct 2026 15:57:27 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id E4AEE2133C; Tue, 13 Oct 2026 15:57:24 +0200 (CEST) Message-ID: Date: Tue, 13 Oct 2026 15:57:20 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH ha-manager v3 05/21] lrm: resource migration: support extra migration options To: Daniel Kral , pve-devel@lists.proxmox.com References: <20260918160841.128088-1-f.ebner@proxmox.com> <20260918160841.128088-6-f.ebner@proxmox.com> Content-Language: en-US From: Fiona Ebner In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1791899840956 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.432 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: H7JNWK5THCJOBIYC4EH5LTITLB3O6FTI X-Message-ID-Hash: H7JNWK5THCJOBIYC4EH5LTITLB3O6FTI X-MailFrom: f.ebner@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: Am 09.10.26 um 3:34 PM schrieb Daniel Kral: > On Fri Sep 18, 2026 at 6:08 PM CEST, Fiona Ebner wrote: >> diff --git a/src/PVE/HA/LRM.pm b/src/PVE/HA/LRM.pm >> index 72e37e6..5fc66eb 100644 >> --- a/src/PVE/HA/LRM.pm >> +++ b/src/PVE/HA/LRM.pm >> @@ -749,14 +749,19 @@ sub manage_resources { >> # intermediate step for optional better node selection on stop -> start request state change >> next if $request_state eq 'request_start'; >> >> + my $params = { >> + 'target' => $sd->{target}, >> + 'timeout' => $sd->{timeout}, >> + }; >> + if (defined($sd->{'migrate-options'})) { >> + $params->{'migrate-options'} = $sd->{'migrate-options'}; >> + } > > nit: pre-existing, but since 'target' and 'timeout' are set in the > $params hash here unconditionally, couldn't we do the same for > 'migrate-options' here as well, just for consistency/readability? > > $params would then just be the hash of $sd properties that can be > passed through as LRM resource command properties, but need a > definedness check before these are used in the LRM workers. > Ideal would be a per-command mapping and have only entries in the hash for parameters that the command actually takes. But seems not worth it and unrelated to my series here, so I'll go with your suggestion for consistency. >> + >> $self->queue_resource_command( >> $sid, >> $sd->{uid}, >> $request_state, >> - { >> - 'target' => $sd->{target}, >> - 'timeout' => $sd->{timeout}, >> - }, >> + $params, >> ); >> } >>