Bug 1032446 - [oVirt][webadmin] No indication of free memory for VMs on host [NEEDINFO]
[oVirt][webadmin] No indication of free memory for VMs on host
Status: CLOSED EOL
Product: ovirt-engine
Classification: oVirt
Component: Frontend.WebAdmin (Show other bugs)
---
Unspecified Unspecified
unspecified Severity unspecified (vote)
: ovirt-3.6.0-rc
: 3.6.0
Assigned To: Doron Fediuck
bugs@ovirt.org
sla
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-20 03:47 EST by Mike Kolesnik
Modified: 2016-02-10 14:19 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-10-02 06:48:35 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: SLA
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
sbonazzo: needinfo? (mkolesni)
ylavi: ovirt‑3.6.0?
ylavi: planning_ack?
ylavi: devel_ack?
ylavi: testing_ack?


Attachments (Terms of Use)
Host with not enought memory (88.64 KB, image/png)
2013-11-20 03:47 EST, Mike Kolesnik
no flags Details

  None (edit)
Description Mike Kolesnik 2013-11-20 03:47:44 EST
Created attachment 826468 [details]
Host with not enought memory

Description of problem:
When host is committed to a certain amount of memory, it's not possible to see how much of the host's memory is committed.
This causes confusion as to the reason why the host can't run a VM.


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


How reproducible:
Always


Steps to Reproduce:
1. Run a couple of VMs on a host
2. Look at the hosts tab
3.

Actual results:
The host's free memory seems quite low, although the committed memory is much higher.


Expected results:
There should be some indication (maybe another color on the bar) showing the committed memory.


Additional info:
Please see attached screenshot for the host which has supposedly 38% memory usage, but actually 0MB left for new VMs to run.

