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

[Rob Landley]

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.)

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.

>>
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20110105/37239d0e/attachment.html>