I'm going to dispel a few myths here.
This is just a bad idea. I'm sorry. – Jacob Mar 5 at 20:30
I don't see how this is a bad idea. It's really just a chroot inside a chroot. On one hand, it could possibly decrease performance in some negligible manner (nothing compared to running a VM inside a VM). On the other hand, it's likely to be more secure (e.g. more isolated from the root host system and it's constituents).
Do you actually have a real reason to do this? Please remember that questions here should be about actual problems that you face. – Zoredache Mar 5 at 21:52
I agree 100% with the poster's following comment. Furthermore, I think it's safe to assume that everybody who posts a question on here likely thinks that they have a real reason to do [ it ]..
I think, that lxc should be able to simplify VM migration(and backup+recovery too). But I'm not sure about cases, when there is no access to host OS(cheap vps for example). – Mikhail Mar 6 at 11:17
I actually came across this question back in June when I was first diving into LXC for PaaS/IaaS projects, and I was particularly interested in the ability to allow users to emulate cloud environments for development purposes.
LXCeption. We're too deep. – Tom O'Connor Mar 6 at 22:46
I laughed a little bit when I read this one, but that's not, at all, the case :)
Anyway, I eventually set up a VirtualBox environment with a stock install of Ubuntu 12.04 LTS Server Edition after reading all this, thinking that this was 100% possible. After installing LXC, I created a new container, and installed LXC inside the container with apt-get. Most of the installation progressed well, but resulted in error eventually due to a problem with the cgroup-lite package, whose upstart job failed to start after the package had been installed.
After a bit of searching, I came across this fine article at stgraber.org (the goodies are hiding under the "Container Nesting" section):
sudo apt-get install lxc
sudo lxc-create -t ubuntu -n my-host-container -t ubuntu
sudo wget https://www.stgraber.org/download/lxc-with-nesting -O /etc/apparmor.d/lxc/lxc-with-nesting
sudo /etc/init.d/apparmor reload
sudo sed -i "s/#lxc.aa_profile = unconfined/lxc.aa_profile = lxc-container-with-nesting/" /var/lib/lxc/my-host-container/config
sudo lxc-start -n my-host-container
(in my-host-container) sudo apt-get install lxc
(in my-host-container) sudo stop lxc
(in my-host-container) sudo sed -i "s/10.0.3/10.0.4/g" /etc/default/lxc
(in my-host-container) sudo start lxc
(in my-host-container) sudo lxc-create -n my-sub-container -t ubuntu
(in my-host-container) sudo lxc-start -n my-sub-container
Installing that AppArmor policy and restarting the daemon did the trick (don't forget to change the network ranges, though!). In fact, I thought that particular snippet was so important that I mirrored it @ http://pastebin.com/JDFp6cTB just in case the article ever goes offline.
After that, sudo /etc/init.d/cgroup-lite start succeeded and it was smooth sailing.
So, yes, it is possible to start an LXC container inside of another LXC container :)
Times change and so do best practices.
The current best way to do this is to run systemctl edit myservice, which will create an override file for you or let you edit an existing one.
In normal installations this will create a directory /etc/systemd/system/myservice.service.d, and inside that directory create a file whose name ends in .conf (typically, override.conf), and in this file you can add to or override any part of the unit shipped by the distribution.
For instance, in a file /etc/systemd/system/myservice.service.d/myenv.conf:
[Service]
Environment="SECRET=pGNqduRFkB4K9C2vijOmUDa2kPtUhArN"
Environment="ANOTHER_SECRET=JP8YLOc2bsNlrGuD6LVTq7L36obpjzxd"
Also note that if the directory exists and is empty, your service will be disabled! If you don't intend to put something in the directory, ensure that it does not exist.
For reference, the old way was:
The recommended way to do this is to create a file /etc/sysconfig/myservice which contains your variables, and then load them with EnvironmentFile.
For complete details, see Fedora's documentation on how to write a systemd script.
Best Answer
answering to myself. The lxc-archlinux template is available at https://github.com/dotcloud/lxc/blob/master/templates/lxc-archlinux.in but it does not include the migration to systemd (as of Feb 15 2013) .
there are usable rootfs part of archlinux (e.g http://www.gtlib.gatech.edu/pub/archlinux/iso/2013.02.01/arch/i686/root-image.fs.sfs for i686 there also is a 64 bit version)
I did not run an lxc guest out of it yet but I got a functional i686 chroot from inside ubuntu 12.04 x64. 1/ download and unsquash the root image, mount it somewhere.
2/ as root (sudo) cp -ar the root filesystem to your location and chroot into it
3/ edit /etc/pacman.conf and update the arch line (by default it is auto, which pulls the ar ch from uname, but ubuntu and arch do not use the same designation)
4/ mount /proc /dev/random and /dev/urandom (this is needed by pacman and pacman-key)
I could not get pacman to run without package signature properly setup
5/ pacman-key --init (here it needs a good source of entropy)
6/ pacman-key --populate archlinux
7/ optional: pacman-key --refresh-keys (needs a working internet connection)
8/ edit /etc/pacman.d/mirrorlist to activate mirrors relevant to you.
9/ pacman -Syy
ready to update or install new packages.
What's (direly) missing is the container startup. I'm not up to speed on systemd but if I understand correctly this is mostly a matter of starting dbus and systemd.