Additionally, it is not very clear as to how the "Resource allocation" of memory in the VM definition affects this behavior, as a user of the system it was not trivial that it is related to the VM scheduling and allows over commitment of memory on a host since the VM might not use up all it's allotted memory.
Comment 1 Itamar Heim 2014-01-12 03:42:39 EST
setting target release to current version for consideration and review. please do not push non-RFE bugs to an undefined target release to make sure bugs are reviewed for relevancy, fix, closure, etc.
Comment 2 Doron Fediuck 2014-01-20 07:58:28 EST
Checking this with the UX team;
Einav, we need a UX advice on this issue. Please read the report and then the attached. Indeed both figures are right, so how would you advice to handle it?
Comment 3 Sandro Bonazzola 2014-03-04 04:28:15 EST
This is an automated message.
Re-targeting all non-blocker bugs still open on 3.4.0 to 3.4.1.
Comment 4 Einav Cohen 2014-03-31 10:37:32 EDT
(In reply to Doron Fediuck from comment #2)
> Checking this with the UX team;
> Einav, we need a UX advice on this issue. Please read the report and then
> the attached. Indeed both figures are right, so how would you advice to
> handle it?

apologies for the extremely late response. 

unfortunately, I am not sure what all of the relevant numbers mean;
what is "committed memory"?
what is "Max free memory for scheduling new VMs"? is that a configured value? a statistic?

I think that a very detailed example (or two) will help out here. 
e.g.:
"""
let's say we have a host with 16GB memory, 4 VMs running on it.
VM1 is using 3 GB, out of which 1 GB is shared with all other VMs.
VM2 is using 3 GB, out of which 1 GB is shared with all other VMs.
VM3 is using 3 GB, out of which 1 GB is shared with all other VMs.
VM4 is using 3 GB, out of which 1 GB is shared with all other VMs.
so VMs are actually utilizing 12 GB total, however they are actually utilizing only 9GB out of the Host's RAM (2*4 GB per VM + 1GB that is shared across all VMs), so the Host's committed (???) memory is actually 9GB. 
the Host's actual used memory is 8GB, since the VMs are not really fully utilizing their allocated RAM. 
running VMs on this Host can theoretically utilize up to 24 GB total, since the Host is configured with 150% memory over-commitment. 
In order to run a new VM, the Host must have at least x GB of non-committed memory. 'x' is a configurable (???) value. 
non-committed memory is not the same as free memory. 
non-committed memory = total memory - committed memory = 16GB - 9GB = 7GB. 
free memory = total memory - used memory = 16GB - 8GB = 8GB != 7GB. 
...
"""

any chance that you can provide that?
[I would suggest to even write an oVirt wiki-page on that]
once we will know what all the numbers mean, we will be able to think of a proper way to display this information. 

thanks.
Comment 5 Doron Fediuck 2014-04-06 08:44:16 EDT
(In reply to Einav Cohen from comment #4)
> (In reply to Doron Fediuck from comment #2)
> > Checking this with the UX team;
> > Einav, we need a UX advice on this issue. Please read the report and then
> > the attached. Indeed both figures are right, so how would you advice to
> > handle it?
> 
> apologies for the extremely late response. 
> 
> unfortunately, I am not sure what all of the relevant numbers mean;
> what is "committed memory"?
> what is "Max free memory for scheduling new VMs"? is that a configured
> value? a statistic?
> 
> I think that a very detailed example (or two) will help out here. 

> 
> any chance that you can provide that?
> [I would suggest to even write an oVirt wiki-page on that]
> once we will know what all the numbers mean, we will be able to think of a
> proper way to display this information. 
> 

It could be that we're over-engineering it. I know reality is more than
just a number, but eventually, we need to decide what does memory load
represent and if we can or cannot add VMs into this host.

So the question is if we can make sure the load expresses capacity, so
the user will get an indication on how many VMs he can squeeze in?
Comment 6 Sandro Bonazzola 2014-05-08 09:55:55 EDT
This is an automated message.

oVirt 3.4.1 has been released.
This issue has been retargeted to 3.5.0 since it has not been marked as high priority or severity issue, please retarget if needed.
Comment 7 Einav Cohen 2014-09-30 09:12:52 EDT
(In reply to Doron Fediuck from comment #5)
> (In reply to Einav Cohen from comment #4)
> > (In reply to Doron Fediuck from comment #2)
> > > Checking this with the UX team;
> > > Einav, we need a UX advice on this issue. Please read the report and then
> > > the attached. Indeed both figures are right, so how would you advice to
> > > handle it?
> > 
> > apologies for the extremely late response. 
> > 
> > unfortunately, I am not sure what all of the relevant numbers mean;
> > what is "committed memory"?
> > what is "Max free memory for scheduling new VMs"? is that a configured
> > value? a statistic?
> > 
> > I think that a very detailed example (or two) will help out here. 
> 
> > 
> > any chance that you can provide that?
> > [I would suggest to even write an oVirt wiki-page on that]
> > once we will know what all the numbers mean, we will be able to think of a
> > proper way to display this information. 
> > 
> 
> It could be that we're over-engineering it. I know reality is more than
> just a number, but eventually, we need to decide what does memory load
> represent and if we can or cannot add VMs into this host.
> 
> So the question is if we can make sure the load expresses capacity, so
> the user will get an indication on how many VMs he can squeeze in?

yes - if we are limiting ourselves to a single number, this number should probably reflect something that will hint the user regarding whether more VMs can be squeezed into this Host or not. This is probably what interests the user the most. 

for the longer term, we should probably not limit ourselves to a single number - we should provide all of the relevant memory-related information (maybe using a bar filled with different colors or similar) - but in a way that will still allow the user to very-easily comprehend whether more VMs can be squeezed into this Host or not.
Comment 8 Sandro Bonazzola 2015-09-04 05:01:16 EDT
This is an automated message.
This Bugzilla report has been opened on a version which is not maintained anymore.
Please check if this bug is still relevant in oVirt 3.5.4.
If it's not relevant anymore, please close it (you may use EOL or CURRENT RELEASE resolution)
If it's an RFE please update the version to 4.0 if still relevant.
Comment 9 Sandro Bonazzola 2015-10-02 06:48:35 EDT
This is an automated message.
This Bugzilla report has been opened on a version which is not maintained
anymore.
Please check if this bug is still relevant in oVirt 3.5.4 and reopen if still
an issue.

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