Red Hat Bugzilla – Bug 806256
Linux guest failed in S4 after memory balloon to a small memory
Last modified: 2013-02-18 05:20:55 EST
Description: Boot up a Linux guest with virtio balloon device. Balloon the memory to a small value which is smaller than the 1/3 of total memory. Then do s4 in guest. The s4 will failed with "bash: echo: write error: Cannot allocate memory". If set the memory back to a higher value with balloon. The s4 will succeed. Version-Release number of selected component (if applicable): kernel: 2.6.32-255.el6.x86_64 qemu: qemu-kvm-tools-0.12.1.2-2.255.el6.x86_64 qemu-guest-agent-0.12.1.2-2.255.el6.x86_64 qemu-img-0.12.1.2-2.255.el6.x86_64 qemu-kvm-debuginfo-0.12.1.2-2.255.el6.x86_64 qemu-kvm-0.12.1.2-2.255.el6.x86_64 gpxe-roms-qemu-0.9.7-6.9.el6.noarch How reproducible: always Steps to Reproduce: 1. boot up a rhel 6.3 guest 2. balloon the memory to a value smaller than 1/3 total memory 3. do s4 echo disk > /sys/power/state Actual results: echo report error messgae: "bash: echo: write error: Cannot allocate memory" Expected results: S4 succeed after balloon Additional info: qemu-kvm command line: /root/test/autotest-devel/client/tests/kvm/qemu -name 'vm1' -nodefaults -vga std -chardev socket,id=human_monitor_id_humanmonitor1,path=/tmp/monitor-humanmonitor1-20120322-113143-GwKb,server,nowait -mon chardev=human_monitor_id_humanmonitor1,mode=readline -chardev socket,id=serial_id_20120322-113143-GwKb,path=/tmp/serial-20120322-113143-GwKb,server,nowait -device isa-serial,chardev=serial_id_20120322-113143-GwKb -drive file='/root/test/autotest-devel/client/tests/kvm/images/RHEL-Server-6.3-64-virtio.qcow2',index=0,if=none,id=drive-virtio-disk1,media=disk,cache=none,boot=off,snapshot=off,readonly=off,format=qcow2,aio=native -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk1,id=virtio-disk1 -device virtio-net-pci,netdev=idhfP0Bo,mac=9a:ad:5f:33:1b:d6,id=ndev00idhfP0Bo,bus=pci.0,addr=0x3 -netdev tap,id=idhfP0Bo,ifname='t0-113143-GwKb',script='/root/test/autotest-devel/client/tests/kvm/scripts/qemu-ifup-switch',downscript='no' -m 4096 -smp 2 -cpu 'Opteron_G3' -spice port=8000,disable-ticketing -vga qxl -rtc base=localtime,clock=host,driftfix=slew -M rhel6.3.0 -boot order=cdn,once=c,menu=off -enable-kvm -device virtio-balloon-pci,id=balloon0,bus=pci.0
Looks like the suspend process itself doesn't succeed because it doesn't have enough RAM to go ahead. Why do you think this is a bug? And why in the qemu-kvm component?
As talked with Amit, add the details for this bug and open it again. 1. boot up a rhel 6.3 guest with 10G memory 2. balloon the memory to a value smaller than 1/3 total memory, such as 4G. In the same time don't run any program in guest. The memory used in guest is just 500~600M for a guest with desktop(Make sure there should be enough memory for S4). 3. do s4 echo disk > /sys/power/state At the same time do the same operate in Windows guest or before balloon. It will succeed.
Linux pre-allocates memory for the resume image to be stored. If there's not enough free RAM, that image creation fails. This happens when the image size is going to be more than the available free RAM. What's happening in these examples is that the kernel doesn't have access to enough memory to store its resume image, and hence fails hibernation. The reason to re-open the bug was to check if we were not freeing pages from the balloon driver upon hibernation start. I confirm that's not what's happening. Linux pre-allocates RAM for the resume image, then suspends devices (where we free the RAM in our balloon driver), and then Linux creates the actual resume image. We can't deflate the balloon before this RAM allocation happens (there's no callback for that currently). So closing this again.