On Sun, Feb 22, 2015 at 11:01 PM, Michal Privoznik <mprivozn@xxxxxxxxxx> wrote: > Just drop the hard_limit. It's a blackbox we should had never > introduced. In Linux, from kernel's POV, there's no difference between > guest RAM and hypervisor memory to store its internal state. It's all > one big chunk of memory. And even if you know the first part (how much > memory you're letting guest to have), you don't know anything about the > other part - how much memory does hypervisor need to store its internal > state (which may even change over the time), therefore you can't tell > the sum of both parts. > > Also, in the config of your VM, you're not using hugepages. Or you've > just posted wrong XML? > > Then again, kernel's approach to hugepages is not as awesome as to > regular system pages. Either on boot (1GB) or at runtime (2MB) one must > cut a slice of memory off to be used by hugepages and nothing else. So > even if you have ~17GB RAM free on both nodes, they are reserved for > hugepages, hence the OOM. Yeah, I dropped the hard limit, and have set <hugepages/>. I had the hard limit set since I had also tried locking the pages in memory... found out that was no bueno too. I also ported numad to Arch Linux [1] and am using placement='auto', which seems to be working reasonably well. I'll keep you posted. Course, this required a custom build of libvirt [2] to get the NUMAD defines set... [1.0] https://aur.archlinux.org/packages/numad-git/ [1.1] https://aur.archlinux.org/packages/numad/ [2] https://github.com/rbellamy/pkgbuilds/tree/master/libvirt-git _______________________________________________ libvirt-users mailing list libvirt-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvirt-users