Hello,
Tried 2.6.33-rc6 to check container, 3 bugs show up.
(test done on x86_64, Pentium(R) Dual-Core CPU E5400)
#1: Critical / fixed?:
Already reported: system hang very badly if you start
a container (clone) while cloneflag is set with at least
one of the set:
CLONE_NEWNET|CLONE_NEWIPC|CLONE_NEWNS|CLONE_NEWPID|CLONE_NEWUTS.
Bug is said fixed:
(commit fabf318e5e4bda0aca2b0d617b191884fda62703),
and is somewhere in queue, hopefully will be part of rc7.
#2: Trouble / can be override by sys_admin
arping not working if HOST interface not named
the same as in CONT.
Lets say you set the HOST "eth0" interface to be
"fast" to met whatever your standard are and
rename CONT veth to be eth0 using command:
ip link set vth_name name eth0
(within CONT) to allow very standard CONT template.
directory HOST:/sys/class/net will report
br0 fast lo sit0 'to-vth'
directory CONT:/sys/class/net will report
exactly the same
Problem: file
/etc/sysconfig/network-scripts/ifup-eth
is doing "ip link set dev eth0 up" as
eth0 is the name we want to have in CONT.
So far so good, just after arping is
trying to make sure no one is using the
IP to be set.
and arping is accessing file
/sys/class/net/eth0/broadcast
which doesn't exist --> Network setting hang!.
Fix: when "ip link set vth_name name othername"
is applied, /sys/class/net/ should be updated
by kernel too.
#3: Very critical / CONT can't be production grade.
HOST and CONT share the same kmsg ring buffer.
Some part of the kernel running as CONT
could printk CONT specific message (iptable
packet tracing is a good example) even worse
CONT:rsyslog is reading kmsg too, meaning
it is competing with HOST:rsyslog to get
critical information. So the whole ring buffer
is garbled (not good at all).
My advice is to give a specific "ring buffer"
to each started container. This is the way it
was implemented by the openvz guys (seems to
me a very good solution), other solution would
be to say CONT:/proc/kmsg to be a kind of
device null, but then how kernel will give to
container context, informations on it specific
CONT problem???
My 3 cents.
Seems to me we are very close to have a "production"
container, thanks to all contributor...
--
A bientôt
==========================================================================
Jean-Marc Pigeon Internet: jmp@xxxxxxx
SAFE Inc. Phone: (514) 493-4280
Fax: (514) 493-1946
Clement, 'a kiss solution' to get rid of SPAM (at last)
Clement' Home base <"http://www.clement.safe.ca";>
==========================================================================
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/containers
