[lxc-devel] LXC live migrate

[Dwight Engen]

On Mon, 25 Nov 2013 21:58:13 -0500
Stéphane Graber <stgraber at ubuntu.com> wrote:

> On Tue, Nov 26, 2013 at 04:04:36AM +0200, Marian Marinov wrote:
> > Hey guys,
> > I just read on LWN about the checkpoint/restore tool:
> >    http://lwn.net/Articles/574917/
> > 
> > With this, it seams possible to freeze and restore a whole
> > container from one node to another.
> > 
> > I'll give it a try this week to give more details on how it
> > actually works.
> > 
> > Marian
> 
> I think I last tried it with CRIU 0.8 without much success but I took
> an action item during Ubuntu's planning even last week to try with a
> newer release and get in touch with Pavel if I'm still having issues.

Hi all,

I also started looking into this (just trying to dump a simple busybox
container) and the first thing I ran into is that criu can't dump
init's fd 0 -> /dev/zero. I believe this is because that inode is
outside the container (ie. its the hosts' /dev/zero). I'm looking into
having lxc_start open std[in,out,err] in do_start after it has cloned
into the namespace. This means the container would have to have
a /dev/zero and /dev/null.

> From what we discussed at Linux Plumbers, CRIU should indeed let you
> dump a full container and restore it on the same machine or on another
> so long as the filesystem and any other external dependency of the
> container matches.
> 
> If I can get this working and they've resolved a few of the known
> issues (specifically the fact that it'd only build on x86_64), then
> the plan is to add API calls to LXC's API that'll implement the
> checkpoint/restore feature using CRIU.

Assuming we can get it to work, I think we'd rather link to some sort
of libcriu than to system() out to criu? If that is the case I think
we'll need to do a bit of packaging work to make such a lib in crtools.