Re: [bisected] balloon driver broken in 3.12+ after save+restore

["Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3612 bytes --]

On 22.05.2014 03:31, Marek Marczykowski-Górecki wrote:
> 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?

Anyone?

> 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'
> ---
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 


-- 
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 #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 538 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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