Il 02/03/2015 17:31, David Vrabel ha scritto:
On 02/03/15 16:23, Jan Beulich wrote:
On 02.03.15 at 16:52, <fabio.fant...@m2r.biz> wrote:
On systems with wheezy as dom0 and kernel 3.2 it seems there are no
visible problems.
After updating the kernel to 3.16 (from backports repository), after
starting the domUs, I get many of these errors in syslog and kern.log
(infinite loop):
xen:balloon: Cannot add additional memory (-17)
I have a vague recollection of some fix from David aiming at
avoiding to issue this message, but you would clearly have better
luck getting a qualified response if you Cc-ed kernel people when
reporting kernel problems (assuming you need explicit Cc-s at all,
as most relevant people read the list anyway afaik) - I certainly
can't figure by what criteria you put together the Cc list.
You need
3dcf63677d4eb7fdfc13290c8558c301d2588fe8 (xen/balloon: cancel ballooning
if adding new memory failed)
fd8b79511349efd1f0decea920f61b93acb34a75 (xen/balloon: Don't continue
ballooning when BP_ECANCELED is encountered)
Or you can disable CONFIG_XEN_BALLOON_MEMORY_HOTPLUG.
David
Readded the other part of my initial mail that explain better the
problem (also with the patch above applied)...
The strange thing is that it should not use balloning because both dom0
and domUs have fixed memory set and balloning disabled.
dom0 from grub.cfg: dom0_mem=2G,max:2G
vi /etc/xen/xl.conf: autoballoon=0
domUs xl cfg: memory parameter only, for example memory=2048
Why it seems to try to use balloning even if everything is set with a
fixed amount of memory?
Could it be a regression in recent kernels or a problem already present
for some time but only now showing in logs?
I've been suggested by one developer in the mailing list to use this
workaround for now to avoid at least the problem of oversized logs:
dom0 from grub.cfg: dom0_mem=2G,max:3G
After latest kernel update (3.16.7-ckt4-3~bpo70+1) with this addition:
[xen] cancel ballooning if adding new memory failed (Closes: #776448)
I removed the workaround and retried.
With xen-unstable (4.6 - actual master) it reports only one balloning
error for each domU after start, *whereas with xen 4.5.0 and actual
stable-4.5 I still have continuous errors about failed balloning.* E.g.
after starting one W7 domU syslog grew by 20 mb in only 3-4 minutes.
I think there is some important fix about memory that still have to be
backported to 4.5-stable (probably in libxl about domU's create).
Even though I can't observe anything wrong besides errors in logs, if
there is something wrong in memory calculation and/or use of balloning I
think it should be found and solved.
Someone can take a look at these please?
Thanks for any reply and sorry for my bad english.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
