[Openstack-operators] RamFilter: stopped instances are accounted too ?

Alexander Rubtsov arubtsov at mirantis.com
Mon Dec 17 18:37:39 UTC 2012

Hi, Brano

Far as I know stopped instance will always start on the same node. And in
order to it started on different node need using migration.

On Mon, Dec 17, 2012 at 7:24 PM, Brano Zarnovican <zarnovican at gmail.com>wrote:

> Hi,
> I have noticed the following problem, but I'm not sure if it's bug or
> feature ;)
> Scheduler is calculating available ram per node by taking total ram
> amount and then subtracting memory for every non-deleted instance
> associated to that compute node. That's all fine if all of them are
> running. Then the result roughly corresponds with reality.
> https://github.com/openstack/nova/blob/stable/essex/nova/scheduler/host_manager.py#L301
> But if, say,  50% of instances are stopped most of the time, they are
> still accounted for used ram for that compute node. RamFilter will
> prevent you to create more instances there..
> Is operator supposed to set over-commit in this case ?
> It seems that resources are allocated to instance at creation and they
> are "locked" during the whole lifecycle. One might expect that stopped
> instances would be disassociated with the compute node to free up the
> resources. Resources would be then allocated again on next
> start-instance, potentially on different compute node. Or is it just
> my misunderstanding of cloudiness ?
> Regards,
> Brano Zarnovican
> PS: We are running Essex 2012.1.3
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20121217/48b26fd3/attachment.html>

More information about the OpenStack-operators mailing list