Re: [Users] Problem checkpointing VE with AUFS root
Hi, Junjiro from AUFS solves my problem. He gave a patch to apply in my kernel sources. After the compilation, I tested checkpointing and retore a VE with AUFS root and everthing works. Attached, the patch for who wants to use AUFS and OpenVZ. On Fri, May 22, 2009 at 12:07:05AM -0300, Josiney de Souza wrote: Hi, Recently, I started to use OpenVZ. My goal is run some VE's with a remote root, mounted with AUFS and each branch of AUFS is a NFS from a server. My problem is: I can't checkpoint a VE with AUFS root. Every time that I try it, I receive the follow output: --- r...@vcg:~# r...@vcg:~# vzctl chkpnt 104 dumpfile dump.104 Setting up checkpoint... suspend... dump... Can not dump container: Invalid argument Error: pg-mapping!=f_mapping: 08048000 c0c37b60 dfaa9e84 43824 Error: dump_one_vma: funkey page Checkpointing failed r...@vcg:~# --- My system is Debian Lenny and vzctl package version is 3.0.23-1dso1. I build my kernel from 2.6.27 sources, following steps in AUFS page and applying the kernel patch 2.6.27-briullov.1-combined . Checkpointing from a local filesystem root (ReiserFS) or NFS filesystem root works, but not from AUFS root. Anyone has a hint what is wrong? -- Josiney de Souza C3SL: http://www.c3sl.ufpr.br Trans Falls: http://www.transfalls.com.br ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users -- Josiney de Souza C3SL: http://www.c3sl.ufpr.br Trans Falls: http://www.transfalls.com.br a.patch.bz2 Description: Binary data ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users
[Users] vzctl start yields err=-12
I am having a problem creating and starting a new VE. vzctl start gives me: mounted, container start failed, unmounting. dmesg shows only this: CT: 30: stopped CT: 30: failed to start with err=-12 The verbose log (level 10) is no more useful to me: Starting container ... Running: /usr/sbin/vzquota show 30 Running: /usr/sbin/vzquota on 30 -r 0 -b 104857700 -B 104857700 -i 2100 -I 2100 -e 0 -n 0 -s 0 Mounting root: /vz/root/30 /vz/private/30 Container is mounted Set iptables mask 0x17bf Set features mask / Container start failed Running: /usr/sbin/vzquota stat 30 -f Running: vzquota setlimit 30 -b 104857600 -B 104857600 -i 2000 -I 2000 -e 0 -n 0 Running: /usr/sbin/vzquota stat 30 -f Running: /usr/sbin/vzquota off 30 Container is unmounted It can't possibly be a RAM shortage. This hardware has 24 GB physical, and only 9 is allocated amongst the other VEs. There are presently 8 VEs, and this would make 9 if it would start. Any thoughts on how I can debug this? -- HostGIS, Open Source solutions for the global GIS community Greg Allensworth - SysAdmin, Programmer, GIS Person, Security Network+ Server+ A+ Security+ ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users
Re: [Users] vzctl start yields err=-12
Hi Greg, I ran into this problem when building my own ovz kernel, and have since noted some distro's stock kernels have this issue as well. This seems to be a symptom of a known bug tied to the kernel scheduling. http://forum.openvz.org/index.php?t=msggoto=27142; To fix this issue, recompile your kernel with this option commented out: #CONFIG_FAIR_USER_SCHED #CONFIG_FAIR_GROUP_SCHED GMSI - Gemini Microsystems John Knight | Systems Engineer jkni...@geminimicro.com | (706) 255-9203 On Tue, May 26, 2009 at 6:47 PM, Gregor at HostGIS gre...@hostgis.comwrote: I am having a problem creating and starting a new VE. vzctl start gives me: mounted, container start failed, unmounting. dmesg shows only this: CT: 30: stopped CT: 30: failed to start with err=-12 The verbose log (level 10) is no more useful to me: Starting container ... Running: /usr/sbin/vzquota show 30 Running: /usr/sbin/vzquota on 30 -r 0 -b 104857700 -B 104857700 -i 2100 -I 2100 -e 0 -n 0 -s 0 Mounting root: /vz/root/30 /vz/private/30 Container is mounted Set iptables mask 0x17bf Set features mask / Container start failed Running: /usr/sbin/vzquota stat 30 -f Running: vzquota setlimit 30 -b 104857600 -B 104857600 -i 2000 -I 2000 -e 0 -n 0 Running: /usr/sbin/vzquota stat 30 -f Running: /usr/sbin/vzquota off 30 Container is unmounted It can't possibly be a RAM shortage. This hardware has 24 GB physical, and only 9 is allocated amongst the other VEs. There are presently 8 VEs, and this would make 9 if it would start. Any thoughts on how I can debug this? -- HostGIS, Open Source solutions for the global GIS community Greg Allensworth - SysAdmin, Programmer, GIS Person, Security Network+ Server+ A+ Security+ ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users
Re: [Users] vzctl start yields err=-12
John Knight wrote: To fix this issue, recompile your kernel with this option commented out: #CONFIG_FAIR_USER_SCHED #CONFIG_FAIR_GROUP_SCHED Thanks a lot for the same-day response, John. I think I can use this tonight on one of our test systems. -- HostGIS, Open Source solutions for the global GIS community Greg Allensworth - SysAdmin, Programmer, GIS Person, Security Network+ Server+ A+ Security+ ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users
Re: [Users] vzctl start yields err=-12
I'm honestly not exactly sure of the reason. When I ran into the -12 error problem you're experiencing, I was applying the ovz dostoevsky patch to vanilla centos 5.2, salgix 5.0.4 and debian unstable (both with debian's stock 2.6.26 kernel and a vanilla 2.6.26 kernel). I never received the kernel errors in openvz Bug 802 either but tried the change mentioned in the bug report in the kernel build files and it worked for me. The problem seems to exist due to an inability in openvz (at least the dostoevsky, it may be fixed in later releases) to utilise the fair scheduling kernel profile in linux. GMSI - Gemini Microsystems John Knight | Systems Engineer jkni...@geminimicro.com | (706) 255-9203 On Tue, May 26, 2009 at 9:12 PM, Gregor at HostGIS gre...@hostgis.comwrote: A question: This problem I'm getting of err=-12 is not accompanied by the noisy kernel dumps mentioned. Does this still sound like a likely cause? Also, I see that the bug was not fixed: http://bugzilla.openvz.org/show_bug.cgi?id=802 The last entry was that it worked for the person reporting it, but in 009.1 which I just downloaded, CONFIG_FAIR_GROUP_SCHED=y If this option must be turned off to avoid this bug, should it be disabled from the distributed config ? -- HostGIS, Open Source solutions for the global GIS community Greg Allensworth - SysAdmin, Programmer, GIS Person, Security Network+ Server+ A+ Security+ ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users
