----- 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
Hi:
This is my test environment:
hardware: Dell PowerEdge 2710 ,Memory 48G
Software: OVirt engine 3.0 ,VDSM 4.9.4 ,kernel
2.6.32-279.2.1.el6.x86_64
I create 100 vms from pool(each vm has 512M memory and has
1M memory garanteed, with guest_overhead = 65 and reserved_mem =
256),
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
memory
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.getpending_vmem_size()
+ curVds.getguest_overhead() + curVds.getreserved_mem() +
vm.getMinAllocatedMem();
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
the
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.
Hi Ly,
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
max_vds_memory_over_commit
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:
vdsCurrentMem =
83 * (512M+65) = 47,891
0
65
321
1
=======
48,278
vdsMemLimit =
120/100
*
47,321.1328125 // reported by vdsm: 'cat /proc/meminfo | grep MemTotal' / 1024
=========
56,785.359375
So vdsCurrentMem <= vdsMemLimit should be true unless you changed something
such as the MemTotal or the memory_over_commit. You can try and change memory_over_commit
let us know how it works.
Doron