From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id CEC029383B for ; Thu, 5 Jan 2023 13:48:45 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id AFD79303C for ; Thu, 5 Jan 2023 13:48:15 +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)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Thu, 5 Jan 2023 13:48:14 +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 8B9A4450EA; Thu, 5 Jan 2023 13:48:14 +0100 (CET) Message-ID: <41f55f19-f3c1-b5ac-22e3-f1ce016edf01@proxmox.com> Date: Thu, 5 Jan 2023 13:48:13 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 From: Fiona Ebner To: "DERUMIER, Alexandre" , "pve-devel@lists.proxmox.com" , "aderumier@odiso.com" References: <20221209192726.1499142-1-aderumier@odiso.com> <20221209192726.1499142-3-aderumier@odiso.com> <821fd1f6894a4871c43f436d4ead587a7b4210bc.camel@groupe-cyllene.com> Content-Language: en-US In-Reply-To: <821fd1f6894a4871c43f436d4ead587a7b4210bc.camel@groupe-cyllene.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL 1.493 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 -2.939 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 URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [proxmox.com, pci.pm] Subject: Re: [pve-devel] [PATCH qemu-server 02/10] add memory parser X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2023 12:48:45 -0000 Am 02.01.23 um 12:23 schrieb DERUMIER, Alexandre: > Le vendredi 16 décembre 2022 à 14:38 +0100, Fiona Ebner a écrit : >> From a modularity standpoint, it would be nice to move the format >> description, parsing+printing to PVE/QemuServer/Memory.pm, similar to >> how it is done in PVE/QemuServer/PCI.pm >> >> Since $confdesc->{memory}->{default} is now gone, load_defaults() >> will >> not return a default for 'memory' anymore. And $conf->{memory} needs >> to >> be parsed everywhere. These two things will break getting static >> usage >> in HA manager, which uses load_defaults() and relies on $conf- >>> {memory} >> to be a single value right now. We can switch there to use >> get_current_memory() too of course, but it'd require a versioned >> Breaks+Depends. >> >> Alternatively, we could add a function in qemu-server for calculating >> the static stats and call that from HA. Requires a versioned >> Breaks+Depends too, but then we'd be safe in the future and also >> catch >> such changes more easily. OTOH, it'd make the coupling go in the >> other >> direction: if HA manager wants to change what it uses for static >> consideration, then qemu-server would need to adapt. So not sure. > > I was think about this, > When dynamic scheduler will be implemented, you'll need to use values > streamed from pvestatd. > So why can't we do the same for static values ? (maxmem && maxcpus are > already send by pvestatd). > > This should avoid the need to parse vm config, > and maybe avoid to use load_config ? > (from your initial commit, > https://git.proxmox.com/?p=pve-ha-manager.git;a=commit;h=561e7f4bfb235fcdca5b0bbb8422ce742a5da75f, > it seem to be slow) > > The information is already readily available on the cluster file system, so sending it around via pvestatd additionally isn't ideal IMHO. maxmem and maxcpus are only one per node and were not available before. The load_config() call is not really problematic, because the result from cfs_read_file() is cached. The real issue is that recompute_online_node_usage() and thus getting the static info is called very often currently. There was an RFC [0] to get the information using PVE::Cluster::get_guest_config_properties(), but it's only twice as fast. Optimizing how often we call recompute_online_node_usage() can give us much more. In any case, HA manager needs to be adapted before the memory setting can be turned into a property string. [0]: https://lists.proxmox.com/pipermail/pve-devel/2022-November/054956.html