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  containing some additions to mainline
> lxc utils that play nicely and work flawlessly from what I can tell so
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:
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.
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