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: > > http://nigel.mcnie.name/blog/a-five-minute-guide-to-linux-containers-for-debian > > 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.
"[1] <http://nigel.mcnie.name/blog/a-five-minute-guide-to-linux-containers-for-debian#id1>Actually, 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. "[2] <http://nigel.mcnie.name/blog/a-five-minute-guide-to-linux-containers-for-debian#id2>I've 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. Regards -- 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. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
