In Nova, "ram_allocation_ratio" & "reserved_host_memory_mb" are not mutually exclusive options, so they work together [0].

If it make sense or not to use "ram_allocation_ratio != 1" when "reserved memory != 0" is up to the cloud admin (depending on your use case, the purpose of your cloud, the underlying hypervisor you're using, etc...)

Cheers,
Luis

[0] https://github.com/openstack/nova/blob/master/nova/scheduler/filters/ram_filter.py#L53

On 11/28/2014 12:50 PM, mad Engineer wrote:
Excellent answer thank you sir.
One doubt comes into my mind is for this reservation to work RAM over
committing should be disabled?
ie ram_allocation_ratio=1
Thanks for your help


On Thu, Nov 27, 2014 at 7:20 PM, Luis Fernandez Alvarez
<[email protected]> wrote:
Hi,

In general, you can see 'reserved_host_memory_mb' as your estimation of how
much memory your hypervisor needs. From the point of view of Nova, your
system is consuming the amount you set in 'reserved_host_memory_mb' [0].

Then, the field 'free_ram_mb' (the one that is checked when VMs are being
scheduled) is calculated using the memory consumed by the instances and the
value of reserved memory [1].

Said that, the scheduler won't see the real free mem (700Mb in your case),
it will see the calculated value. I would suggest you take a look to the
value of "free_ram_mb" on your hypervisor (the value in the database: like
"nova hypervisor-show", not the one in the compute logs), and then... you
compare. If you're expection 700Mb and you see 900Mb, you should tweak a bit
more your 1024Mb or reserved memory and increase it.

It's a bit difficult to follow the flow in the code, but these links are
quite useful to understand how it works.

[0]
https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L695
https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L708
[1]
https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L532



On 11/27/2014 01:55 PM, mad Engineer wrote:
it reports "Free ram (MB): 425"
but free -m has different result.

Is it working for you.Are you using icehouse

On Thu, Nov 27, 2014 at 6:16 PM, George Mihaiescu <[email protected]>
wrote:
Then I would enable debug and verbose in nova.conf and restart the
scheduler
service. In this way you should see in the logs the entire scheduler
logic
and what resources it thinks your host has.

On 27 Nov 2014 06:20, "mad Engineer" <[email protected]> wrote:
George,
                overcommit of RAM is 1  and that is working.However
instances are still getting created with available free memory <
reserved_host_memory_mb

On Thu, Nov 27, 2014 at 4:33 PM, George Mihaiescu <[email protected]>
wrote:
Depending on your overcommit ratio, the scheduler can schedule
instances
using more virtual memory than the available physical memory on the
host,
700 MB in your case.

On 27 Nov 2014 05:36, "mad Engineer" <[email protected]> wrote:
hi all i have set
reserved_host_memory_mb in nova.conf of controller and compute and
restarted necessary services.
i am expecting scheduler to not pickup host that has less than what is
reserved_host_memory_mb
in my example i put reserved_host_memory_mb = 1024
and free RAM in compute node is 700 Mb.
But still scheduler chooses this host and created a new instance on
it.I
am expecting scheduler to show "No valid Hosts found" as it has less
ram
than reserved_host_memory_mb = 1024

Can some one help me understand this value

Thanks

_______________________________________________
Mailing list:
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to     : [email protected]
Unsubscribe :
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

_______________________________________________
Mailing list:
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to     : [email protected]
Unsubscribe :
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to     : [email protected]
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack


_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to     : [email protected]
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Reply via email to