CRIU

Most low-level software engineers that have an interest in new technologies will probably already know what this post is about: checkpoint/restore in userspace. But this post is – unlike most posts about this technology – not aimed at low-level software monkeys like me. I would rather like to have people outside of academia and engineering understand what CRIU is and why it is one of the most exciting technologies in recent years.

Imagine having an important program running, I mean a program so important that taking it down is unthinkable. Think about a program that manages your bank account, all your precious, precious finances. It would be a shame if it would go down and all the runtime information associated with that program is now lost.

Runtime information is basically that part of a running program that is very volatile. Meaning, this information is usually lost when the program stops or crashes unexpectedly. Some of this information though can be very vital and important to someone. I’m using this term loosely here. Runtime information in that sense is anything that e.g. has not yet been written to disk. Information that somehow is not yet safe in any way. Think of it as having a very heavily loaded paper bag with all your groceries. You have no choice but to carry it all in this bag but until you set down that bag on your table at home to unpack it this thing could rip at any moment. Runtime information might be information such as the last financial transactions from a big banking deal you just struck. What if you need to evacuate that program because there’s an impending hardware failure or you’re worried that you need to restore it somehow with all the given state this program carries at a specific point in time – all the precious runtime information. There aren’t a lot of ways to achieve this.

The funny thing is that this very simple problem I tried to describe is one that actually a lot of companies have. Take all the replication or saving to disk and backups that you need often this is still not enough. You might still need to touch that program while it is running in a very sensitive way which might cause it to crash and then the runtime information will be lost. You may be able to restore it but think about a heavy program that needs to now reinitialize a database, restore from a bunch of backups and come back to the point of execution it was at before the crash to continue operation. Sure, 5 minutes doesn’t sound like a lot but 5 minutes not serving paycheck information for a couple of big companies and you’d be surprised how fast a seemingly minor annoyance becomes a major crisis.

But what if you could literally snapshot a running program with all its state dump that state to disk and on crash restore that program to the exact point of execution it was before it crashed. You guessed it CRIU allows you to do it. Even better you can live migrate a program while it is running. Think about a machine that is about to fail or has to be taken down. CRIU would let you send that program from one machine to another without stopping it. Think about how crazy ingenious this actually is and what engineering feat. It’s like moving your whole household from somewhere in Europe to Japan without a single thing being changed or lost.

CRIU is a cross-company effort with strong ties to academia and research. I’ve had the pleasure of getting to know a lot of the guys who are developing CRIU not just are they extremely nice and competent, the work they have done is absolutely impressive: from an engineering perspective and from actual potential for real-world impact.

—

Finally, here’s some more technical insight into CRIU by a friend of mine you might enjoy:

Tycho Andersen: Live Migration of Linux Containers

CNI for LXC

This was definitely needed! Thanks.

S3hh's Blog

It’s now possible to use CNI (container networking interface) with lxc. Here is an example. This requires some recent upstream patches, so for simplicity let’s use the lxc packages for zesty in ppa:serge-hallyn/atom. Setup a zesty host with that ppa, i.e.

sudo add-apt-repository ppa:serge-hallyn/atom
sudo add-apt-repository ppa:projectatomic/ppa
sudo apt update
sudo apt -y install lxc1 skopeo skopeo-containers jq

(To run the oci template below, you’ll also need to install git://github.com/openSUSE/umoci. Alternatively, you can use any standard container, the oci template is not strictly needed, just a nice point to make)

Next setup CNI configuration, i.e.

cat >> EOF | sudo tee /etc/lxc/simplebridge.cni
{
  "cniVersion": "0.3.1",
  "name": "simplenet",
  "type": "bridge",
  "bridge": "cnibr0",
  "isDefaultGateway": true,
  "forceAddress": false,
  "ipMasq": true,
  "hairpinMode": true,
  "ipam": {
    "type": "host-local",
    "subnet": "10.10.0.0/16"
  }
}
EOF

The way lxc will use CNI is to call out to it using a start-host hook, that is, a program (hook) which…

View original post 137 more words