[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] balloon driver broken in 3.12+ after save+restore



Hi,

I have a problem with balloon driver after/during restoring a saved domain.
There are two symptoms:
1. When domain was 'xl mem-set <some size smaller than initial>' just before
save, it still needs initial memory size to restore. Details below.

2. Restored domain sometimes (most of the time) do not want to balloon down.
For example when the domain has 3300MB and I mem-set it to 2800MB, nothing
changes immediately (only "target" in sysfs) - both 'xl list' and 'free'
inside reports the same size (and plenty of free memory in the VM). After some
time it get ballooned down to ~3000, still not 2800. I haven't found any
pattern here.

Both of above was working perfectly in 3.11.

I'm running Xen 4.1.6.1.

Details for the first problem:
Preparation:
I start the VM as in config at the end of email (memory=400, maxmem=4000),
wait some time, then 'xl mem-set' to size just about really used memory (about
200MB in most cases). Then 'sleep 1' and 'xl save'.
When I want to restore that domain, I get initial config file, replace memory
setting with size used in 'xl mem-set' above and call 'xl restore' providing
that config. It fails with this error:
---
Loading new save file /var/run/qubes/current-savefile (new xl fmt info
0x0/0x0/849)
 Savefile contains xl domain config
xc: detail: xc_domain_restore start: p2m_size = fa800
xc: detail: Failed allocation for dom 51: 1024 extents of order 0
xc: error: Failed to allocate memory for batch.!: Internal error
xc: detail: Restore exit with rc=1
libxl: error: libxl_dom.c:313:libxl__domain_restore_common restoring domain:
Resource temporarily unavailable
cannot (re-)build domain: -3
libxl: error: libxl.c:713:libxl_domain_destroy non-existant domain 51
---
When memory set back to 400 (or slightly lower, like 380) - restore succeeded,
but still the second problem is happening.

I've bisected the first problem down to this commit:
commit cd9151e26d31048b2b5e00fd02e110e07d2200c9
    xen/balloon: set a mapping for ballooned out pages

I've checked that the problem still exists in v3.14.4.

Any idea how to fix this?

The domain config:
---
kernel="/var/lib/qubes/vm-kernels/3.12.18-1/vmlinuz"
ramdisk="/var/lib/qubes/vm-kernels/3.12.18-1/initramfs"
extra="ro nomodeset console=hvc0 rd_NO_PLYMOUTH nopat"
root="/dev/mapper/dmroot"
tsc_mode = 2

memory = 400
maxmem = 4000
name = "fedora-20-x64-dvm"

disk = [
'script:snapshot:/var/lib/qubes/vm-templates/fedora-20-x64/root.img:/var/lib/qubes/vm-templates/fedora-20-x64/root-cow.img,xvda,r',
         
'script:file:/var/lib/qubes/appvms/fedora-20-x64-dvm/private.img,xvdb,w',

'script:file:/var/lib/qubes/appvms/fedora-20-x64-dvm/volatile.img,xvdc,w',
         'script:file:/var/lib/qubes/vm-kernels/3.12.18-1/modules.img,xvdd,r',
       ]

vif = [
'mac=00:16:3E:5E:6C:02,script=/etc/xen/scripts/vif-route-qubes,ip=10.137.2.4,backend=firewallvm'
]

pci = [  ]

vcpus = 1

on_poweroff = 'destroy'
on_reboot   = 'destroy'
on_crash    = 'destroy'
---

-- 
Best Regards,
Marek Marczykowski-GÃrecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.