Bug 814072
Summary: | Guest memory sometimes reduces to a small number after balloon mem to a large negative value | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Qunfang Zhang <qzhang> |
Component: | qemu-kvm | Assignee: | Amit Shah <amit.shah> |
Status: | CLOSED WONTFIX | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 6.3 | CC: | acathrow, amit.shah, bcao, bsarathy, dyasny, juzhang, lcapitulino, mdeng, michen, mkenneth, tburke, virt-maint, ypu |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-05-02 16:24:33 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Qunfang Zhang
2012-04-19 07:33:26 UTC
For rhel guest, there's a strange behaviours like below, after the memory continuously reduce to 312M, it comes back to 1974M some seconds later. and then I do 'balloon 2048', no response. (qemu) balloon -10000000000000111 Parameter 'target' expects a size (qemu) balloon -100000000000001111114334234 (qemu) info balloon balloon: actual=457 (qemu) (qemu) info balloon balloon: actual=416 (qemu) info balloon balloon: actual=402 (qemu) info balloon balloon: actual=378 (qemu) info balloon balloon: actual=359 (qemu) info balloon (qemu) info balloon balloon: actual=312 (qemu) (qemu) info balloon balloon: actual=312 (qemu) info balloon balloon: actual=1974 (qemu) (qemu) info balloon balloon: actual=1974 (qemu) balloon 2048 (qemu) info balloon balloon: actual=1974 (qemu) Tested RHEL6.2 release host, the issue exists too. Luiz, does qmp's int handling need some bounds-checking here? See hw/balloon.c, function qmp_balloon(). It gets an int64_t. Look at the values given in comment #2. Looks strange what is happening in the first 6 lines. Amit, you're mostly right. There are three points to be considered: 1. Yes, there's a bug. But it's in HMP. HMP is not supported and this kind of issue should _always_ be tested against QMP 2. I tested QMP a bit, it seems to do the right thing. I'd appreciate if QE could confirm this 3. The fact that the guest (or is it the host?) continuously reduces its memory seems to be a different issue. Here, a balloon value of -100000000000001111114334234 will turn into 1048576 when passed to qmp_ballon(). This means that the guest memory is being reduced to 1M. The side effects this will cause are unrelated to HMP's bug, and this is probably what is causing the "continuous memory reduction" effect I'll fix HMP bug usptream, but as HMP is not supported in RHEL I'd close this as NOTABUG. Unless you want to investigate item 3... (In reply to comment #5) > Amit, you're mostly right. There are three points to be considered: > > 1. Yes, there's a bug. But it's in HMP. HMP is not supported and this kind of > issue should _always_ be tested against QMP OK, I assumed they would use the same code path. Apparently not. > 2. I tested QMP a bit, it seems to do the right thing. I'd appreciate if QE > could confirm this Qunfang, please test with the QMP interface. > 3. The fact that the guest (or is it the host?) continuously reduces its memory > seems to be a different issue. Here, a balloon value of > -100000000000001111114334234 will turn into 1048576 when passed to > qmp_ballon(). This means that the guest memory is being reduced to 1M. The side > effects this will cause are unrelated to HMP's bug, and this is probably what > is causing the "continuous memory reduction" effect I should've been clearer: I wanted your input only on the monitor interaction. However, thanks for noting this here too. > I'll fix HMP bug usptream, but as HMP is not supported in RHEL I'd close this > as NOTABUG. Unless you want to investigate item 3... It's difficult for the guest to do much if its mem gets reduced below acceptable levels; can't do much in that case. I'll leave the bug open till QE can confirm QMP works fine in their testing. Thank you, Luiz. (In reply to comment #6) > (In reply to comment #5) > > Amit, you're mostly right. There are three points to be considered: > > > > 1. Yes, there's a bug. But it's in HMP. HMP is not supported and this kind of > > issue should _always_ be tested against QMP > > OK, I assumed they would use the same code path. Apparently not. > > > 2. I tested QMP a bit, it seems to do the right thing. I'd appreciate if QE > > could confirm this > > Qunfang, please test with the QMP interface. > Sorry for reply late, retest with QMP interface and can not set a negative value with QMP: Boot with the same command line in bug description: {"execute":"query-balloon"} {"return": {"actual": 2147483648}} {"execute":"balloon","arguments":{"value":"-1048576000"}} {"error": {"class": "InvalidParameterType", "desc": "Invalid parameter type, expected: int", "data": {"name": "value", "expected": "int"}}} {"execute":"balloon","arguments":{"value":"-10485760000000000000"}} {"error": {"class": "InvalidParameterType", "desc": "Invalid parameter type, expected: int", "data": {"name": "value", "expected": "int"}}} {"execute":"query-balloon"} {"return": {"actual": 2147483648}} {"execute":"balloon","arguments":{"value":"-104857600000001165087824133750784"}} {"error": {"class": "InvalidParameterType", "desc": "Invalid parameter type, expected: int", "data": {"name": "value", "expected": "int"}}} *(This value is the one that hit the HMP issue, but can not hit it with QMP)* {"execute":"query-balloon"} {"return": {"actual": 2147483648}} As stated in the last comments, this issue only affects HMP which is not supported by RHEL. Closing as WONTFIX. *** Bug 843360 has been marked as a duplicate of this bug. *** |