[lxc-devel] LXC as an alternative to linux-vserver
Hi all, We have been using linux-vserver for years (we actually created the project before eventually passing on maintainership), but after years of kernel patching and unending API and syscall changes, we are looking to move towards a more mainstream approach, ideally fully integrated into the stock linux kernel. Some research has lead me to LXC as perhaps a viable replacement solution, but before going further I would like to get a better grasp on some of key aspects of the project. Here goes: - One of the things we use a lot with linux-vserver is an "enter" functionality: from a shell in the host, use the "enter" command to get a shell inside a container. This is a variant of the "exec" feature, which allows the execution of an arbitrary command inside a container from a shell on the host. A lot of our internal processes are based on this feature. The vast majority of our containers do not run SSH servers and are accessed interactively (or not) from the host. Is this functionality (or something equivalent) supported by LXC? - As far as networking is concerned, we simply use IP aliases (eth0:1) to allocate IP addresses for the containers. This offers very basic network isolation (the container is limited to using specific aliases) but it suits our needs. With LXC, is this simple technique usable or does one have to necessarily setup bridges and/or tunnels? Thanks a lot, Patrick -- *Patrick LeBoutillier* Directeur TI 2, Place Laval, bureau 510 Laval (Québec) H7N 5N6 patrick.leboutill...@croesus.com 450-662-6101, poste 136 -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] [Lxc-users] pivot root failures when "/" is mounted as "shared"
Additional comments specific to the pivot root issue... Adding the developers list as well, since this is a development issue... On Sat, 2012-11-03 at 12:01 +0100, Peter Simons wrote: > Hi guys, > I've been using lxc for a while now, and it's a great tool. Thank you > very much for the time and effort you have been dedicating to the > development of that software! > My Linux distribution (NixOS) is about to switch from upstart to > systemd, and it this switch in the host system is going to break all my > containers. It appears this is a well known problem that's been reported > at > > http://sourceforge.net/tracker/?func=detail&aid=3559833&group_id=163076&atid=826303 > and > https://github.com/lxc/lxc/issues/4. > Now, I wonder what the status of this issue is. Is it clear how that > problem can be remedied? Is there maybe a patch that fixes this problem? > Does anyone know a work-around that I could use to keep my containers > running when that switch to systemd occurs on the host system? This was from another threat with the systemd guys. On Mon, 2012-10-22 at 16:11 +0200, Lennart Poettering wrote: > Note that there are reports that LXC has issues with the fact that > newer > systemd enables shared mount propagation for all mounts by default > (this > should actually be beneficial for containers as this ensures that new > mounts appear in the containers). LXC when run on such a system fails > as > soon as it tries to use pivot_root(), as that is incompatible with > shared mount propagation. The needs fixing in LXC: it should use > MS_MOVE > or MS_BIND to place the new root dir in / instead. A short term > work-around is to simply remount the root tree to private before > invoking LXC. > > Lennart > -- > Lennart Poettering - Red Hat, Inc. So there you have a suggested workaround for the shared mount propagation problem, which is what you are referring to. ITMT... Daniel, Serge? Any thoughts on those comments vis-a-vis the pivot function and using MS_MOVE or MS_BIND instead? IIRC, we switched to pivot_root() years ago to deal with some other issues that were plaguing us. > Take care, > Peter > > > -- > LogMeIn Central: Instant, anywhere, Remote PC access and management. > Stay in control, update software, and manage PCs from one command center > Diagnose problems and improve visibility into emerging IT issues > Automate, monitor and manage. Do more in less time with Central > http://p.sf.net/sfu/logmein12331_d2d > ___ > Lxc-users mailing list > lxc-us...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lxc-users > -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] LXC as an alternative to linux-vserver
On Sat, 2012-11-03 at 17:10 -0400, Patrick LeBoutillier wrote: > Hi all, > We have been using linux-vserver for years (we actually created the > project before eventually passing on maintainership), but after years > of kernel patching and unending API and syscall changes, we are looking > to move towards a more mainstream approach, ideally fully integrated into > the stock linux kernel. > Some research has lead me to LXC as perhaps a viable replacement > solution, but before going further I would like to get a better > grasp on some of key aspects of the project. I tried using linux-vservers a long time ago but had to abandon it due to removal / failure of IPv6 support (which I think has since been corrected) something like a decade ago. At the time, I switched to OpenVZ and never looked back. I feel your pain on the kernel patching an maintenance. This finally got me fed up and I had to abandon OpenVZ for LXC. For what I do, it works great. It has some significant resource control limitations vis-a-vis OpenVZ but I wasn't using those trottles and tuning knobs anyways. I'm running a set of tightly controlled environments with no "untrusted" users so all the owners of my containers are no more than a strong brick throw away from me so that takes care of resource management for me. :-)=) > Here goes: > - One of the things we use a lot with linux-vserver is an "enter" > functionality: from a shell in the host, use the "enter" command > to get a shell inside a container. This is a variant of the "exec" > feature, which allows the execution of an arbitrary command inside > a container from a shell on the host. I believe with recent kernels this works with lxc-attach but could be problematical. I'm working on development versions right now and it's having problems attaching. At one point, this feature needed a kernel patch but I was thinking it has been integrated upstream. Not certain. > A lot of our internal processes are based on this feature. The vast > majority of our containers do not run SSH servers and are accessed > interactively (or not) from the host. > Is this functionality (or something equivalent) supported by LXC? You really don't want to do that. Just use bridging. In the end, once it's set up, it's cleaner. I used bridging on linux-vservers, OpenVZ, and now LXC. > - As far as networking is concerned, we simply use IP aliases (eth0:1) > to allocate IP addresses for the containers. This offers very basic > network isolation (the container is limited to using specific aliases) > but it suits our needs. > With LXC, is this simple technique usable or does one have to > necessarily setup bridges and/or tunnels? There's also macvlan in LXC with lets the container share the network device (sort of what you are doing without the need for alias interfaces) but there have been problems in the past with that (solved now, I think). > Thanks a lot, > Patrick > -- > *Patrick LeBoutillier* > Directeur TI > 2, Place Laval, bureau 510 > Laval (Québec) H7N 5N6 > patrick.leboutill...@croesus.com > 450-662-6101, poste 136 Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] LXC as an alternative to linux-vserver
On Sat, 03 Nov 2012 "Michael H. Warfield" wrote: > On Sat, 2012-11-03, Patrick LeBoutillier wrote: > >> - One of the things we use a lot with linux-vserver is an "enter" >> functionality: from a shell in the host, use the "enter" command >> to get a shell inside a container. This is a variant of the "exec" >> feature, which allows the execution of an arbitrary command inside >> a container from a shell on the host. > > I believe with recent kernels this works with lxc-attach but could be > problematical. I'm working on development versions right now and it's > having problems attaching. At one point, this feature needed a kernel > patch but I was thinking it has been integrated upstream. Not certain. I *think* the contrary is the case: lxc-attach capability is neither integrated into any current kernels, nor is lxc-attach working with an unpatched kernel. I would be very happy to see some evidence to the contrary and would be glad to attach it here: http://bugs.debian.org/595920 Wrt the original question I agree with Michael: a missing lxc-attach is not *that* problematic as you can work around it with ssh. However if lxc-attach actually worked, that would be very yummy. Thanks, *t -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d ___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
Re: [lxc-devel] LXC as an alternative to linux-vserver
On Sat, 2012-11-03 at 23:51 +0100, Tomas Pospisek wrote: > On Sat, 03 Nov 2012 "Michael H. Warfield" wrote: > > > On Sat, 2012-11-03, Patrick LeBoutillier wrote: > > > >> - One of the things we use a lot with linux-vserver is an "enter" > >> functionality: from a shell in the host, use the "enter" command > >> to get a shell inside a container. This is a variant of the "exec" > >> feature, which allows the execution of an arbitrary command inside > >> a container from a shell on the host. > > > > I believe with recent kernels this works with lxc-attach but could be > > problematical. I'm working on development versions right now and it's > > having problems attaching. At one point, this feature needed a kernel > > patch but I was thinking it has been integrated upstream. Not certain. > > I *think* the contrary is the case: lxc-attach capability is neither > integrated into any current kernels, nor is lxc-attach working with an > unpatched kernel. I would be very happy to see some evidence to the > contrary and would be glad to attach it here: > > http://bugs.debian.org/595920 As I said... I was not certain. Sad it's still not there yet. > Wrt the original question I agree with Michael: a missing lxc-attach is > not *that* problematic as you can work around it with ssh. However if > lxc-attach actually worked, that would be very yummy. You are absolutely correct. If we can't get systemd to play nicely with console getty's on tty? then we absolutely need this, since their actions have rendered the lxc-console useless. My problem was that you can not depend on ssh for a variety of reason as you are provisioning containers. I could get an F17 container provisioned but then I had no ssh and no consoles. I was shooting in the dark until Serge worked out a patch for what I was uncovering. If you can't get networking up and running, you can't get ssh up and running and, if you don't have consoles, you can't begin to debug WHY you don't have networking up and running. > Thanks, > *t > > -- > LogMeIn Central: Instant, anywhere, Remote PC access and management. > Stay in control, update software, and manage PCs from one command center > Diagnose problems and improve visibility into emerging IT issues > Automate, monitor and manage. Do more in less time with Central > http://p.sf.net/sfu/logmein12331_d2d > ___ > Lxc-devel mailing list > Lxc-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/lxc-devel > -- Michael H. Warfield (AI4NB) | (770) 985-6132 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d___ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
