LXC 1.0: Your first Ubuntu container [1/10]

This is post 1 out of 10 in the LXC 1.0 blog post series.

So what’s LXC?

Most of you probably already know the answer to that one, but here it goes:

“LXC is a userspace interface for the Linux kernel containment features.
Through a powerful API and simple tools, it lets Linux users easily create and manage system or application containers.”

I’m one of the two upstream maintainers of LXC along with Serge Hallyn.
The project is quite actively developed with milestones every month and a stable release coming up in February. It’s so far been developed by 67 contributors from a wide range of backgrounds and companies.

The project is mostly developed on github: http://github.com/lxc
We have a website at: http://linuxcontainers.org
And mailing lists at: http://lists.linuxcontainers.org

LXC 1.0

So what’s that 1.0 release all about?

Well, simply put it’s going to be the first real stable release of LXC and the first we’ll be supporting for 5 years with bugfix releases. It’s also the one which will be included in Ubuntu 14.04 LTS to be released in April 2014.

It’s also going to come with a stable API and a set of bindings, quite a few interesting new features which will be detailed in the next few posts and support for a wide range of host and guest distributions (including Android).

How to get it?

I’m assuming most of you will be using Ubuntu. For the next few posts, I’ll myself be using the current upstream daily builds on Ubuntu 14.04 but we maintain daily builds on 12.04, 12.10, 13.04, 13.10 and 14.04, so if you want the latest upstream code, you can use our PPA.

Alternatively, LXC is also directly in Ubuntu and quite usable since Ubuntu 12.04 LTS. You can choose to use the version which comes with whatever release you are on, or you can use one the backported version we maintain.

If you want to build it yourself, you can do (not recommended when you can simply use the packages for your distribution):

git clone git://github.com/lxc/lxc
cd lxc
sh autogen.sh
# You will probably want to run the configure script with --help and then set the paths
./configure
make
sudo make install

What about that first container?

Oh right, that was actually the goal of this post wasn’t it?

Ok, so now that you have LXC installed, hopefully using the Ubuntu packages, it’s really as simple as:

# Create a "p1" container using the "ubuntu" template and the same version of Ubuntu
# and architecture as the host. Pass "-- --help" to list all available options.
sudo lxc-create -t ubuntu -n p1

# Start the container (in the background)
sudo lxc-start -n p1 -d

# Enter the container in one of those ways## Attach to the container's console (ctrl-a + q to detach)
sudo lxc-console -n p1

## Spawn bash directly in the container (bypassing the console login), requires a >= 3.8 kernel
sudo lxc-attach -n p1

## SSH into it
sudo lxc-info -n p1
ssh ubuntu@<ip from lxc-info>

# Stop the container in one of those ways
## Stop it from within
sudo poweroff

## Stop it cleanly from the outside
sudo lxc-stop -n p1

## Kill it from the outside
sudo lxc-stop -n p1 -k

And there you go, that’s your first container. You’ll note that everything usually just works on Ubuntu. Our kernels have support for all the features that LXC may use and our packages setup a bridge and a DHCP server that the containers will use by default.
All of that is obviously configurable and will be covered in the coming posts.

This entry was posted in Canonical voices, LXC, Planet Ubuntu and tagged . Bookmark the permalink.

