From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 73A431FF191 for ; Tue, 21 Oct 2025 17:50:27 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id B2E613A0E; Tue, 21 Oct 2025 17:50:50 +0200 (CEST) From: Friedrich Weber To: pve-devel@lists.proxmox.com Date: Tue, 21 Oct 2025 17:50:27 +0200 Message-ID: <20251021155034.143672-1-f.weber@proxmox.com> X-Mailer: git-send-email 2.47.2 MIME-Version: 1.0 X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1761061836395 X-SPAM-LEVEL: Spam detection results: 0 AWL -0.990 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 KAM_MAILER 2 Automated Mailer Tag Left in Email RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. 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. [api2tools.pm] Subject: [pve-devel] [PATCH manager] api2 tools: rrd data: prefer new-format keys over old-format keys 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: , Reply-To: Proxmox VE development discussion Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" This fixes an issue where on a fresh Proxmox VE 9 cluster, the status of the first VM/container would not be updated in the resource tree for the first 5 minutes after creation. For example, starting the newly created guest after the first pvestatd status update would not update the state to "running" for 5 minutes. The reason is that pvestatd, when broadcasting RRD data, checks for existence of /var/lib/rrdcached/db/pve-vm-9.0/ to decide whether to send RRD data with new-format (pve-vm-9.0/) or old-format (pve2.3-vm/) keys. The directory does not exist on nodes of a fresh cluster without guests, so pvestatd falls back to sending an old-format key. pmxcfs, upon receiving the key, creates the directory, so on the next pvestatd status update, pvestatd will send out new-format keys. But until the entry with the old-format key expires (after 5 minutes), both the new-format and the old-format key exist in the RRD data. Currently, if both keys are present, get_rrd_key will return the old-format key, meaning that any status updates with the new-format key are not registered. In order to fix this, prefer the new-format key if it is present. Signed-off-by: Friedrich Weber --- Notes: Encountered during a training, where one is more likely to closely watch the state of the first created guest. I'm unsure if this is a good fix. An alternative fix for this particular case would be to instead have pvestatd always send out new-style keys on a fresh cluster. However, another situation where there could be both old-format and new-format keys is in a mixed 8+9 cluster (e.g. during upgrade). One issue is that get_rrd_key on 8 would still prefer old-style keys (unless we backport this patch to 8), so behavior on 8 and 9 would be different. Another issue is that having both an old-format and new-format key could happen after migrating a VM from a PVE 8 node (sending old-format keys) to a PVE 9 node (sending new-format keys). In this direction, I guess we also want to prefer new-format keys over the old-format keys. But when migrating a VM from a PVE 9 (sending new-format keys) to a PVE 8 node (sending old-format keys) -- which is admittedly not supported -- it would make more sense to prefer old-format keys. Perhaps a better solution is, if both old-format and new-format keys are present, to prefer the key whose entry has the more recent timestamp (ctime)? PVE/API2Tools.pm | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/PVE/API2Tools.pm b/PVE/API2Tools.pm index 863f5f55..a1a6f39e 100644 --- a/PVE/API2Tools.pm +++ b/PVE/API2Tools.pm @@ -45,17 +45,17 @@ sub get_hwaddress { sub get_rrd_key { my ($rrd, $type, $id) = @_; + my $key = "pve-${type}-9.0/${id}"; + if (defined($rrd->{$key})) { + return $key; + } + # check for old formats: pve2-{type}/{id}. For VMs and CTs the version number is different than for nodes and storages if ($type ne "vm" && exists $rrd->{"pve2-${type}/${id}"}) { return "pve2-${type}/${id}"; } elsif ($type eq "vm" && exists $rrd->{"pve2.3-${type}/${id}"}) { return "pve2.3-${type}/${id}"; } - - my $key = "pve-${type}-9.0/${id}"; - if (defined($rrd->{$key})) { - return $key; - } } sub extract_node_stats { -- 2.47.2 _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel