From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9]) by lore.proxmox.com (Postfix) with ESMTPS id A25F71FF13F for ; Thu, 09 Apr 2026 13:44:03 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 682F02B7D; Thu, 9 Apr 2026 13:43:30 +0200 (CEST) From: Daniel Kral To: pve-devel@lists.proxmox.com Subject: [PATCH docs 14/18] ha-manager: crs: add more information about rebalance on start in its section Date: Thu, 9 Apr 2026 13:41:40 +0200 Message-ID: <20260409114224.323102-15-d.kral@proxmox.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260409114224.323102-1-d.kral@proxmox.com> References: <20260409114224.323102-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: 1775734880201 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.081 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 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: UGK64LUMIQQSZ5Y7SIU7A5FNBHFGPRVP X-Message-ID-Hash: UGK64LUMIQQSZ5Y7SIU7A5FNBHFGPRVP 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: The information which node is considered as the best suited for an HA resource was only described in the static-load scheduler section. To define it both, add the description for the basic load scheduler and move the description from the static-load scheduler section to the description of the HA resource rebalance on start section. The important notice about the technology preview is merged and also moved to the rebalance-on-start section, as the technology preview only really applies to this functionality instead of the whole static-load scheduler mode. The link macros for the scheduler modes are needed for the references in the new paragraphs and are the same as the ones, which were previously auto-generated. Signed-off-by: Daniel Kral --- ha-manager.adoc | 34 ++++++++++++++++++++-------------- 1 file changed, 20 insertions(+), 14 deletions(-) diff --git a/ha-manager.adoc b/ha-manager.adoc index 682e254..979e5e1 100644 --- a/ha-manager.adoc +++ b/ha-manager.adoc @@ -1438,6 +1438,7 @@ round, which should take no longer than 10 seconds. NOTE: There are plans to add modes for (static and dynamic) load-balancing in the future. +[[_basic_scheduler]] Basic Scheduler ^^^^^^^^^^^^^^^ @@ -1445,28 +1446,15 @@ The number of active HA resources on each node is used to choose the best-fitting node for an HA resource. Non-HA-managed resources are currently not counted. +[[_static_scheduler]] Static-Load Scheduler ^^^^^^^^^^^^^^^^^^^^^ -IMPORTANT: The static mode is still a technology preview. - Static usage information from HA resources on each node is used to choose the best-fitting node for an HA resource. This includes the configured CPU and memory quotas for the HA resources. Usage of non-HA-managed resources is currently not considered. -For this selection, each node in turn is considered as if the HA resource was -already running on it, using CPU and memory usage from the associated guest -configuration. Then for each such alternative, CPU and memory usage of all nodes -are considered, with memory being weighted much more, because it's a truly -limited resource. For both, CPU and memory, highest usage among nodes (weighted -more, as ideally no node should be overcommitted) and average usage of all nodes -(to still be able to distinguish in case there already is a more highly -committed node) are considered. - -IMPORTANT: The more HA resources the more possible combinations there are, so -it's currently not recommended to use it if you have thousands of HA resources. - [[ha_manager_crs_scheduling_points]] CRS Scheduling Points ~~~~~~~~~~~~~~~~~~~~~ @@ -1510,9 +1498,27 @@ When starting an HA resource with rebalance on start enabled, the CRS will select the node best suited for the HA resource. If the selected node is not the current node, the HA resource will be migrate to the selected node. +For the xref:_basic_scheduler[basic scheduler mode], the node with the least +resources count is considered as the best suited node. + +For the xref:_static_scheduler[static-load scheduler mode], each node in turn +is considered as if the HA resource was already running on it, using CPU and +memory usage from the associated guest configuration. Then for each such +alternative, CPU and memory usage of all nodes are considered, with memory +being weighted much more, because it's a truly limited resource. For both, CPU +and memory, highest usage among nodes (weighted more, as ideally no node should +be overcommitted) and average usage of all nodes (to still be able to +distinguish in case there already is a more highly committed node) are +considered. + This setting can be enabled with the CRS option `ha-rebalance-on-start` in the web interface under `Datacenter` -> `Options` -> `Cluster Resource Scheduling`. +IMPORTANT: For the static-load scheduler mode, this functionality is still in +technology preview. The more HA resources the more possible combinations there +are, so it's currently not recommended to use it if you have thousands of HA +resources. + ifdef::manvolnum[] include::pve-copyright.adoc[] endif::manvolnum[] -- 2.47.3