Bug 220504 - [RHEL5] Xen restore tries to balloon to "maxmem" if specified in the config file
[RHEL5] Xen restore tries to balloon to "maxmem" if specified in the config file
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xen (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Rik van Riel
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-12-21 15:10 EST by Chris Lalancette
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version: RHEA-2007-0635
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-07 12:09:01 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)
patch for RHEL5 to make restoring a ballooned domain work (13.33 KB, patch)
2007-01-19 11:11 EST, Rik van Riel
no flags Details | Diff

  None (edit)
Description Chris Lalancette 2006-12-21 15:10:52 EST
Description of problem:
Now that we have proper memory ballooning working, I have been testing it out by
setting "maxmem" in my config files.  For instance:

maxmem = "1024"
memory = "256"

This works fine on boot; the domU balloons down dom0 appropriately and starts
with 256MB of memory.

However, when doing a save/restore, we run into a problem.  In the restore path,
the tools attempt to balloon down dom0 to "maxmem", not "memory".  The problem
here is that on a 1024MB HV, for instance, I can successfully start 3 domU's
with 256MB (leaving 256MB for dom0); but then I cannot successfully save and
then restore one or more of them, since there is not enough memory to make it
back up to maxmem.
Comment 1 Rik van Riel 2007-01-16 15:45:28 EST
Upstream changeset to fix this issue:

http://xenbits2.xensource.com/xen-unstable.hg?rev/895d873a00b4

I'll try to merge this into our RHEL5 tree.
Comment 2 Rik van Riel 2007-01-19 11:11:31 EST
Created attachment 145997 [details]
patch for RHEL5 to make restoring a ballooned domain work

I have tested this patch on my system and it seems to allow restoring a saved
domain that has been ballooned down.  I am ready to commit this whenever we
feel it is appropriate to get this fix in.
Comment 3 RHEL Product and Program Management 2007-03-21 19:13:39 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 5 Daniel Berrange 2007-06-15 16:19:09 EDT
This fix was picked up in the rebase to 3.1.0  libxc. The xen-3.0.3-27.el5 build
in dist-5E-qu-candidate has the fix.

To test create a domain with

  $ grep mem /etc/xen/demo
  memory=300
  maxmem=500

Start it with 

  $ virsh start demo
  $ virsh dominfo demo | grep mem
  Max memory:     512000 kB
  Used memory:    307064 kB

Save it

  $virsh save demo /var/lib/xen/demo.save

Restore it

  $ virsh restore /var/lib/xen/demo.save

And check memory usage 

  $ virsh dominfo demo | grep mem
  Max memory:     512000 kB
  Used memory:    307064 kB

Comment 6 Chris Lalancette 2007-06-15 16:31:10 EDT
It's a little more complicated than that.  Here is the test case where I
originally saw it:

1.  Machine with 1G of memory.
2.  Start up domU-1 with mem=256M, maxmem=768M
3.  Start up domU-2 with mem=512M
4.  Now, "xm save domU-1"; everything is cool
5.  Now, "xm restore domU-1"; the domain fails to start because the scripts are
trying to balloon back up to 768M first

Note that if you shut down domU-2, then try to do the restore of domU-1, things
are cool; domU-1 starts, and then automatically balloons itself back to 256M. 
So it's just a problem with the tools allocating too much memory initially.

Note that this very well may be fixed by the -27 package; we just need to
confirm properly.

Chris Lalancette
Comment 9 errata-xmlrpc 2007-11-07 12:09:01 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2007-0635.html

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