Bug 483529
Summary: | virt-manager can't increase memory allocation for Dom0 host | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Karel Volný <kvolny> |
Component: | virt-manager | Assignee: | Cole Robinson <crobinso> |
Status: | CLOSED DUPLICATE | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | 5.3 | CC: | clalance, syeghiay, xen-maint |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2009-02-13 19:33:51 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
Karel Volný
2009-02-02 08:15:45 UTC
If you go to the command-line and do "xm mem-set 0 10000" (the last number can be as big as you want; it will only balloon as much as it can), does the memory get returned to dom0? Chris Lalancette wov, thanks for the command, it saves me having to restart the machine, as I get the memory back ;-) ... but still I consider quite an issue that it does not work automagically (and that the GUI does not allow to do that despite the fact it pretends so) after starting/stopping one virtual guest, at the host I tried: [root@dhcp-lab-227 ~]# free total used free shared buffers cached Mem: 1499136 1483200 15936 0 4988 319748 -/+ buffers/cache: 1158464 340672 Swap: 2096472 204 2096268 [root@dhcp-lab-227 ~]# xm mem-set 0 10000 [root@dhcp-lab-227 ~]# free total used free shared buffers cached Mem: 1785468 1485576 299892 0 5456 321588 -/+ buffers/cache: 1158532 626936 Swap: 2096472 204 2096268 (well, where are those ~300 MiB remaining to 2 GiB?) The fact that it doesn't automatically give memory back to the dom0 is a design decision. The idea is that if you are running Xen in the first place, in all likelihood you are running guests. So there isn't much point in shutting down a guest, ballooning dom0 up, then starting a new guest, and ballooning dom0 down again. So the only problem left here is that virt-manager can't be used at present to balloon dom0 back up. That should probably work; I'll re-assign this bug to virt-manager. Chris Lalancette (In reply to comment #3) > The fact that it doesn't automatically give memory back to the dom0 is a > design decision. The idea is that if you are running Xen in the first > place, in all likelihood you are running guests. So there isn't much point > in shutting down a guest, ballooning dom0 up, then starting a new guest, and > ballooning dom0 down again. thanks for the explanation; I am virtualization newbie but it seems quite unfortunate to me - if the memory would be reused for another guest, it would make much more sense ... but if I have three machines configured, and run just two of them simultaneously at most, for example, then running the graphical desktop on 2 GiB - 3*512 MiB - some magic number = 430 MiB is very uncomfortable (read: the machine is swapping constantly and some operations take ages) the "all likehood" is probably true for Server installations, but as there is also the Client branch, couldn't we just have two different behaviours? (ok, this probably isn't the right place to discuss ...) virt-manager has the ability to change dom0 allocation, my guess is you are hitting a regression pointed out in bug 484314. *** This bug has been marked as a duplicate of bug 484314 *** |