Bug 680198
Summary: | the guest kernel will panic when ballooning memory | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Alex Jia <ajia> | ||||||
Component: | libvirt | Assignee: | Daniel Veillard <veillard> | ||||||
Status: | CLOSED CANTFIX | QA Contact: | Virtualization Bugs <virt-bugs> | ||||||
Severity: | high | Docs Contact: | |||||||
Priority: | high | ||||||||
Version: | 6.1 | CC: | berrange, dyuan, eblake, jdenemar, jyang, llim, xen-maint, yoyzhang | ||||||
Target Milestone: | rc | ||||||||
Target Release: | --- | ||||||||
Hardware: | x86_64 | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2011-02-28 09:38:03 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: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 693510 | ||||||||
Attachments: |
|
Description
Alex Jia
2011-02-24 16:18:15 UTC
Created attachment 480795 [details]
virtio_balloon driver
Created attachment 480796 [details]
guest screen
That's the dark side of memory ballooning. If you want to shrink too much your guest may get into an OOM condition and start killing processes like crazy. Frankly, decreasing memory from 2GB to 128MB really sounds like too much to me. It's hard to find a general rule what amount of memory is still ok and what is already not enough for a guest so I don't think we can really do anything useful with this in libvirt. The user (of libvirt API, so it can even be an application higher in the stack) should know what the guest OS is, what processes need to run in it and what the memory consumption should look like. I'm inclined to close this as CANTFIX although I'll wait a bit in case someone else has a better suggestion. Agreed, we have tried to set a minimum limit in the past, but had to remove it precisely because it will always be wrong for at least one person's valid use case. |