CPU speed in compute offering is not a MHz speed when using KVM and libvirt.

[correajl]

ISSUE TYPE

• Improvement Request

COMPONENT NAME

Cloudstack management and cloudstack agent. 

CLOUDSTACK VERSION

4.17.0.1

CONFIGURATION

2 management servers, 2 databases, advanced network, everything working fine.

OS / ENVIRONMENT

Ubuntu Server 22.04 LTS, KVM, libvirt 8.0.0-1ubuntu7.1, cgroup2.

SUMMARY

The value "CPU (in MHz)" used by Compute Offerings has nothing to do with the CPU speed when using KVM. The value configured as "CPU (in MHz)" is mapped to "shares" element in the cputune section of libvirt configuration of domain (KVM). This mapping is done using this

int minSpeed = (int)(newServiceOffering.getSpeed() / (divideCpuByOverprovisioning ? cpuOvercommitRatio : 1));

So, if I have a 1000 Mhz value in compute offering and try to launch a VM with 80 CPUs, I will get 80000 configured as 'shares' value. 'Shares' is a relative value that defines how much CPU time a VM will have when compared to others. This description in MHz is very confusing.

The second problem is why is this value required when creating a custom constrained compute offering? Why couldn't we just inform the number of CPUs and memory to limit the ranges that service offering permits? In UI the value is required. Looking at
createServiceOffering API definition the only two required parameters are displaytext and name. But trying to create I have:

~# create serviceoffering name="Custom VM" displaytext="Custom VM" storagetype=shared provisioningtype=fat mincpunumber=2 maxcpunumber=80 minmemory=1000 maxmemory=1000000 offerha=true dynamicscalingenabled=true
Error: (HTTP 431, error code 4350) For creating a custom compute offering min/max cpu and min/max memory/cpu speed should all be null or all specified

My first suggestion is to permit the creation of a compute offering without inform this value. If this is not possible for some reason, so my suggestion is to change the description of this value in some way. For KVM users/admins, this MHz notation is so confusing.

STEPS TO REPRODUCE

In UI the value "CPU (in MHz)" when creating a custom constrained compute offering not to be required. The same when using API.

Or, change the "CPU (in MHz)" to something more representative, that makes more sense.

EXPECTED RESULTS

Do not inform "CPU (in MHz)" or have a better description when using KVM as hypervisor.

ACTUAL RESULTS

Sometimes, depending on the value entered in "CPU (in MHz)" the hypervisor can't launch the instance.

[Hudratronium]

The value "CPU (in MHz)" used by Compute Offerings has nothing to do with the CPU speed when using KVM.

Hmmm... from a technical viewpoint i would say that you are right, as this value won't change the actual CPU frequency at all.
Nevertheless when using / creating offerings which support the CPU cap functionality, you will create a configuration which matches the behaviour of a CPU running on the given frequency from an overall performance point of view.
From my understanding this is what is represented, not the 'phyiscal' realization.

The second problem is why is this value required when creating a custom constrained compute offering?

At least the value is used for finding suitable hosts during the allocation process.
Just think of a situation where one has a host with a 1000MHz CPU and another with 2000MHz CPU. When creating a service offering without the value 'CPU (in MHz)' you could get a VM running on either of the machines. (one could try to work around this with the usage of Host tags... but this could get quiet cumbersome in many ways).
Also without giving a value for frequency, a user would literally not know what to expect when choosing a service offering. One would have to pass this kind of information via the nameing or description of the service offering.

Why couldn't we just inform the number of CPUs and memory to limit the ranges that service offering permits?

That's what the actual user can choose in the GUI. And in addition getting the information what equivalent of performance he will get - through the representation of the CPU Frequency.

My first suggestion is to permit the creation of a compute offering without inform this value.

We have this kind of offering - which is the 'Custome unconstrained'.
Given that you can't constrain the number of cores or memory used (while the limitation here would be the physical capability of availeable hosts - the the user would have to perform either a trial-and-error-deployment or you would need to display the different availeable capabilies of existing hosts).

[weizhouapache]

this looks like a polishing
a better name might be "CPU weight factor"

maybe we can fix it together with #6744

[shwstppr]

@correajl @weizhouapache since we have had an improvement regarding cgroupv2, is this still an issue?