Bug 806256 - Linux guest failed in S4 after memory balloon to a small memory
Linux guest failed in S4 after memory balloon to a small memory
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
Unspecified Unspecified
medium Severity high
: rc
: ---
Assigned To: Amit Shah
Virtualization Bugs
: Reopened
Depends On:
Blocks: 580954 720669 761491
  Show dependency treegraph
Reported: 2012-03-23 06:28 EDT by Joy Pu
Modified: 2013-02-18 05:20 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-07-27 06:48:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Joy Pu 2012-03-23 06:28:21 EDT
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):

How reproducible:

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
Comment 2 Amit Shah 2012-03-23 06:56:58 EDT
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?
Comment 6 Joy Pu 2012-03-26 07:46:54 EDT
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.
Comment 8 Amit Shah 2012-07-27 06:48:11 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.