<p>To play around with containers, I chose to use a 3 layer approach:</p>

<ul>
<li><p><b>Laptop</b> - the host system running on real hardware (my Ubuntu
laptop).</p></li>
<li><p><b>KVM</b> - a virtual debian Sid system running under KVM.<p></li>
<li><p><b>Container</b> - a simple busybox-based system running in a
container.</p></li>
</ul>

<p>So "Laptop" hosts "KVM" which hosts "Container".</p>

<p>The advantage of this approach is we can modify and repeatedly reboot the
KVM system without interfering with the host laptop.  Whatever we do to
the KVM or Container systems</p>

<b><h2>Step 1: Create a root filesystem for the KVM system.</h2></b>

<p>Here's how to creates a debian "sid" (unstable) root filesystem and package
it into an 8 gigabyte ext3 image.  The root password is "root".  If you prefer a
different root filesystem, feel free to use that instead.  This procedure
requires the "debootstrap", "genext2fs", and "e2fsprogs" packages installed.</p>

<p>This creates a smaller image and resizes it because genext2fs is extremely
slow at creating large images.</p>

<p>You'll have to run this stage as root, and it requires network access.  The
remaining stages do not require root access.</p>

<blockquote><pre>
sudo debootstrap sid sid

echo -e "root\nroot" | chroot sid passwd
echo -e "auto lo\niface lo inet loopback\nauto eth0\niface eth0 inet dhcp" \
  > sid/etc/network/interfaces
rm -f sid/etc/udev/rules.d/70-persistent-net.rules
echo kvm > sid/etc/hostname
echo cgroup /mnt/cgroup cgroup defaults >> sid/etc/fstab
mkdir -p sid/mnt/cgroup

BLOCKS=$(((1024*$(du -m -s sid | awk '{print $1}')*12)/10))
genext2fs -z -d sid -b $BLOCKS -i 1024 sid.ext3
resize2fs sid.ext3 8G
tune2fs -j -c 0 -i 0 sid.ext3
</pre></blockquote>

<p>Now chown the "sid.ext3" file to your normal (non-root) user, and switch back
to that user.  (If you forget to chown, the emulated system won't be able to
write to the ext3 file and will complain about write errors when you fire up
KVM.  Use your username instead of mine here.)</p>

<blockquote><pre>
chown landley:landley sid.ext3
exit  # Stop being root now
</pre></blockquote>

<b><h2>Step 2: Build a kernel for KVM, with container support.</h2></b>

<p>The defconfig in 2.6.36 is close to a usable configuration, but needs
a few more symbols switched on:</p>

<blockquote><pre>
# Start with the default configuration
make defconfig

# Add /dev/hda and more container support.
cat >> .config << EOF
CONFIG_IDE=y
CONFIG_IDE_GD=y
CONFIG_IDE_GD_ATA=y
CONFIG_BLK_DEV_PIIX=y

CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_MEM_RES_CTLR=y
CONFIG_CGROUP_MEM_RES_CTLR_SWAP=y
CONFIG_CGROUP_MEM_RES_CTLR_SWAP_ENABLED=y
CONFIG_BLK_CGROUP=y
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
EOF
yes '' | make oldconfig

# Build it

CPUS=$(grep "^processor" /proc/cpuinfo | wc -l)
make -j $CPUS
</pre></blockquote>

<p>(You might want to add -j $MYCPUS to your make.)</p>

<p>This builds a (mostly) static kernel, because rebooting kvm with a new
kernel image is trivial, but copying modules into a loopback mounted root
filesystem image is a multi-step process requiring root access.</p>

<b><h2>Step 3: Boot the result under QEMU or KVM, and add more packages.</h2></b>

<p>This invocation boots the newly built kernel with the sid root filesystem
image, configured to exit the emulator when the virtual system shuts down.
It allocates 1 gigabyte of memory and provides a virtual gigabit network
interface hooked up to a virtual masquerading router (for the 10.0.2.X
address range), with port 9876 on the host's loopback interface forwarded to
the SSH port on the emulated interface.</p>

<blockquote><pre>
kvm -m 1024 -kernel arch/x86/boot/bzImage -no-reboot -hda ~/sid.ext3 \
  -append "root=/dev/hda rw panic=1" -net nic,model=e1000 -net user \
  -redir tcp:9876::22
