Bug 806256

Summary:	Linux guest failed in S4 after memory balloon to a small memory
Product:	Red Hat Enterprise Linux 6	Reporter:	Joy Pu <ypu>
Component:	qemu-kvm	Assignee:	Amit Shah <amit.shah>
Status:	CLOSED WONTFIX	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	high	Docs Contact:
Priority:	medium
Version:	6.3	CC:	acathrow, amit.shah, areis, bsarathy, flang, michen, mkenneth, qzhang, qzhou, rhod, shuang, virt-maint
Target Milestone:	rc	Keywords:	Reopened
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-07-27 10:48:11 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Bug Depends On:
Bug Blocks:	580954, 720669, 761491

Description Joy Pu 2012-03-23 10:28:21 UTC

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

Comment 2 Amit Shah 2012-03-23 10:56:58 UTC

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 11:46:54 UTC

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 10:48:11 UTC

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.