14 Responses to LXC 1.0: Your first Ubuntu container [1/10]

  1. Mark Constable says:

    I ran this intro article past a couple of non-techies and they couldn’t get past the quoted intro parargraph. The problem seems to be that the phrase “kernel containment features” is meaningless to anyone without a fair degree of OS level experience. I’d like to point out to linux novices why this is such a cool feature so if anyone could come up with the shortest bulletproof lxc intro explanation I, for one, would really appreciate it.

    • Yeah, that’s always a tough one…

      If they already are familiar with chroots, then it’s usually fairly easy to define LXC has chroots on steroid, with their own networking and isolated view of the process tree (though in practice it does quite a lot more than that).

      If they’re not, then a vague approximation would be a zero-overhead Linux only virtualization technology that’s extremely flexible but requires you to share your kernel with the host.

  2. Stuart Naylor says:

    I am definately a noob but my take on LXC.

    Near metal speed virtualisation that shares the same kernel space, without any of the hassle of defining disk or memory space.

    Bugger maybe not right but just damn easy virtualisation where you can start partitioning processes to make really stable solutions connected at the network level.

    Bugger maybe thats not right, just really exciting thats all.

    Stephane are you going to do an example with overlays unionfs or aufs where a “golden image” can be used multiple times so LXC can demonstrate a tiny resource footprint in disk and memory?

    I wouldn’t try and explain it just show the results

    • Stuart Naylor says:

      Apols to replying to myself.

      I would love to see a setup of many ubuntu servers all performing specific roles.

      MySQL, couple of instances of apache, postfix (mail), maybe a desktop via freenx or other, and any other servers you can think of.

      All of them using a cloned base image and employing unionfs or aufs to allow the instance space.

      It would be really good to get a modest piece of hardware and show how little resources are being used in comparison to other forms of virtualisation.

      Also demonstrate that network partitioning via LXC makes the move to dedicated servers very simple.

  3. Scott Dowdle says:

    Containers are a form of light weight virtualization where there is a single kernel that is shared by isolated, resource managed groups of processes… each being potentially a different Linux distribution, with its own users and network stack. Container don’t offer as much flexibility as hardware virtualization (Linux-on-Linux only), but being much lighter weight they offer increased performance, scalibility, and density and are appropriate for many virtualization use cases.

    Basically LXC 1.0 is almost as good as the out-of-tree OpenVZ patch from 2005 to present, except LXC runs on contemporary kernels since is has been part of the mainline kernel from the beginning.

  4. Stefan says:

    What I understand of LXC so far is that

    - LXC containers are similar to Oracle Solaris Zones
    - LXC containers share all the same kernel which means that an kernel update hits
    all LXC containers and at the same time. If each LXC container has a different services and/or customer, finding a downtime window which meets all needs can be difficult.

  5. wantoo says:

    Maybe once I see a use-case and some examples, I’ll understand. For now, I’m in the dark! Sounds exciting though so I’ll keep reading!

  6. jonesy says:

    Thanks very much for documenting this, it’s awesome. One thing I noticed is that, in the first set of example commands to get things going, where you tell us how to ssh into the container, you say to use lxc-info to get the IP, but that only gets the pid. The IP can be gotten using ‘sudo lxc-ls –fancy’.

    Thanks again for your work.

    • You must be using an older lxc.

      stgraber@castiana:~$ lxc-info -n precise-gui
      Name: precise-gui
      State: RUNNING
      PID: 30467
      IP: 10.0.3.59
      IP: 2607:f2c0:f00f:2751:212f:d38d:1fec:d6e1
      IP: 2607:f2c0:f00f:2751:216:3eff:fe51:234f
      CPU use: 675.46 seconds
      Memory use: 362.43 MiB
      Link: vethSTAD32
      TX bytes: 14.67 MiB
      RX bytes: 295.93 MiB
      Total bytes: 310.61 MiB

      • Frodox says:

        Well… it would be good, if you tell a few words about set up an internet (bridget) inside container..=)

        I use github version and all inet-options inside “…/myctn/config” are commented
        by you say nothing in this tutorial and it just work after creating for you =(

        • Macer says:

          Were you asking how to set up a bridge INSIDE the container or do you mean setting one up on the host? If you mean the ability to get the container onto the same subnet it wasn’t too difficult.

          (May differ across distros but I’m using Ubuntu Server)

          Disable default lxcbr0 in /etc/default/lxc
          Make sure bridge-utils is installed
          # apt-get install bridge-utils
          Edit /etc/network/interfaces
          You should have a line that says:
          auto eth0 (not sure if this is necessary but I would think so in order to make sure eth0 comes up)

          Edit /etc/network/interfaces and add:

          auto br0
          iface br0 inet static
          bridge_ports eth0
          bridge_fd 0
          address 192.168.1.### (Host IP not ###)
          netmask 255.255.255.0
          network 192.168.1.0
          broadcast 192.168.1.255
          gateway 192.168.1.1

          This is the part that confuses people. The eth0 interface will NOT have an IP. It will simply be up. All traffic on the host will actually start routing through br0 with eth0 being the PORT (means of pkt transport). Unless you are using some sort of advanced config then eth0 should just be up but with no settings attached to it.

          Edit container config:

          /var/lib/lxc//config

          # Network configuration
          lxc.network.type = veth
          lxc.network.flags = up
          lxc.network.link = br0
          lxc.network.hwaddr =
          lxc.network.ipv4 = 192.168.1.###/24 (container IP)

          Now when you start the container (using dhcp) it should always have the IP you specify in its config. After that you just need to get the DNS into resolv.conf. The Ubuntu containers use resolv.conf. I’m not a big fan of it so I usually remove it and simply add the DNS manually.

          Not sure if that’s what you were looking for but it seemed to work for me.

          • Frodox says:

            Yup, thank you very much!
            I did all this stuff inside VirtualBox (NAT-ed) with CentOS, so… I was a bit confused with web-tutorials and different configs..
            Today I finally found necessary combinations of all configs and set up network (lxc->VBox->www)! Voila :D

  7. AJ says:

    So, trying to wrap my fragile brain around this. You create an Ubuntu “host” that creates containers with potentially any linux distro. Does the host have to be Ubuntu? And how do you run other container OSes (like CentOS)?

  8. Macer says:

    Awesome stuff. Finally something similar to FBSD jails for Linux. You said earlier that the containers have their own network stack correct? Is this akin to vimage or more so similar to the default network aliasing FBSD uses for jails? It seemed as though in one of your examples you routed through the “host” system’s eth0. Is this necessary or is it possible to put the container on the same subnet?

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>