Bug 1250378

Created attachment 1059690 [details]
error log when the bug duplicate

Are you using '-realtime mlock=on' QEMU parameter?

The host has 8G of memory so two 4G guests will fit only with the help of swap (or KSM).  The log shows that QEMU has no pages in the almost empty 8G swap, which points to the mlock parameter that disables swap for QEMU and allocates all memory on startup.

The memory is allocated and locked in two phases.
The allocation phase works fine because we allow memory overcommit (no pages are allocated at that point), but in the locking phase, there is not enough RAM to fit the second guest and the mlockall sysctl cannot fail because of insufficient memory (Linux is tragic in low-memory situations), so a oom killer pops up and something must die.

QEMU used to say "qemu-kvm: cannot set up guest memory 'pc.ram': Cannot allocate memory" in RHEL 7.0?

(In reply to Radim Krčmář from comment #5)
> Are you using '-realtime mlock=on' QEMU parameter?
> 
> The host has 8G of memory so two 4G guests will fit only with the help of
> swap (or KSM).  The log shows that QEMU has no pages in the almost empty 8G
> swap, which points to the mlock parameter that disables swap for QEMU and
> allocates all memory on startup.
> 
> The memory is allocated and locked in two phases.
> The allocation phase works fine because we allow memory overcommit (no pages
> are allocated at that point), but in the locking phase, there is not enough
> RAM to fit the second guest and the mlockall sysctl cannot fail because of
> insufficient memory (Linux is tragic in low-memory situations), so a oom
> killer pops up and something must die.
> 
> QEMU used to say "qemu-kvm: cannot set up guest memory 'pc.ram': Cannot
> allocate memory" in RHEL 7.0?

yes, i add '-realtime mlock=on' QEMU parameter. without this parameter,two VMs can start successfully.

Now, i have test many times in my side, but can not trigger:"qemu-kvm: cannot set up guest memory 'pc.ram': Cannot allocate memory" now.
And i find, if i echo the score in "/pro/[qemu pid]/oom_adj",the order of the "kill" will be changed. (the one with higher score will be killed first).

command line:
/usr/libexec/qemu-kvm -name test -machine pc,accel=kvm,usb=off,dump-guest-core=on -m 6G -cpu SandyBridge -smp 4,sockets=4,cores=1,threads=1 -no-user-config -nodefaults -monitor stdio -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -global PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot menu=on,strict=on -device pci-bridge,bus=pci.0,id=bridge1,chassis_nr=1,addr=0x5 -device ich9-usb-ehci1,id=usb,bus=bridge1,addr=0x2.0x7 -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=bridge1,multifunction=on,addr=0x2.0x0 -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=bridge1,addr=0x2.0x1 -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=bridge1,addr=0x2.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=bridge1,addr=0x4 -chardev socket,path=/tmp/yfu,server,nowait,id=yfu0 -netdev tap,id=hostnet,vhost=on -device virtio-net-pci,netdev=hostnet,id=net,mac=78:1a:4a:d6:b8:97,bus=bridge1,addr=0x6,bootindex=2 -vnc :1 -vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=33554432 -msg timestamp=on -monitor unix:/home/qmp,server,nowait -serial unix:/tmp/ttyS0,server,nowait -qmp tcp:0:4444,server,nowait -drive file=/root/RHEL-7.2.qcow2,if=none,id=drive-virtio-disk0,format=qcow2,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=0 -S -realtime mlock=on

The memory overcommit behaviour with '-realtime mlock=on' is not perfect, but expected and requires custom configuration, so the admin shouldn't let it happen.  Closing because improving the error case is not worth the effort.