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
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 ***