From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <f.ebner@proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by lists.proxmox.com (Postfix) with ESMTPS id D4C65AF6D
 for <pve-devel@lists.proxmox.com>; Wed, 23 Nov 2022 10:09:16 +0100 (CET)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
 by firstgate.proxmox.com (Proxmox) with ESMTP id BEC291FED9
 for <pve-devel@lists.proxmox.com>; Wed, 23 Nov 2022 10:09:16 +0100 (CET)
Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com
 [94.136.29.106])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
 (No client certificate requested)
 by firstgate.proxmox.com (Proxmox) with ESMTPS
 for <pve-devel@lists.proxmox.com>; Wed, 23 Nov 2022 10:09:15 +0100 (CET)
Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1])
 by proxmox-new.maurer-it.com (Proxmox) with ESMTP id B105A4436C;
 Wed, 23 Nov 2022 10:09:15 +0100 (CET)
Message-ID: <aa0a3adc-7a25-4cc3-069b-17f7e1bfb0c7@proxmox.com>
Date: Wed, 23 Nov 2022 10:09:10 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.5.0
To: pve-devel@lists.proxmox.com,
 "DERUMIER, Alexandre" <Alexandre.DERUMIER@groupe-cyllene.com>
References: <19713dd51749ed24a5ecda1c6930191ed8fc4c11.camel@groupe-cyllene.com>
Content-Language: en-US
From: Fiona Ebner <f.ebner@proxmox.com>
In-Reply-To: <19713dd51749ed24a5ecda1c6930191ed8fc4c11.camel@groupe-cyllene.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-SPAM-LEVEL: Spam detection results:  0
 AWL 0.027 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
 NICE_REPLY_A           -0.001 Looks like a legit reply (A)
 SPF_HELO_NONE           0.001 SPF: HELO does not publish an SPF Record
 SPF_PASS               -0.001 SPF: sender matches SPF record
Subject: Re: [pve-devel] cluster resource scheduler question
X-BeenThere: pve-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Wed, 23 Nov 2022 09:09:16 -0000

Am 22.11.22 um 17:43 schrieb DERUMIER, Alexandre:
> Hi,
> 
> I was looking at the proxmox 7.3 video
> https://www.proxmox.com/en/training/video-tutorials/item/what-s-new-in-proxmox-ve-7-3
> 
> showing the new cluster resource scheduling with static-ressource.
> 
> I'm not sure to understand, but the video seem to say that vm is
> migrated to the least "loaded" node.

yes, the video is misleading there. The static node CPU and memory
values and the configured CPU and memory for guests will be used to
approximate the real usage.

> 
> 
> But looking at static-info of the node,  cpu && memory are the physical
> core number && full memory size
> 
> (in pvestatd,
> 
>     broadcast_static_node_info($maxcpu, $meminfo->{memtotal});
>      my sub broadcast_static_node_info {
>       ...
>         my $info = {
>             cpus => $cpus,
>             memory => $memory,
>      }
> 
> 
> I'm not sure about the logic, but if we only look at number of total
> cpus && memory without current usage, the biggest node will always be
> choose ?  or does I miss something ?

We add the static usage of all active guests (i.e. configured CPU and
memory) to the node's usage. Then, for choosing a node for a guest, we
check how the highest/average CPU/memory usage (in percent) in the
cluster would look like after starting the guest on each node and score
according to those alternatives. In effect, the alternative leading to
the least load (in percent) across the cluster, according to the model
with static guest and node information will be chosen.