[CRIU] p.haul and lxc

Tycho Andersen tycho.andersen at canonical.com
Thu Nov 13 13:06:19 PST 2014


Hi all,

I've been looking p.haul a bit and thinking about how we might improve it for
use with lxc. Based on my read of the code, I think there are two conceptual
changes that would be needed:

1. We need to add incremental dump support to lxc-checkpoint, so that p.haul
   can shell out to lxc-checkpoint, instead of calling criu directly. This
   means that p.haul doesn't need to know about lxc internals (e.g. how veths,
   ttys are set up and configured) in order to do its thing.

2. We can get rid of any p.haul specific handling of cgroups for lxc, since
   these can be restored via criu and lxc-checkpoint and lxc-checkpoint will
   try to do the right thing w.r.t. multiple containers with the same name or
   any other cgroup collisions.

This would require a slight architectural change, since lxc-checkpoint is
setuid and execs criu, rather than using the service. However, since the
service mechanism is just to get around this problem, I think it should be ok.

Another question is what to do about rewriting the images. Based on our last
thread, we decided that in-process (e.g. while criu is restoring) rewriting is
most efficient, so we want to pass some --crit-flags to criu to tell it how to
rewrite things. Is p.haul the thing that would decide how to rewrite e.g.
cpusets, or would that be at some higher level?

Finally, a minor conceptual change is that it would be nice to be able to set
up the channel that p.haul communicates over (e.g. a TLS socket or so), vs.
just having p.haul do a connect() over a raw socket. If nothing else, I think
we can just implement some other version of the `rpc_proxy` class to do this.

Do these sound reasonable? Does anyone have any thoughts?

Thanks!

Tycho


More information about the CRIU mailing list