Attached is a patch to make Xend balloon down an additional 8MB (for the
Cirrus logic video device) when doing a restore or migrate. Without this, you
can run into the following situation:
1) Start an HVM guest up on machine1
2) Boot up machine2, making sure dom0 has *all* of available memory
3) Migrate (off-line or live) from machine1 to machine2
4) Have the video device setup fail, with the following in the qemu-dm log
Failed allocation for dom 3: 2048 extents of order 0
The problem ends up being that if dom0 has all of memory, the restore on the
target side only balloons down exactly enough for the memory of the migrating
domain; it doesn't take into account the additional memory needed for the device
model. So the "populate_physmap" that happens as part of video device setup
fails with out-of-memory, causing the failure above.
Note that it could be argued that this additional ballooning should be done from
QEMU, since it knows better than anyone how much memory it is going to need.
However, all of the logic for ballooning is currently contained in xend, so it
seems like a more appropriate place to put it.
The patch is against 3.1.0, but should apply fairly easily to xen-unstable.
Signed-off-by: Chris Lalancette <clalance@xxxxxxxxxx>
--- xen-3.1.0-src/tools/python/xen/xend/XendCheckpoint.py.orig 2007-08-24
+++ xen-3.1.0-src/tools/python/xen/xend/XendCheckpoint.py 2007-08-24
@@ -178,6 +178,10 @@ def restore(xd, fd, paused=False):
log.info("restore hvm domain %d, apic=%d, pae=%d",
dominfo.domid, apic, pae)
+ # for an HVM guest, we actually need an additional 2048 pages (8MB)
+ # for the qemu device model; add that here
+ nr_pfns += 2048
apic = 0
pae = 0
Xen-devel mailing list