Sorry for the so late reply.
These days I looked into the code again and found it's my setting not
1. You opinion about reserved_mem is right.
2. Yes, pending_vmem_size is 0 before the 84th runs.
3. memory_over_commit is where my problem is.
In webadmin UI, I set the cluster's memory optimization
to none, thus memory_over_commit is 100 in DB(the dafault value is 100
in my env).
when I set the cluster's mem_opt to 'for server load',
memory_over_commit grows to 150
and when I set to 'for desktop load', memory_over_commit grows to 200.
Both 'for server load' and 'for desktop load' have let the vdsMemLimit
thus the 84th vm managed to run.
So I realized the memory optimization option in cluster is for KSM function.
2012/10/24 Doron Fediuck <dfediuck(a)redhat.com>:
----- Original Message -----
> From: "ly pan" <plysab(a)gmail.com>
> To: engine-devel(a)ovirt.org
> Sent: Thursday, October 18, 2012 2:43:35 PM
> Subject: [Engine-devel] Question about hasMemoryToRunVM() in RunVmCommandBase
> This is my test environment:
> hardware: Dell PowerEdge 2710 ,Memory 48G
> Software: OVirt engine 3.0 ,VDSM 4.9.4 ,kernel
> I create 100 vms from pool(each vm has 512M memory and has
> 1M memory garanteed, with guest_overhead = 65 and reserved_mem =
> but only 83 vms
> turn out to run. When I run the 84th vm, engine says there is not
> enough memory. However at this time KSM is enabled and 15G free
> is still left on the host.
> I checked the code and found out that before running a vm, the
> function hasMemoryToRunVM() in RunVmCommandBase would decide whether
> there is enough memory in the selected host to run it.
> The Algorithm in the function is like this:
> mem_avaliable >= mem_required = curVds.getmem_commited() +
> + curVds.getguest_overhead() + curVds.getreserved_mem() +
> And here is my question: curVds.getmem_commited() is caculated from
> the memory of vm
> assigned by user. But when the host is running with KSM enabled, the
> actual memory of each
> running vm would be smaller than the memory the user assigned to. In
> this case, the following
> may occur: engine says there be no more memroy to run any vm while
> host has much free
> space to run more vms(in my case, 15G).
> Therefore I think the actual memory size reported by vdsm(The KSM
> shared memory) should be taken into account when calculating
> curVds.getmem_commited(). Any ideas are welcome.
Sorry for the delay. I'd like to look into this issue.
In the meanwhile a few relevant points;
1. You're saying that reserved_mem=256. This is not accurate, since it's
reported by vds as host_mem_reserve(256) + extra_mem_reserve(65) = 321
2. I'm assuming you retried running the 84th vm, just to make sure your
pending_vmem_size is 0 once all 83 VMs are running.
3. So assuming (2) is correct, I'd like to ask what's the
you have for the cluster? By default it's set to 120, and in such a case the 84th
VM should still be running.
Here's a calculation sample based on your data, and the above 3 issues:
83 * (512M+65) = 47,891
47,321.1328125 // reported by vdsm: 'cat /proc/meminfo | grep MemTotal' / 1024
So vdsCurrentMem <= vdsMemLimit should be true unless you changed something
such as the MemTotal or the memory_over_commit. You can try and change
let us know how it works.