Bug 483529 - virt-manager can't increase memory allocation for Dom0 host
virt-manager can't increase memory allocation for Dom0 host
Status: CLOSED DUPLICATE of bug 484314
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: virt-manager (Show other bugs)
5.3
All Linux
low Severity medium
: rc
: ---
Assigned To: Cole Robinson
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-02 03:15 EST by Karel Volný
Modified: 2009-12-14 16:18 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-02-13 14:33:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Karel Volný 2009-02-02 03:15:45 EST
Description of problem:
After starting some virtual guests, parts of the memory are taken away from the host for those guests. After shutting down the guests, the memory is not returned to the host.

In addition, not just that it isn't done automatically, but starting virt-manager, displaying Domain-0 Details => Hardware => Memory, increasing allocation back to the amount corresponding to the physical RAM and applying the changes does nothing, the available memory does not increase.

Version-Release number of selected component (if applicable):
xen-3.0.3-80.el5
kernel-xen-2.6.18-128.el5virttest3

How reproducible:
always

Steps to Reproduce:
1. create and run some virtual guests
2. shutdown the virtual guests
3. free
  
Actual results:
(on a machine with 2 GiB of physical RAM with 3 guests, each has 512 MB RAM, the first and then the second were started, then the first was shut down and the third was started, then the third was shut down and then the second was shut down)

[root@dhcp-lab-227 rhel]# free
             total       used       free     shared    buffers     cached
Mem:        432128     414192      17936          0       3532      84000
-/+ buffers/cache:     326660     105468
Swap:      2096472    1033384    1063088


Expected results:
[root@dhcp-lab-227 rhel]# free
             total       used       free     shared    buffers     cached
Mem:       2094080     414192    1679888          0       3532      84000
...


Additional info:
the physical hardware is Dell Precision 490
Comment 1 Chris Lalancette 2009-02-02 04:30:43 EST
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
Comment 2 Karel Volný 2009-02-02 05:00:13 EST
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?)
Comment 3 Chris Lalancette 2009-02-02 05:06:06 EST
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
Comment 4 Karel Volný 2009-02-02 06:46:14 EST
(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 ...)
Comment 5 Cole Robinson 2009-02-13 14:33:51 EST
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 ***

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