I understand, You could potentially encapsulate all else - except your
VM's in a small cgroup and frequently reclaim from there using the
memory cgroup. If drop caches works for you, that is good too. I am
surprised that cache allocations are causing lowmem exhaustion.
I'm suirprised that LOWMEM
Have you looked at memory cgroups and using that with limits with VMs?
The problem was *NOT* that my VMs exhausted all memory. I know that is
what "normally" triggers oom-killer, but you have to understand this
mine was a very different scenario, hence I wanted to bring it to
people's attenti
echo "-16"> /proc//oom_adj
Thanks for that - yes, I know about "oom_adj", but it doesn't (totally)
work. "udevd" has a default of "-17" and it got killed anyway.
Also, the only thing this server runs is VMs so if they can't be killed
oom-killer will just run through the everything e
I'd go with 64-bit at 2GB and above. It's both faster and safer.
safer, how? (apart from no lowmem exhaust).
On a different subject, the qemu documentation says a guest VM can only
have 2Gb of memory - does this still apply when using a 64bit host O/S ?
The lowmem load is about 0.5% of gues
This is *NOT* a KVM issue, but may be worth adding into the FAQ...
We have a KVM host with 48Gb of RAM and run about 20 KVM clients on it.
After some time - different time depending on the kernel version - the
VM host kernel will start OOM-Killing the VM clients, even when there is
lots of fr
Further to my previous report..
I have just noticed that, where the host is running on the dual
"Quad-Core AMD Opteron(tm) Processor 2352" (family 16, model 2) the
kernels in the *guest* machines (usually 2.6.26) are reporting "WARNING:
This combination of AMDprocessors is not suitable for SMP
Summary - I'm getting stability issues running SMP. The guest will run
for, typically, 6 to 12 hours before causing a problem.
The first time it happened the guest process that was running SMP went
Zombie, but in a spin loop clocking huge amount of CPU time, and I had
to reboot the host to cle