Hi!
Am 08.07.2015 um 16:15 schrieb Timothy Lothering:
Hi Martin,
Thanks for the information.
From the details below, I understand that your Cluster will not allow
additional VMs to be created if 85% of the memory is consumed. This value is
important as you also need to factor in what amount of memory is required by
the Hypervisor (XenServer) to run. Xenserver needs a minimum of 1GB -- Check
out the following link:
http://support.citrix.com/servlet/KbServlet/download/34970-102-704220/installation.pdf.
Correct. On the other host, only 60% is used, so still enough free space
in the cluster. The cluster actually allows new VMs, but tries to start
them on the wrong host.
Secondly, unless you are running memory intensive applications, using a 1:1
ratio is not entirely economically viable, you can safely up the
mem.overprovisioning.factor to 2 or 4 (depending on your Memory over
provisioning calculations vs CPU). This means that you are essentially doubling
or quadrupling up on the actual amount of memory you have available.
We prefer to give our users the full memory they request. XenServer does
no "real" memory overprovisioning, but proportionally scales VMs down if
the hosts real memory is exceeded. Unless there's real dynamic memory
scaling (including swapping, deduplication and pressure sensing), we
prefer to stay at 1:1.
Another option to look at is your deployment.planners.order &
vm.deployment.planner fields. In my case, I use FirstFitPlanner for both as we
prefer to fully utilize each host before provisioning on another host.
That's what I prefer, too.
The problem is not that the algorithm is wrong, but that the data it
bases its decisions on is faulty. So not CloudStack fails to create VM,
but the underlying XenServer.
Ciao
Martin