</pre></blockquote>

<p>Log in to the resulting system (user root password root), and install
some more packages to fluff out the SID install a bit.</p>

<blockquote><pre>
aptitude update
aptitude install file psmisc less strace bzip2 make gcc libc6-dev dropbear lxc
</pre></blockquote>

<b><h2>Step 4: ssh into the KVM instance.</h2></b>

<p>The KVM/QEMU console window is a nice fallback, but awkward for serious
use.  To get multiple terminal windows, or use cut and paste, we need more.
Redirecting a port from the host's loopback interface to connect to the
port of the KVM instance allows us to ssh in from the laptop system.</p>

<p>In step 3, we installed the dropbear ssh server, and the
"-redir tcp:9876::22" arguments we used to launch KVM forward port 9876 from
the host's loopback interface to port 22 of KVM's eth0, so we should now be
able to ssh in from the laptop system via:</p>

<blockquote><pre>
ssh root@127.0.0.1 -p 9876
</pre></blockquote>

<p>Remember, root's password is "root".  (Feel free to change it.)</p>

<b><h2>Step 5: Install container support</h2></b>

<p>Launching containers requires the "cgroup" filesystem be mounted somewhere.
(Doesn't matter where, LXC will check /proc/mounts to find it.)  In step 1,
we added an fstab entry to the KVM sid system to mount cgroup on
/mnt/cgroup.</p>

<p>We also need the LXC command line tools, which we installed in step 3.</p>

<b><h2>Step 6: Set up a simple busybox-based container under the KVM
system.</h2></b>

<p>The lxc-create command sets up a container directory with a new root
filesystem.  It takes three arguments: a name for the new container directory,
a root filesystem build script, and a configuration file describing
things like what network devices to put in the new container.</p>

<p>LXC calls its root filesystem build scripts "templates" (see
/usr/lib/lxc/templates), the simplest of which is the "busybox" template.</p>

<p>Unfortunately, the default busybox binary in Debian sid is insufficient.
The "busybox" package doesn't include the "init" command, and the
"busybox-static" package doesn't have "login".  To work around this, we grab a
prebuilt busybox binary from the busybox website, and add the current
directory to the $PATH so lxc-create can find it.</p>

<p>We supply a trivial configuration file defining no network devices, mostly
to shut up the "are you really really sure" babysitting lxc-create would
spew otherwise.</p>

<blockquote><pre>
wget http://busybox.net/downloads/binaries/1.18.0/busybox-i686 -O busybox
chmod +x busybox
echo "lxc.utsname = container" > container.conf
PATH=$(pwd):$PATH lxc-create -f container.conf -t busybox -n test
</pre></blockquote>

<p>LXC creates the container's directory (including its config file and its
root filesystem) under /var/lib/lxc.</p>

<p>If you want to delete this container, the command is:</p>

<blockquote><pre>
lxc-destroy -n test
</pre></blockquote>

<b><h2>Step 7: Launch the container</h2></b>

<p>Now we get to experience the brittle bugginess that is LXC 0.7.3.
The first step to launching an LXC container is:</p>

<blockquote><pre>
lxc-start -n container
</pre></blockquote>

<p>This starts busybox init in the container, which will tell you
"press Enter to activate this console".  Unfortunately, LXC's console
handling code is buggy, and this console won't actually
work.  (Feel free to play with it, just don't expect to accomplish much.)</p>

<p>To get a working shell prompt in the container, ssh into the KVM system
again and from that window type:</p>

<blockquote><pre>
lxc-console -n container
</pre></blockquote>

<p>This will connect to one of init's other consoles, which finally lets you
log in (as root).</p>

<p>You should now be able to get a shell prompt in all three systems:</p>

<ul>
<li><p>The host laptop.</p></li>
<li><p>The Debian sid KVM.</p></li>
<li><p>The busybox container.</p></li>
</ul>

<p>To kill the container, run this on the KVM system:</p>

<blockquote><pre>
killall -9 lxc-start
</pre></blockquote>

<p>(I don't know why lxc-start ignores everything but "kill -9".  I think
it's another bug.)</p>

<p>Next time, we set up networking in the container.</p>