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.
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.
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?
This is an automated message. Re-targeting all non-blocker bugs still open on 3.4.0 to 3.4.1.
(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.
(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?
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.
(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.
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.
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.