Github user rafaelweingartner commented on the issue:

    https://github.com/apache/cloudstack/pull/1918
  
    @jayakarteek from what I understood so far, there will always be a mismatch.
    
    For instance, the way it is implemented so far, if a VM uses a service 
offering that provides 1000 MHz; and if CPU cap is not used, it (the VM) can 
use up to the real CPU of the host. If real CPU on the host is 2000 MHz, then 
it would show 200% of usage. Unless we want this behavior, the use of 
CPUCounter seems a better approach to avoid having an inconsistent POJO in the 
code. You said it might not be ideal because the CPUCounter (per its 
documentation) does not seem to consider the amount of virtual CPU allocated in 
MHz while calculating usage, right?
    
    I just started this discussion because of the POJO that has an attribute 
that sometimes is set using percentage values and some other as continuous 
values. My goal was to highlight this and maybe discuss some solution.
    
    I was reading the documentation link you sent, what are the differences 
between “cpuentitlement” and “reservedCapacity”; I mean, I can read the 
description of the parameters 
    
    >  cpuentitlement is computed based on an ideal scenario in which all 
virtual machines are completely busy and the load is perfectly balanced across 
all hosts
    
    but the description for me seems different from what I can understand from 
"entitlement" when I read "CPU entitlement" I think of CPU power that the CPU 
is entitled and may not be using or getting for one or other reason. However, 
the description may sound like something else (this value being based on the 
load of hosts/clusters). 
    
     Would not one of these two configurations have the CPU in MHz allocated 
for the VM?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Reply via email to