On Wed, Apr 15, 2015 at 04:39:10PM +0000, Serge Hallyn wrote: > 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.
Ah, good point. > > 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. Actually it might be me misunderstanding. I thought lxcapi_checkpoint was run from the monitor process, but I just realized that it's not. Sorry for the noise. Tycho > 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 _______________________________________________ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
