Bug 694373

Summary:	ballooning value reset to original value after setting a negative number
Product:	Red Hat Enterprise Linux 6	Reporter:	Mike Cao <bcao>
Component:	qemu-kvm	Assignee:	Amit Shah <amit.shah>
Status:	CLOSED ERRATA	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.2	CC:	bcao, ehabkost, flang, juzhang, michen, mkenneth, qzhang, rhod, virt-maint
Target Milestone:	rc	Keywords:	Reopened
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	qemu-kvm-0.12.1.2-2.179.el6	Doc Type:	Bug Fix
Doc Text:	A negative balloon value was seen to be a very high positive value by the code. The very high value was then topped off to the max ram the guest was started with, resulting in deflating the balloon entirely. The fix is to check for negative input and flag that as an error.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-12-06 15:51:46 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Mike Cao 2011-04-07 07:05:37 UTC

Description of problem:
start a guest with -m 4G -device virtio-ballon-pci,id=balloon0, whenever set the ballooning to a negative number ,it always turns to 4096

Version-Release number of selected component (if applicable):
rpm -q qemu-kvm
qemu-kvm-0.12.1.2-2.156.el6.x86_64
[root@localhost /]# rpm -q kernel
kernel-2.6.32-128.el6.x86_64


How reproducible:
100%

Steps to Reproduce:
1.start guest with  -m 4G -device virtio-ballon-pci,id=balllon0
2.(qemu)balloon 3000
3.(qemu)info balloon
   3000  ( this is right )
4.(qemu)balloon -1024
  
Actual results:
(qemu)info balloon
4096

Expected results:
balloon value should keep the previous value
(qemu)info balloon
3000

Additional info:

Comment 2 RHEL Program Management 2011-04-07 07:23:44 UTC

Since RHEL 6.1 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

Comment 5 Vadim Rozenfeld 2011-06-02 15:19:18 UTC

Hello Mike,

Who was the quest in this case?

Best regards,
Vadim.

Comment 6 Mike Cao 2011-06-03 03:03:10 UTC

(In reply to comment #5)
> Hello Mike,
> 
> Who was the quest in this case?

Hi, Vadim

I found the issue myself when doing ballooning functional test .
Is there anything wrong or unsuitable to test it ?

> 
> Best regards,
> Vadim.

Comment 7 Vadim Rozenfeld 2011-06-03 17:14:43 UTC

(In reply to comment #6)
> (In reply to comment #5)
> > Hello Mike,
> > 
> > Who was the quest in this case?
> 
> Hi, Vadim
> 
> I found the issue myself when doing ballooning functional test .
> Is there anything wrong or unsuitable to test it ?
> 
Hi Mike,
Testing is always good. 
I'm just trying to figure out
on which host did it happen to you.
Was it also RHEL5.7 64 bit guest,
just like in case of https://bugzilla.redhat.com/show_bug.cgi?id=694378

Best regards,
Vadim.

Comment 8 Mike Cao 2011-06-04 14:43:13 UTC

(In reply to comment #7) 
> Hi Mike,
> Testing is always good. 
> I'm just trying to figure out
> on which host did it happen to you.
> Was it also RHEL5.7 64 bit guest,
> just like in case of https://bugzilla.redhat.com/show_bug.cgi?id=694378
> 
Hi,Vadim

I check the history of QE's test run .both Bug 694378 and this one were using 
RHEL5.6 64 bit guest .

I also tried on RHEL5.7 64 bit guest ,still can hit the issue.

> Best regards,
> Vadim.

Comment 9 Amit Shah 2011-07-20 08:49:38 UTC

A negative balloon value is seen to be a very high positive value by the code (the input is supposed to be in MB, and is an unsigned value).  So what happens is the very high value is topped off to the max ram the guest was started with (4G in your case), and that value is then used to balloon.  It's supposed to work this way, not something that's fixable or even an error.

Will close this, please re-open if you think otherwise.

Comment 10 Ronen Hod 2011-07-20 11:02:59 UTC

Well, an end user, would never deliberately use -1024 for max RAM. I think that he deserves an error message.
Still closing it for 5.8 is the right thing to do, since there is no crash, and the feature works for positive numbers.
Mike, if the bug exists also in 6.2, please report it.

Comment 11 Amit Shah 2011-07-28 06:19:27 UTC

OK, I revisited the code and looks like we do accept an int as the size param (instead of unsigned int, as I had assumed).  So this is solvable in the balloon driver, patch posted upstream.

Comment 16 Qunfang Zhang 2011-08-31 10:13:11 UTC

Verified on qemu-kvm-0.12.1.2-2.184.el6, balloon value can not be set to negative number or zero any more for both RHEL and Windows guests.

(qemu) balloon 0
Parameter 'target' expects a size
(qemu) balloon -1
Parameter 'target' expects a size
(qemu) balloon -10000
Parameter 'target' expects a size
(qemu) 
(qemu) balloon 2000
(qemu) info balloon 
balloon: actual=2000
(qemu) 

So, this bug is fixed.

Comment 18 Amit Shah 2011-11-18 08:41:25 UTC

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
A negative balloon value was seen to be a very high positive value by the code.  The very high value was then topped off to the max ram the guest was started with, resulting in deflating the balloon entirely.  The fix is to check for negative input and flag that as an error.

Comment 19 errata-xmlrpc 2011-12-06 15:51:46 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2011-1531.html