public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Dominik Csapak <d.csapak@proxmox.com>
To: Fiona Ebner <f.ebner@proxmox.com>,
	Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH manager 01/10] api/pvestatd: broadcast and expose non-x86 host architecture
Date: Thu, 29 Jan 2026 10:20:27 +0100	[thread overview]
Message-ID: <f4e92f14-f015-4d44-b430-90c30410511f@proxmox.com> (raw)
In-Reply-To: <8ddda307-76c3-4177-8b79-c22116eaa12f@proxmox.com>



On 1/28/26 5:04 PM, Fiona Ebner wrote:
> Am 28.01.26 um 1:29 PM schrieb Dominik Csapak:
>> in case a nodes runs a non-x86 kernel, broadcast that info into the
> 
> typo: nodes -> node
> 
>> 'static-info' hash to pmxcfs (once). Use that info to add an
>> 'architecture' property to /cluster/resources.
>>
>> x86 nodes won't return a value here.
>>
>> Use 'POSIX::uname' for determining the architecture (from the running
>> kernel). POSIX is used in this module anyway but was missing in the
>> imports.
>>
>> Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
>> ---
>>   PVE/API2/Cluster.pm     |  9 +++++++++
>>   PVE/API2/Nodes.pm       |  3 ++-
>>   PVE/Service/pvestatd.pm | 10 ++++++++++
>>   3 files changed, 21 insertions(+), 1 deletion(-)
>>
>> diff --git a/PVE/API2/Cluster.pm b/PVE/API2/Cluster.pm
>> index d6003a7d..73b948b5 100644
>> --- a/PVE/API2/Cluster.pm
>> +++ b/PVE/API2/Cluster.pm
>> @@ -484,6 +484,12 @@ __PACKAGE__->register_method({
>>                       type => "string",
>>                       optional => 1,
>>                   },
>> +                architecture => {
>> +                    description => "The nodes CPU architecture. (for type 'node').",
> 
> typo: nodes -> node's
> 
>> +                    type => 'string',
> 
> could also be an enum

i also thought about that but was not sure if we should limit ourselves
in the response here.

  can do of course, and would add

'x86_64' and 'aarch64'


> 
>> +                    default => 'x86_64',
>> +                    optional => 1,
>> +                },
>>               },
>>           },
>>       },
>> @@ -608,6 +614,9 @@ __PACKAGE__->register_method({
>>                   if (defined(my $mode = $info->{'cgroup-mode'})) {
>>                       $entry->{'cgroup-mode'} = int($mode);
>>                   }
>> +                if (defined(my $architecture = $info->{architecture})) {
>> +                    $entry->{architecture} = $architecture;
>> +                }
>>                   if (defined(my $status = $hastatus->{node_status}->{$node})) {
>>                       $entry->{'hastate'} = $status;
>>                   }
>> diff --git a/PVE/API2/Nodes.pm b/PVE/API2/Nodes.pm
>> index 5bd6fe49..9fddea9f 100644
>> --- a/PVE/API2/Nodes.pm
>> +++ b/PVE/API2/Nodes.pm
>> @@ -502,7 +502,8 @@ __PACKAGE__->register_method({
>>           my ($avg1, $avg5, $avg15) = PVE::ProcFSTools::read_loadavg();
>>           $res->{loadavg} = [$avg1, $avg5, $avg15];
>>   
>> -        my ($current_kernel_info, $kversion_string) = get_current_kernel_info();
>> +        my ($current_kernel_info, $kversion_string) =
>> +            PVE::NodeConfig::get_current_kernel_info();
> 
> Seems like an unrelated hunk from an older iteration of the patch?


yep, in my first version i moved that function to reuse it, but 
ultimately decided against that since i only need one field
from the uname call and we use the POSIX module here anyway..

> 
>>           $res->{kversion} = $kversion_string;
>>           $res->{'current-kernel'} = $current_kernel_info;
>>   
>> diff --git a/PVE/Service/pvestatd.pm b/PVE/Service/pvestatd.pm
>> index 98d421f4..05f4061e 100755
>> --- a/PVE/Service/pvestatd.pm
>> +++ b/PVE/Service/pvestatd.pm
>> @@ -7,6 +7,7 @@ use PVE::SafeSyslog;
>>   use PVE::Daemon;
>>   
>>   use JSON;
>> +use POSIX qw();
>>   
>>   use Time::HiRes qw (gettimeofday);
>>   use PVE::Tools qw(dir_glob_foreach file_read_firstline);
>> @@ -138,6 +139,8 @@ my sub broadcast_static_node_info {
>>       my $cgroup_mode = eval { PVE::CGroup::cgroup_mode(); };
>>       syslog('err', "cgroup mode error: $@") if $@;
>>   
>> +    my (undef, undef, undef, undef, $architecture) = POSIX::uname();
>> +
>>       my $old = PVE::Cluster::get_node_kv('static-info', $nodename);
>>       $old = eval { decode_json($old->{$nodename}) } if defined($old->{$nodename});
>>   
>> @@ -147,11 +150,18 @@ my sub broadcast_static_node_info {
>>           || !defined($old->{memory})
>>           || $old->{memory} != $memory
>>           || ($old->{'cgroup-mode'} // -1) != ($cgroup_mode // -1)
>> +        || (defined($architecture)
>> +            && $architecture ne 'x86_64'
>> +            && (!defined($old->{architecture}) || $old->{architecture} ne $architecture))
>>       ) {
>>           my $info = {
>>               cpus => $cpus,
>>               memory => $memory,
>>           };
>> +
>> +        # only save architecture info for non-x86 ones
>> +        $info->{architecture} = $architecture;
>> +
>>           $info->{'cgroup-mode'} = $cgroup_mode if defined($cgroup_mode);
>>           PVE::Cluster::broadcast_node_kv('static-info', encode_json($info));
>>       }
> 





  reply	other threads:[~2026-01-29  9:20 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-28 12:18 [pve-devel] [PATCH manager 00/10] enable qemu vm architecture selection Dominik Csapak
2026-01-28 12:18 ` [pve-devel] [PATCH manager 01/10] api/pvestatd: broadcast and expose non-x86 host architecture Dominik Csapak
2026-01-28 16:05   ` Fiona Ebner
2026-01-29  9:20     ` Dominik Csapak [this message]
2026-01-28 12:18 ` [pve-devel] [PATCH manager 02/10] ui: resource store: add architecture field Dominik Csapak
2026-01-28 12:18 ` [pve-devel] [PATCH manager 03/10] ui: qemu: add architecture field in wizard and hardware view Dominik Csapak
2026-01-28 16:32   ` Fiona Ebner
2026-01-28 12:18 ` [pve-devel] [PATCH manager 04/10] ui: qemu: make scsi hw selector architecture aware Dominik Csapak
2026-01-28 12:18 ` [pve-devel] [PATCH manager 05/10] ui: qemu: make osdefaults " Dominik Csapak
2026-01-29  9:25   ` Fiona Ebner
2026-01-28 12:18 ` [pve-devel] [PATCH manager 06/10] ui: qemu: make os type selector " Dominik Csapak
2026-01-29  9:41   ` Fiona Ebner
2026-01-29  9:47     ` Dominik Csapak
2026-01-29 12:09       ` Fiona Ebner
2026-01-29 10:18     ` Dominik Csapak
2026-01-29 12:10       ` Fiona Ebner
2026-01-28 12:18 ` [pve-devel] [PATCH manager 07/10] ui: qemu: make machine panels/fields " Dominik Csapak
2026-01-29 11:12   ` Fiona Ebner
2026-01-29 12:16     ` Dominik Csapak
2026-01-29 12:25       ` Fiona Ebner
2026-01-28 12:18 ` [pve-devel] [PATCH manager 08/10] ui: qemu: make bios selector " Dominik Csapak
2026-01-28 12:18 ` [pve-devel] [PATCH manager 09/10] ui: qemu: make sortByPreviousUsage " Dominik Csapak
2026-01-28 12:18 ` [pve-devel] [PATCH manager 10/10] ui: qemu: wizard: use defaults to populate machine and bios Dominik Csapak
2026-01-29 13:13 ` [pve-devel] [PATCH manager 00/10] enable qemu vm architecture selection Fiona Ebner
2026-01-29 13:15   ` Fiona Ebner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f4e92f14-f015-4d44-b430-90c30410511f@proxmox.com \
    --to=d.csapak@proxmox.com \
    --cc=f.ebner@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal