[lxc-devel] Questions about lxc.autodev

[Serge Hallyn]

Quoting Stéphane Graber (stgraber at ubuntu.com):
> On Fri, Jan 09, 2015 at 05:04:27PM +0000, Serge Hallyn wrote:
> > Quoting Stéphane Graber (stgraber at ubuntu.com):
> > > Hello,
> > > 
> > > So I'm looking into how to rework lxc.autodev to apply properly to all
> > > the cases we care about:
> > >  - Privileged containers started by root
> > >  - Unprivileged containers started by privileged root
> > >  - Unprivileged containers started by unprivileged root
> > >  - Unprivileged containers started by unprivileged user
> > > 
> > > My understanding is that autodev currently creates /dev/.lxc and then
> > > uses one directory per-container+lxc-path-hash under there, creates the
> > > devices nodes and uses that as the container's /dev.
> > > 
> > > My question is why the /dev/.lxc directory to begin with, wouldn't
> > 
> > Ok, after looking back through the code a bit,
> > 
> > One advantage of the current method is that it doesn't need to use a
> > tmpfs per container.  If the host uses devtmpfs (which most do)
> > then /dev/.lxc can just be a subdir, otherwise it needs to be the
> > single tmpfs mount.  This ensures that systemd will see a separate
> > /dev and be happy.
> > 
> > Another advantage of the current method is that the host can see
> > the container's /dev more easily.  Though I htink the existence
> > of lxc-device suggests that we're ok.  I mainly don't want to do
> > anything that makes it harder for our eventual implementation of
> > forwarding hotplug events into containers (as per the presentation
> > at plumbers)
> > 
> > > it make more sense to use LXC_PATH/<container>/dev, mount a tiny
> > > tmpfs on that and then use it? This would have the advantage of having
> > 
> > I guess one question is whether we think one more mount per container
> > can become a scalability issue.
> > 
> > Second question is whether systemd is happier if it sees that /dev is
> > on devtmpfs.
> 
> I've been using regular tmpfs for a while now with systemd and it's fine
> with it. I don't believe it treats devtmpfs any differently than tmpfs.

Cool, thanks for that info.