Hudratronium commented on issue #6743: URL: https://github.com/apache/cloudstack/issues/6743#issuecomment-1251080080
> 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). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
