[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