Bug 694373 - ballooning value reset to original value after setting a negative number
Summary: ballooning value reset to original value after setting a negative number
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.2
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Amit Shah
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-04-07 07:05 UTC by Mike Cao
Modified: 2012-08-14 06:19 UTC (History)
9 users (show)

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.
Clone Of:
Environment:
Last Closed: 2011-12-06 15:51:46 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:1531 normal SHIPPED_LIVE Moderate: qemu-kvm security, bug fix, and enhancement update 2011-12-06 01:23:30 UTC

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


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