[lxc-devel] [PATCH] c/r: rework external mountpoint handling v2

[Serge Hallyn]

Quoting Tycho Andersen (tycho.andersen at canonical.com):
> On Wed, Apr 15, 2015 at 04:19:54PM +0000, Serge Hallyn wrote:
> > Quoting Tycho Andersen (tycho.andersen at canonical.com):
> > > On Wed, Apr 15, 2015 at 03:48:10PM +0000, Serge Hallyn wrote:
> > > > Quoting Tycho Andersen (tycho.andersen at 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.