[lxc-devel] How does the console work in most recent release?

[Daniel Lezcano]

On 01/05/2011 08:53 AM, Rob Landley wrote:
> On 01/04/2011 06:52 AM, Daniel Lezcano wrote:
>> On 01/04/2011 09:36 AM, Rob Landley wrote:
>>> I'm attempting to write a simple HOWTO for setting up a container with
>>> LXC. Unfortunately, console handling is really really brittle and the
>>> only way I've gotten it to work is kind of unpleasant to document.
>>>
>>> Using lxc 0.7.3 (both in debian sid and built from source myself), I
>>> can lxc-create a container, and when I run lxc-start it launches init
>>> in the container. But the console is screwy.
>>>
>>> If my init program is just a command shell, the first key I type will
>>> crash lxc-start with an I/O error. (Wrapping said shell with a script
>>> to redirect stdin/stdout/stderr to various /dev character devices
>>> doesn't seem to improve matters.)
>>>
>>> Using the busybox template and the busybox-i686 binary off of
>>> busybox.net, it runs init and connects to the various tty devices, and
>>> this somehow prevents lxc-start from crashing. But if I "press enter
>>> to active this console" like it says, the resulting shell prompt is
>>> completely unusable. If I'm running from an actual TTY device, then
>>> some of the keys I type go to the container and some don't. If my
>>> console is connected to a PTY when I run lxc-start (such as if I ssh
>>> in and run lxc-start from the ssh session), _none_ of the characters I
>>> type go to the shell prompt.
>>>
>>> To get a usable shell prompt in the container, what I have to do is
>>> lxc-start in one window, ssh into the server to get a fresh terminal,
>>> and then run lxc-console in that second terminal. That's the only
>>> magic sequence I've found so far that works.
>>
>> Hmm, right. I was able to reproduce the problem.
>
> I've got two more.  (Here's another half-finished documentation file, 
> attached, which may help with the reproduction sequence.)
>
> I'm running a KVM instance to host the containers, and I've fed it an 
> e1000 interface as eth0 with the normal -net user, and a tun/tap 
> device on eth1 with 192.168.254.1 associated at the other end.
>
> Inside KVM, I'm using this config to set up a container:
>
>   lxc.utsname = busybox
>   lxc.network.type = phys
>   lxc.network.flags = up
>   lxc.network.link = eth1
>   #lxc.network.name = eth0
>
> And going:
>
>   lxc-start -n busybox -f busybox.conf -t busybox
>
> Using that (last line of the config intentionally commented out for 
> the moment) I get an eth1 in the container that is indeed the eth1 on 
> the host system (which is a tun/tap device I fed to kvm as a second 
> e1000 device).  That's the non-bug behavior.
>
> Bug #1: If I exit that container, eth1 vanishes from the world.  The 
> container's gone, but it doesn't reappear on the host.  (This may be 
> related to the fact that the only way I've found to kill a container 
> is do "killall -9 lxc-start".  For some reason a normal kill of 
> lxc-start is ignored.  However, this still shouldn't leak kernel 
> resources like that.)

It is related to the kernel behavior :  netdev with a rtnl_link_ops will 
be automatically deleted when a network namespace is destroyed. The full 
answer is at net/core/dev.c :


> Bug #2: When I uncomment that last line of the above busybox.conf, 
> telling it to move eth1 into the container but call it "eth0" in 
> there, suddenly the eth0 in the container gets entangled with the eth0 
> on the host, to the point where dhcp gives it an address.  (Which is 
> 10.0.2.16.  So it's talking to the VPN that only the host's eth0 
> should have access to, but it's using a different mac address.  Oddly, 
> the host eth0 still seems to work fine, and the two IP addresses can 
> ping each other across the container interface.)
>
> This is still using the most recent release version.

What is the kernel version ?

>>>
>>> The attached html file is a long drawn-out reproduction sequence for
>>> this.
>>>
>>> I tried downloading lxc-git to see if this is already fixed, but
>>> running "autoconf" doesn't seem to want to produce a ./configure file
>>> for me. ("configure.ac:8: error: possibly undefined macro:
>>> AM_CONFIG_HEADER") I'm really not an autoconf expert (the whole thing
>>> is just a horrible idea at the design level), so have no idea what I'm
>>> doing wrong there.
>>
>> Is automake installed on your system ? Maybe the version is too old ...
>
> # aptitude show automake
> Package: automake
> State: installed
> Automatically installed: yes
> Version: 1:1.11.1-1
> ...
>
> It's what "debian sid" installs by default when you ask for automake.
>
> Rob


<javascript:void(0);>