LXC 1.0: Blog post series [0/10]

So it’s almost the end of the year, I’ve got about 10 days of vacation for the holidays and a bit of time on my hands.

Since I’ve been doing quite a bit of work on LXC lately in prevision for the LXC 1.0 release early next year, I thought that it’d be a good use of some of that extra time to blog about the current state of LXC.

As a result, I’m preparing a series of 10 blog posts covering what I think are some of the most exciting features of LXC. The planned structure is:

While they are all titled LXC 1.0, most of the things I’ll be showing will work just as well on older LXC. However some of the features will need a very very recent version of LXC (as in, current upstream git). I’ll try to make that clear and will explain how to use our stable backports in Ubuntu or current upstream snapshots from our PPA.

I’ll be updating this first blog post with links to all of the posts in the series. So if you want to bookmark or refer to these, please use this post.

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

22 Responses to LXC 1.0: Blog post series [0/10]

  1. Hello Stéphane!

    Thanks for the series of great articles. We run our complete infrastructure within LXC. In the past we had to exchange physical servers pretty often. They were all Ubuntu 12.04. Unfortunately, we did not find a way to copy LXC machines between servers.

    If it’s possible, can you please describe it in these series?

    • Hi!

      I’ll try to cover it in one of the upcoming posts but very quickly, unless you are using some unusual way of spring your containers, copying /var/lib/lxc from one host to another will do the trick. Just make sure to copy all attributes either by making a tarball or by using something like rsync -a –hard-links –sparse –numeric-ids

      • Thanks for the reply. Is this going to work, even if hardware is pretty different? Another interesting point would be to explain how this sort of container copy/move differences from conventional vms (virtual box and vmware)?

        • You obviously need both hosts to support the container’s architecture but besides that, Linux distributions don’t really care about what hardware is in your server.

          The kernel takes care of that much and since LXC containers use the host’s kernel, nothing should be needed there.

          As for containers vs VMs, containers should be slightly easier to move because you can move them to a server with fewer CPU capabilities without having to reconfigure them.
          Not that reconfiguring VMs is required in all cases, but depending on the technology used and the kind of feature passthrough that they use, it may happen.

          In practice, in most cases, moving a VM requires moving a bunch of disk images and a configuration file, moving a container requires moving a directory, so all in all not do different.

  2. Winael says:

    Hi Stéphane,

    Thx for all your work on LXC.

    I plan to work with LXC container app. I don’t want to debootstrap in it, I don’t need an entire system in it. Will you talk about this particular case in your post ?

    I plan to translate your post into french to break the language barrier. But I need you authorization to publish it. In fact, because you’re speak french, I’m wondering if you’ll be interested in reading and correct me ? All my sources are published in rst here : https://github.com/Winael/LXC-LXC-1.0/tree/master/_sources/fr
    (I’ll generate an online doc/odt/pdf/epub too, english and french, ‘coz I kind of need it for my personnal use :p but I think it could help lot’s of people)

    Happy holidays

    Winael

    • Hi,

      I wasn’t planning on covering application containers in this series though maybe I will if I’m running out of things to talk about in one of the posts :)

      Anyway, in your case, I suspect you’ll either want to create a minimal rootfs similar to what’s done with the busybox template or even run against the host rootfs by using something like:
      lxc-execute -n p5 — /path/to/service

      As for translating and publishing translations of my posts, feel free to go ahead and I’ll try to take a look at them if/when I find the time!

      Enjoy the holidays!

  3. Pingback: Creating a virtualized fully-distributed Hadoop cluster using Linux Containers | Big Data, Small Font

  4. Robert Breton says:

    Where does Docker fit into all of this? We’re thinking about using it on top of LXC. What are your thoughts on Docker versus native LXC?

  5. Pingback: Релиз LXC 1.0, системы управления изолированными контейнерами Linux | Просто блог

  6. Alexander says:

    That is actually a good question posted by Robert Breton. But I believe Docker runs on top of LXC so they do not go in competition or against (am I wrong?).

    Moreover, it would be great to know your opinion, Stéphane as well.

    I for one, am already working on some APIs to automate some functionalities of Docker in Python. I’m already thinking of a general purpose engine but plugged with APIs to create individual environments, all powered by Docker and LXC under the hood; this should pack some tremendous power for Quality Assurance, Testing and Development Testing stage of software (e.g. unittests but where heavy load is needed).

    Would be great to know if LXC development may head towards this view as well? Maybe partnership with Docker? Who knows what awaits… :-)

    In any case, thanks for all your work

  7. Pingback: Статьи о LXC 1.0 | SysAdmins Location

  8. raul says:

    Imho there is a communication problem with LXC, not only because of a lack of communication, engagement, involvement from the LXC team about their project but also the Docker project which leverages LXC. Because of the way the docker team has decided to communicate and with LXC being relatively unknown there is now plenty of potential for confusion, that a nascent project that needs support like LXC can do without.

    Visit the docker page and read the about section including the embedded slideshare and the getting started page you do get the impression its Docker which is providing the capabilities provided by LXC. There is no mention of LXC, and this can be slightly to hugely misleading. This has to be one of the main reasons why there are many people who appear to be confused about docker and LXC and what exactly LXC is and what capabilities Docker adds to it. Its a management and deployment layer that can be done in LXC itself, or with some scripts.

    A bit like for example UFW and iptables. UFW does not provide the capabilities of iptables, it leverages them, but its fundamentally iptables that is providing these capabilities. It would be odd for UFW to showcase powerful iptables functionality without making it clear its a management scripting layer on top of iptables.

    I think docker should be clearer about what it is doing, as the vagueness creates needless confusion and detracts from exciting capabilities and possibilities that LXC brings, pushing it into the background as some boring infrastructure container stuff provided by the kernel, when it LXC and the work done by Stephane and team that is fundamentally providing all these capabilities, and needs to be widely known and supported.

    • Alexander says:

      Couldn’t say it better. Even though the Mailinglist is quite active (been registered for a while now) whenever someone mentions Docker, people just treat it very cold. Maybe is the relationship you’ve described raul that creates this effect, albeit to be honest, I fully agree with you.

      In the end it could be that this hinders both projects. On the other side you could see why this is, as you’ve mentioned:
      1) LXC needs to be focused on its functionalities, thus developing i t, debugging, kernel analysis and whatever else may be needed drains time and there is little left for popularizing it (more than the ML, Canonical – sort of and whatever other events there may be).

      2) Docker builds on top of LXC, so they already have most of the functionality like you’ve said, they have more time in providing their layering but this is permits (more?) time to have a better strategy on the “market”. Maybe this is why was coded in Go in the first place? To be honest this attitude leaves me cold but… yeah.

      Anyways, in the end as for LXC, if you’re active in RSS feeds like LWN.net you cannot hear of it (actually there I find the the news related to the release of 1.0).

      Maybe is just me…

      • Docker aims to provide slightly different functionality than LXC. Docker is built as a framework on top of containers (and other technology going forward) that provides workflow and lifecycle for building and managing applications. It does this by helping you specify and build “containers” to hold applications and services. It provides tools and an API to deploy and manage those containers. I consider LXC to be handling the “building containers” at an infrastructure level whilst Docker works at the application level.

        Additionally, since Docker 0.9, we’ve removed the dependency on LXC in favor of our own native container format called libcontainer. Libcontainer natively interacts with cgroups and namespaces to create your own containers and their configuration. You can still use LXC under Docker by the default containerization technology is now our native variant. We’ve done this primarily to reduce the number of variables/components in the stack we run and to limit our exposure to changes in LXC requiring updates to Docker (In fairness our implementation/integration to LXC was little more than a wrapper around the lxc binaries so issues were frequent).

        Hope this helps clarify and feel free to reach out to me – james@docker.com or on the #docker Freenode channel – if you have any queries or questions about Docker and our plans.

        Ritual disclaimer: I work at Docker.

  9. Pingback: Ivan Pesin - Links: Apr 4

  10. Fibo says:

    I am “slightly” confused between LXC, Docker and other tools like OpenVZ, Proxmox…

  11. qin guang says:

    Hello Stéphane
    This is Qin Guang, I have one question about LXC IPC.
    Currently i already set network option in lxc.conf to use private network space. below is example:
    lxc.network.type = veth
    lxc.network.hwaddr = 00:01:02:03:04:05
    lxc.network.flags = up
    lxc.network.link = br0
    lxc.network.ipv4 = 192.168.2.1/24

    but i still want to let one process inside lxc communicate with process running outside lxc container using UNIX domain socket such as /tmp/testunixsocket.
    I dont want to use TCP/UPD socket.
    Would you please tell me how to let this work?

    Thanks,
    Qin Guang

  12. Pingback: Working with unprivileged and privileged containers in Ubuntu 14.04 and LXC « geeklee's Notes

  13. Pingback: Nekhelesh Ramananthan: A Core App Dev's Workflow | Bartle Doo Articles

  14. Pingback: Linux containers (LXC), Docker, CoreOS and systemd-nspawn | Rui's Blog

  15. Peter says:

    Sorry to bother you on my trivial problem. I am an 81 year old enthusiast of kubuntu, at novice level. Have tried to install lxc, but got errors and have a real mess on my hands. It’s totally beyond my expertise, so could you advise as to how I can totally undo all of this.
    So far I’ve installed part of lxc container: Created a 32bit container,
    Then start the container; at the console login prompt…..
    Thenbumpy@my32bitbox:~$ sudo apt-get install software-properties-common
    Reading package lists... Error!
    E: Type ‘deb-src-src’ is not known on line 10 in source list /etc/apt/sources.list
    E: The list of sources could not be read.
    E: The package lists or status file could not be parsed or opened.
    bumpy@my32bitbox:~$ cd /etc/apt/sources.list
    -bash: cd: /etc/apt/sources.list: Not a directory
    bumpy@my32bitbox:~$ /etc/apt/sources.list
    -bash: /etc/apt/sources.list: Permission denied
    bumpy@my32bitbox:~$ sudo /etc/apt/sources.list
    sudo: /etc/apt/sources.list: command not found
    bumpy@my32bitbox:~$ cd /etc/apt/sources.list
    -bash: cd: /etc/apt/sources.list: Not a directory
    bumpy@my32bitbox:~$ cd /etc/apt
    bumpy@my32bitbox:/etc/apt$ dir
    apt.conf.d preferences.d sources.list sources.list.d trusted.gpg trusted.gpg~ trusted.gpg.d
    bumpy@my32bitbox:/etc/apt$ sources.list
    -bash: sources.list: command not found
    bumpy@my32bitbox:/etc/apt$
    bumpy@my32bitbox:/etc/apt$ dir
    apt.conf.d preferences.d sources.list sources.list.d trusted.gpg trusted.gpg~ trusted.gpg.d
    bumpy@my32bitbox:/etc/apt$ print sources.list
    Warning: unknown mime-type for "sources.list" -- using "application/octet-stream"
    Error: no "print" mailcap rules found for type "application/octet-stream"
    bumpy@my32bitbox:/etc/apt$ sources.list
    -bash: sources.list: command not found
    bumpy@my32bitbox:/etc/apt$ sudo apt-get update
    E: Type ‘deb-src-src’ is not known on line 10 in source list /etc/apt/sources.list
    E: The list of sources could not be read.
    bumpy@my32bitbox:/etc/apt$ sudo sudo sources.list
    sudo: sources.list: command not found
    bumpy@my32bitbox:/etc/apt$ sudo sources.list
    sudo: sources.list: command not found
    bumpy@my32bitbox:/etc/apt$ cd ..
    bumpy@my32bitbox:/etc$ cd ..
    bumpy@my32bitbox:/$ sudo apt-get update
    E: Type ‘deb-src-src’ is not known on line 10 in source list /etc/apt/sources.list
    E: The list of sources could not be read.
    bumpy@my32bitbox:/$ sudo apt-get update
    E: Type ‘deb-src-src’ is not known on line 10 in source list /etc/apt/sources.list
    E: The list of sources could not be read.
    bumpy@my32bitbox:/$ deb http://ca.archive.ubuntu.com/ubuntu/ trusty-updates main restricted
    -bash: deb: command not found
    bumpy@my32bitbox:/$

    How can I delete all this? It's far too complicated for me.

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>