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 875571FF13A for ; Wed, 08 Jul 2026 10:42:15 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id D762021445; Wed, 08 Jul 2026 10:42:13 +0200 (CEST) From: Daniel Kral To: pve-devel@lists.proxmox.com Subject: [PATCH ha-manager 2/2] fix #6084: lrm: allow dropping maintenance with active HA resources Date: Wed, 8 Jul 2026 10:42:05 +0200 Message-ID: <20260708084205.69947-3-d.kral@proxmox.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260708084205.69947-1-d.kral@proxmox.com> References: <20260708084205.69947-1-d.kral@proxmox.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1783500121430 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.014 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) 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: H4RMYX34XU2FKULFNBBMNMUDVREIX3VX X-Message-ID-Hash: H4RMYX34XU2FKULFNBBMNMUDVREIX3VX 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: If a node's LRM is in the maintenance state and one of the HA resources could not be moved to another node, the node's LRM would be kept in the maintenance state even as the maintenance request on the node is lifted again. This happens because the LRM maintenance state branch for any active HA resources or workers will catch these cases and not advance to the branch which puts nodes without maintenance requests back into active state. Therefore, do advance to the next branch if the maintenance request is already lifted and the node's LRM can go back to the active state. The check for is_maintenance_requested() is intentionally put last to not change the existing execution chain as run_workers() might have some side-effects on the LRM workers itself. Signed-off-by: Daniel Kral --- src/PVE/HA/LRM.pm | 7 +++++-- src/test/test-crm-maintenance-request5/README | 5 ++--- src/test/test-crm-maintenance-request5/log.expect | 1 + 3 files changed, 8 insertions(+), 5 deletions(-) diff --git a/src/PVE/HA/LRM.pm b/src/PVE/HA/LRM.pm index 34425653..a0f8fbc4 100644 --- a/src/PVE/HA/LRM.pm +++ b/src/PVE/HA/LRM.pm @@ -456,13 +456,16 @@ sub work { $haenv->release_ha_agent_lock(); give_up_watchdog_protection($self); $self->set_local_status({ state => 'wait_for_agent_lock' }); - } elsif ($self->active_service_count() || $self->run_workers()) { + } elsif ( + ($self->active_service_count() || $self->run_workers()) + && $self->is_maintenance_requested() + ) { # keep the lock and watchdog as long as not all services cleared the node if (!$self->get_protected_ha_agent_lock()) { $self->set_local_status({ state => 'lost_agent_lock' }); } } elsif (!$self->is_maintenance_requested()) { - # empty && no maintenance mode && not exited -> need to switch active again + # no node maintenance request && not exited -> need to switch active again if ($self->get_protected_ha_agent_lock()) { $self->set_local_status({ state => 'active' }); } else { diff --git a/src/test/test-crm-maintenance-request5/README b/src/test/test-crm-maintenance-request5/README index e7fe0d5e..99612321 100644 --- a/src/test/test-crm-maintenance-request5/README +++ b/src/test/test-crm-maintenance-request5/README @@ -2,6 +2,5 @@ Test setting the maintenance mode for a node where an HA resource cannot be moved to any other node because of migration errors and moving it out of maintenance mode again. -Currently, the node will move out of the maintenance mode, but is left stuck in -maintenance state as it never reached the required state to be empty to be able -to move to active state again after the maintenance request is lifted. +The node's LRM is expected to move out of maintenance mode and state again +after the maintenance request is lifted from the node. diff --git a/src/test/test-crm-maintenance-request5/log.expect b/src/test/test-crm-maintenance-request5/log.expect index 90326ef5..a30be92d 100644 --- a/src/test/test-crm-maintenance-request5/log.expect +++ b/src/test/test-crm-maintenance-request5/log.expect @@ -49,6 +49,7 @@ err 220 node1/crm: service 'fa:109' - migration failed (exit code 1) info 220 node1/crm: service 'fa:109': state changed from 'relocate' to 'started' (node = node1) info 220 node1/crm: relocate service 'fa:109' to node 'node2' info 220 node1/crm: service 'fa:109': state changed from 'started' to 'relocate' (node = node1, target = node2) +info 221 node1/lrm: status change maintenance => active err 221 node1/lrm: service fa:109 not moved (migration error) info 240 node1/crm: node 'node1': state changed from 'maintenance' => 'online' err 240 node1/crm: service 'fa:109' - migration failed (exit code 1) -- 2.47.3