Suno Ano wrote:
> Hi folks,
> I figure most people are desperately looking for some Quickstart info on
> LXC. There is quite a bit info on the net already but then there is one
> that is quite up to date and written straight forward:
> It also features a git repo [0] containing some additions to mainline
> lxc utils that play nicely and work flawlessly from what I can tell so
> far.
I would like to add some comments concerning the two notes in the footer 
of the howto.

this is debatable. Martyn seems to be getting along fine with 
configuring his containers to use the physical interface directly; I had 
less luck. The bridge Works For Me, and conveniently is what you need 
for heavier virtualisation like kvm, so I'm sticking with it."

The use of a physical interface in the container was possible with a 
kernel patch but it is right now disabled in the mainline kernel due to 
the sysfs limitations. At present there is some work around the sysfs 
per namespace to be merged in the mainline kernel, so I hope that would 
be possible to use a physical interface soon.

The veth allows to have the container to communicate with the other 
containers (within the host), with the host and with the outside world. 
The drawback is the loss of the network offloading, so more overhead 
with heavy traffic.

The macvlan allows to get rid of setting up a bridge and you can use the 
full offloading capability of the physical interface. Using the macvlan 
is like using the physical interface. The drawback is you can not 
communicate with the host and with the other containers. But the macvlan 
was modified to act as a bridge in the 2.6.33 kernel and this new 
capability is already take into account in lxc for the 0.6.5 version 
(check the lxc.conf man page). So the next macvlan version should have 
the advantages without the drawbacks.

found that starting containers in the foreground and then lxc-stopping 
them can cause the terminal they were in to start behaving strangely. No 
idea why this is, I tend to always start my containers in the background 
so it's not an issue for me."

The console in the container is the terminal tty mapped on /dev/console. 
The init process of the container does literally "stole" the terminal's 
tty when getting the console with a TIOCSCTTY ioctl, so when the 
container exits, the shell has no longer a controlling tty, (ctrl+C, 
ctrl+Z, etc ... does no longer work, etc ...),
An extract of the tty_ioctl man page:

"Controlling tty
       TIOCSCTTY int arg
              Make  the  given tty the controlling tty of the calling 
process.  The calling process must be a ses-
              sion leader and not have a controlling tty already.  If 
this tty is already the controlling tty of a
              different session group then the ioctl fails with EPERM, 
unless the caller is root and arg equals 1,
              in which case the tty is stolen, and all processes that 
had it as controlling tty lose it."

 The console management needs some redesign to avoid that. Maybe do the 
same but allocate a tty for the container and proxy the io of the tty to 
the terminal tty.

   -- Daniel

Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
Lxc-users mailing list

Reply via email to