Bug 1122150 - Over allocation ratio reporting different numbers in Admin Portal and REST API
Summary: Over allocation ratio reporting different numbers in Admin Portal and REST API
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-restapi
Version: 3.4.0
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
: 3.5.0
Assignee: Tal Nisan
QA Contact: Shai Revivo
URL:
Whiteboard: storage
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-22 16:05 UTC by wdaniel
Modified: 2019-04-28 10:42 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-07-23 06:08:45 UTC
oVirt Team: Storage
Target Upstream Version:


Attachments (Terms of Use)

Description wdaniel 2014-07-22 16:05:42 UTC
Description of problem:

Currently when the customer looks in the Admin Portal he notices a negative over-allocation ratio for his storage domains. For example:

Size:
300 GB
Available:
91 GB
Used:
209 GB
Allocated:
250 GB
Over Allocation Ratio: -17%
(copied from the Admin Portal)

However, querying the API, we see these numbers:

size = (not in curl output) = 300GB
available = 97710505984 bytes = 97.71GB
used = 224412041216 bytes = 224.41GB
committed = 268435456000 bytes = 268.43GB

And the math shows

(250-209)/91 = .4505 = 45.05%


Version-Release number of selected component (if applicable):

rhevm-3.4.0-0.21.el6ev.noarch
rhevm-restapi-3.4.0-0.21.el6ev.noarch
rhevm-webadmin-portal-3.4.0-0.21.el6ev.noarch

How reproducible:

Loaded in a test environment with customer database this issue can be seen, but I'm not sure how it could be replicated

Actual results:

Admin Portal: -17%
REST API: 45%

Expected results:

Matching values from API and Admin Portal

Comment 4 Allon Mureinik 2014-07-23 06:08:45 UTC
wdaniel, your calculation is wrong.

First, your calculations are performed in GiB (1000^3) and not in GB (1024^3).
So a correct conversion would be:

size = (not in curl output) = 300GB
available = 97710505984 bytes = 91GB
used = 224412041216 bytes = 209GB
committed = 268435456000 bytes = 250GB

So, as you can see, the numbers in REST API match the numbers in the UI.

Second, over-allocation is defined as [(allocated / available) - 1] * 100%.
[(209 / 250) - 1] * 100% = -16.4%

So aside from a minor round discrepancy, there's no issue here.


Note You need to log in before you can comment on or make changes to this bug.