Quoting Tycho Andersen (tycho.ander...@canonical.com): > On Wed, Apr 15, 2015 at 04:19:54PM +0000, Serge Hallyn wrote: > > Quoting Tycho Andersen (tycho.ander...@canonical.com): > > > On Wed, Apr 15, 2015 at 03:48:10PM +0000, Serge Hallyn wrote: > > > > Quoting Tycho Andersen (tycho.ander...@canonical.com): > > > > > CRIU now supports autodetection of external mounts via the > > > > > --ext-mount-map auto > > > > > --enable-external-sharing --enable-external-masters options, so we > > > > > don't need > > > > > to explicitly pass the cgmanager mount or any of the mounts from the > > > > > config. > > > > > This also means that lxcfs mounts (since they are bind mounts from > > > > > outside the > > > > > container) are autodetected, meaning that c/r of containers using > > > > > lxcfs works. > > > > > > > > > > A further advantage of this patch is that it addresses some of the > > > > > ugliness > > > > > that was in the exec_criu() function. There are other criu options > > > > > that will > > > > > allow us to trim this even further, though. > > > > > > > > > > Finally, with --enable-external-masters, criu understands slave > > > > > mounts in the > > > > > container with shared mounts in the peer group that are outside the > > > > > namespace. > > > > > This allows containers on a systemd host to be dumped and restored > > > > > correctly. > > > > > > > > > > However, these options have just landed in criu trunk today, and the > > > > > next > > > > > tagged release will be 1.6 on June 1, so we should avoid merging this > > > > > into any > > > > > > > > Ouch, June 1, that's a ways away. > > > > > > > > > stable releases until then. > > > > > > > > Should there be a lxc_check_criu_version() fn, updated in cases like > > > > these, > > > > which ensures that criu is new enough version for the lxc version? > > > > > > Yes, I was thinking about this, the only question is how to detect it; > > > I can fork() and just pass --version, but then on every checkpoint or > > > restore we have an extra fork() in the critical path. Unfortunately, I > > > > The critical path of checkpoint/restore? Isn't that as speedy as mollasses > > now? > > A fair point :) > > > You could also cache the result in a global variable (-1 by default) > > so only the first lxcapi_checkpoint or lxcapi_restart will invoke the > > penalty. > > Right, but in the case of e.g. checkpoint it will only ever be called
That's "/usr/bin/lxc-checkpoint". But something like lxd using the lxc API may benefit. > once, because as soon as you invoke checkpoint the monitor process Oh I was thinking the check would be done in the lxcapi_checkpoint, not in the container monitor. Maybe I'm misunderstanding the current c/r architecture. Note also that when criu development slows down we can probably drop that check. _______________________________________________ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
