[Lxc-users] Kernel 2.6.33-rc6, 3 bugs container specific.

Jean-Marc Pigeon jmp at safe.ca
Tue Feb 2 01:37:56 UTC 2010


	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:
	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
	   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
	   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 at safe.ca
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">

More information about the lxc-users mailing list