[pve-devel] [RFC manager 3/6] Broadcast supported CPU flags and allow 'cluster' CPU type

Fabian Grünbichler f.gruenbichler at proxmox.com
Tue Jul 30 14:00:24 CEST 2019


On Wed, Jul 17, 2019 at 03:03:45PM +0200, Stefan Reiter wrote:
> pvestatd will read supported CPU flags once on startup (since these
> most likely never change during runtime), then broadcasts them as a
> key-value pair to the cluster.

I don't think this is true - at least according to the Qemu docs:

> The data returned by this command may be affected by:
> 
> • QEMU version: CPU models may look different depending on the QEMU
> version. (Except for CPU models reported as "static" in
> query-cpu-definitions.)

'host' is obviously not a static CPU type, so the definition of and
supported CPU flags possible change when upgrading Qemu.

> Also add the 'cluster' CPU type to be selectable in the GUI.

as discussed off-list, this is probably too confusing (what is a cluster
CPU? when does it change? how does it change? ...), and we'd prefer
re-using parts of this series to:
- easily derive a "cluster-baseline" set of CPU flags
- add a new mechanism to define custom CPU definitions (either by taking
  the current cluster-baseline, or creating a custom one from scratch)

this avoids the whole "cluster" CPU type can change its meaning
depending on cluster member additions/removals, microcode/software/...
upgrades, etc.pp., while still allowing an easy way to create a
"highest-performing CPU type for the current cluster configuration" that
can then be used in multiple VMs.

> Signed-off-by: Stefan Reiter <s.reiter at proxmox.com>
> ---
>  PVE/Service/pvestatd.pm               | 11 +++++++++--
>  www/manager6/form/CPUModelSelector.js |  4 ++--
>  2 files changed, 11 insertions(+), 4 deletions(-)
> 
> diff --git a/PVE/Service/pvestatd.pm b/PVE/Service/pvestatd.pm
> index e138b2e8..35f02066 100755
> --- a/PVE/Service/pvestatd.pm
> +++ b/PVE/Service/pvestatd.pm
> @@ -47,12 +47,16 @@ my $cmdline = [$0, @ARGV];
>  my %daemon_options = (restart_on_error => 5, stop_wait_time => 5);
>  my $daemon = __PACKAGE__->new('pvestatd', $cmdline, %daemon_options);
>  
> +my $supported_cpuflags = '';
> +
>  sub init {
>      my ($self) = @_;
>  
>      $opt_debug = $self->{debug};
>  
>      PVE::Cluster::cfs_update();
> +
> +    $supported_cpuflags = PVE::QemuServer::query_supported_cpu_flags();

this needs to be eval {}

see above, this would need to be done more often (but probably not too
often, because of the associated costs). a qemu-server update would
already trigger this AFAICT, since it will reload-or-try-restart
pvestatd via pve-api-updates. but pve-qemu-kvm updates don't activate
this trigger - they are rare enough, maybe we should add it?

also, it would be nice to detect a regression here - i.e., if we already
have a state, and the query now returns nothing/an error, we should at
least warn, or maybe not overwrite the old status..

>  }
>  
>  sub shutdown {
> @@ -91,7 +95,10 @@ sub update_node_status {
>  
>      my $cpuinfo = PVE::ProcFSTools::read_cpuinfo();
>  
> -    my $maxcpu = $cpuinfo->{cpus}; 
> +    my $maxcpu = $cpuinfo->{cpus};
> +
> +    my $flag_string = join(" ", @$supported_cpuflags);
> +    PVE::Cluster::broadcast_node_kv("cpuflags", $flag_string);

the list to string stuff could be done in one go with retrieving the
list, instead of here for every pvestatd update cycle.

>  
>      my $subinfo = PVE::INotify::read_file('subscription');
>      my $sublevel = $subinfo->{level} || '';
> @@ -104,7 +111,7 @@ sub update_node_status {
>  	$netin += $netdev->{$dev}->{receive};
>  	$netout += $netdev->{$dev}->{transmit};
>      }
> - 
> +
>      my $meminfo = PVE::ProcFSTools::read_meminfo();
>  
>      my $dinfo = df('/', 1);     # output is bytes
> diff --git a/www/manager6/form/CPUModelSelector.js b/www/manager6/form/CPUModelSelector.js
> index 9eb5b0e9..7a2b572f 100644
> --- a/www/manager6/form/CPUModelSelector.js
> +++ b/www/manager6/form/CPUModelSelector.js
> @@ -32,7 +32,7 @@ Ext.define('PVE.form.CPUModelSelector', {
>  	['Opteron_G4', 'Opteron_G4'],
>  	['Opteron_G5', 'Opteron_G5'],
>  	['EPYC', 'EPYC'],
> -	['host', 'host']
> -
> +	['host', 'host'],
> +	['cluster', 'cluster']
>      ]
>  });
> -- 
> 2.20.1
> 
> 
> _______________________________________________
> pve-devel mailing list
> pve-devel at pve.proxmox.com
> https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel




More information about the pve-devel mailing list