[winterhazel]

Description

This PR is a minimal follow-up to #12190. A few refactorings and adjustments will be done in a separate PR targeting main.

#12190 changed the order in which the KVM Agent retrieves the CPU speed from lscpu, so that CPU max MHz is preferred over the frequency advertised in the model name. However, the host CPU speed is not only informative. It is used to:

• calculate the CPU capacity of the host (cores * speed);
• calculate the CPU quota of VMs that use a compute offering with CPU cap enabled (VM speed / host speed).

CPU max MHz may include the turbo frequency, which the CPU is not able to sustain; thus, it is not a suitable value for these calculations. Besides that, its meaning depends on the cpufreq driver in use: with intel_pstate/amd-pstate it is the turbo frequency, with acpi-cpufreq it is the base frequency plus 1 MHz, and without a cpufreq driver it is not reported at all.

As a consequence, the change impacts existing VMs with CPU cap enabled. Considering a host with a base frequency of 2.9 GHz and a maximum frequency of 4.8 GHz, a VM using a CPU cap enabled offering with 2.9 GHz does not have its CPU time limited. After #12190, once the Agent reconnects and the VM is started or migrated, it is able to use only ~60% of the CPU time, making users feel that the performance of their VMs degraded out of nowhere.

Therefore, this PR:

• restores the previous order of the lscpu checks to the same behavior that existed before Fix lscpu speed checking order #12190;
• exposes the maximum frequency of the CPU as a new host detail (host.cpu.max.speed.mhz), which is returned in the details of the listHosts API and shown in the details of the host in the UI as CPU maximum frequency (turbo). This value is only informative; it is not used in capacity or CPU quota calculations.

Operators that want a host to be registered with a specific CPU speed, such as the turbo frequency, can still do so through the host.cpu.manual.speed.mhz property in agent.properties.

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Enhancement (improves an existing feature and functionality)
• Cleanup (Code refactoring and cleanup, that may add test cases)
• Build/CI
• Test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity

Bug Severity

• BLOCKER
• Critical
• Major
• Minor
• Trivial

Screenshots (if appropriate):

How Has This Been Tested?

I verified that the previous behavior of using the base CPU frequency as the host speed was restored, and that the maximum frequency is now shown in a separate tag in the UI.

[winterhazel]

@blueorangutan package

[blueorangutan]

@winterhazel a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 4.08%. Comparing base (437adc8) to head (5243c52).
⚠️ Report is 29 commits behind head on 4.22.

❗ There is a different number of reports uploaded between BASE (437adc8) and HEAD (5243c52). Click for more details.

HEAD has 1 upload less than BASE

Flag	BASE (437adc8)	HEAD (5243c52)
unittests	1	0

Additional details and impacted files

@@              Coverage Diff              @@
##               4.22   #14383       +/-   ##
=============================================
- Coverage     18.02%    4.08%   -13.94%     
=============================================
  Files          5936      449     -5487     
  Lines        535823    38282   -497541     
  Branches      65612     7083    -58529     
=============================================
- Hits          96572     1564    -95008     
+ Misses       428252    36503   -391749     
+ Partials      10999      215    -10784     

Flag	Coverage Δ
uitests	4.08% <ø> (+0.04%)	⬆️
unittests	?

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[blueorangutan]

Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 19514

[Damans227]

approved by mistake earlier, ignore that one. will look again once tests are in.

[winterhazel]

@blueorangutan package

[blueorangutan]

@winterhazel a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.

[blueorangutan]

Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 19693

[nvazquez]

@blueorangutan test

[blueorangutan]

@nvazquez a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests

[sureshanaparti]

clgtm

[vladimirpetrov]

@blueorangutan package

[blueorangutan]

@vladimirpetrov a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.

[Damans227]

thanks @winterhazel, tests and the new max speed tag look right. CLGTM

[blueorangutan]

Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 19706