Bug 843621 - engine-setup does not complete if RAM = 2GB
Summary: engine-setup does not complete if RAM = 2GB
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-installer
Version: 3.1 RC
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
: 3.3
Assignee: Ofer Schreiber
QA Contact:
URL:
Whiteboard: integration
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-07-26 18:58 UTC by Cybertimber2011
Modified: 2013-09-23 07:35 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-09-23 07:35:34 UTC
oVirt Team: ---
Embargoed:


Attachments (Terms of Use)

Description Cybertimber2011 2012-07-26 18:58:25 UTC
Component should be ovirt-engine-setup but I don't see that option in the components list.

Description of problem:
engine-setup does not complete if the system RAM equals 2GB (2048MB). The exception from the log, and the error posted on the console, is "the minimum requirement is 2GB and the recommended is 4GB".

Version-Release number of selected component (if applicable):
ovirt-engine 3.1.0-1.fc17
ovirt-engine-setup-3.1.0-1.fc17

How reproducible:
Always unless physical RAM >= 2095MB

Steps to Reproduce:
1. Have system with 2048 of RAM (Virtual Machine, physical)
2. Add oVirt 3.1 repo
3. Install ovirt-engine and related packages
4. Run engine-setup
  
Actual results:
engine-setup exits with "Error: not enough available memory on the Host. The minimum requirement is 2GB and the recommended is 4GB"

Expected results:
On a system with 2GB (2048MB) of RAM, the install should complete since it technically meets the minimum requirement.

Additional info:
ovirt 3.0 also exibits the same problem.

I'm wondering though if the error message just needs clarification, or the check needs reworking. Looking over /bin/engine-setup, I see that engine-setup checks by using the "free -g" command, and I'm guessing for total memory rather than available.

Using the "-g" option (IMO) leaves little flexibility in rounding, etc. I bumped the system up incrementally up to 2070MB of RAM and it still displayed 1GB of ram total to "free -g".  That said, "free -m" at 2070MB of ram showed 2023 under total. 
System at 2071MB ram, free -m reports "2024", free -g reports "1".
System at 2080MB ram, free -m reports "2033", free -g reports "1".
System at 2095MB ram, free -m reports "2048", free -g reports "2". and engine-setup runs successfully.

I have no idea where the other 47MB of RAM is going (12 to video? virtualbox default) but in a physical system you wouldn't be able to add memory like that. 
Can we add some flexibility for when the system allocates (or misreports?) available RAM?

Comment 1 Amador Pahim 2012-08-07 20:23:47 UTC
Same issue here. Patch sent:
http://gerrit.ovirt.org/6992

Comment 2 Cybertimber2011 2012-08-08 15:48:42 UTC
Thanks for working on that. I think this should make it a lot easier to avoid that error now.

Comment 3 Amador Pahim 2012-08-20 12:24:58 UTC
Thank you for reporting.

Comment 5 Cybertimber2011 2013-02-03 21:20:23 UTC
This doesn't seem to have made it into 3.2 (or if it did, it's not working). Any chance this can make it?

Comment 6 Itamar Heim 2013-02-04 08:05:27 UTC
the way i read the patch, it will allow installing on a machine with 0.95*2048MB of free memory, not available memory.
i think the request here is to allow installing on a machine with 2048-128 (say, video card) MB of installed memory, not available memory.

Comment 7 Amador Pahim 2013-02-04 12:37:37 UTC
availableMemory variable has the installed memory value.

http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=packaging/fedora/setup/engine-setup.py#l2176

Take my system as example:

>>> print output
             total       used       free     shared    buffers     cached
Mem:          3881       3666        214          0          0       1928
-/+ buffers/cache:       1738       2143
Swap:         3887        300       3587

>>> for line in output.split("\n"):
...     result = re.match("Mem:\s+(\d+)\s+.+", line)
...     if result:
...         availableMemory = result.group(1)
... 
>>> print availableMemory
3881

Comment 8 Alex Lourie 2013-02-04 16:27:56 UTC
Definitely included in the 3.2.

If there is any issue with it, please let us know.

Comment 9 Cybertimber2011 2013-02-04 16:32:04 UTC
My apologies, I thought I only had the beta repo enabled, so when I ran "yum install ovirt-engine", it installed 3.1 from the Fedora repo and I didn't catch it until I went to the mailing list.

Now that I have ovirt-engine-3.2 installed, I'll do some further testing. So far looks good but free -g did return 2GB so moot point. I'll shortly change to ~2000MB and see what happens.

Comment 10 Eyal Edri 2013-03-27 15:51:26 UTC
when using a virtual machine to install ovirt, and specifying 4096MB as memory,
setup will fail currently since the actual memory on host is less (~3800).

so it should at least allow installing on a system with 3800.

Comment 11 Cybertimber2011 2013-03-28 00:49:49 UTC
3800 isn't enough based on the patch. 3800 = 92.7% of 4096. Amador made it 95%.
What's taking up almost 300MB (almost 10%) of your allocated RAM? What does "free -m" return?

Comment 12 Eyal Edri 2013-03-28 09:26:08 UTC
here is the vm output: (defined in engine as 4096mb)

free -m
             total       used       free     shared    buffers     cached
Mem:          3831       3329        502          0        294       1261
-/+ buffers/cache:       1773       2057
Swap:        15999         29      15970

i would assume the delta is taken by qemu? for virt purposes? 
but i can't tell for sure.

Comment 13 Amador Pahim 2013-03-28 18:33:33 UTC
iirc 4096 is the warning limit. fail limit is 2048.

Comment 14 Eyal Edri 2013-03-28 18:37:43 UTC
changed after patch merged: http://gerrit.ovirt.org/#/c/13201/

Comment 15 Amador Pahim 2013-03-28 19:30:48 UTC
big jump btw. 5% was supposed to be enough to most of the cases. New 4096MB limit is raising tolerance up to ~204MB, a considerable value imo. It's not a strong opinion, but I think we shouldn't bite the limit more than we currently do. And manual basedefs change is always possible for those who aren't able to meet the requirements.

Comment 16 Itamar Heim 2013-08-21 16:42:39 UTC
as RC is built, moving to ON_QA (hopefully did not catch incorrect bugs when doing this)

Comment 17 Cybertimber2011 2013-08-22 00:07:51 UTC
Some feedback on this, based on 3.3 RC1.
Looks good! The minimum RAM changed to 4096 (as Amador said), but the installer prompts the user with the minimum and recommended values, and asks if you want to install with less. Nice touch!

Comment 18 Itamar Heim 2013-09-23 07:35:34 UTC
closing as this should be in 3.3 (doing so in bulk, so may be incorrect)


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