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

[Tycho Andersen]

On Wed, Apr 15, 2015 at 04:39:10PM +0000, Serge Hallyn wrote:
> 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.

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 at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel