[lxc-devel] Questions about lxc.autodev

[Stéphane Graber]

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.

> 
> > the same path for privileged and unprivileged containers and avoid the
> > ugly lxcpath hash.
> > 
> > 
> > I believe the following setup would make a bit more sense and offer a
> > consistent behaviour:
> >  - If not available or not a tmpfs, create LXC_PATH/<container>/dev and
> >    mount a tiny tmpfs on it. Chown the path to the container's root uid/gid
> >    and chmod to something sane.
> >  - For all the nodes we care about, attempt to mknod them in there, on
> >    failure, fallback to touch+bind-mount from real /dev.
> 
> The improved consistency is appealing.
> 
> > This would allow for the exact same code to be used for all 4 cases, for
> > the layout and location of the autodev tree to be entirely guessable
> > without requiring fancy hashing (making it easier for external tools to
> > interact with the autodev tree).
> > 
> > As with the current implementation, the tree wouldn't be flushed on
> > container reboot but it would on container shutdown.
> > 
> > 
> > Does the above make sense or am I missing something about the design of
> > current autodev?
> > 
> > Cheers
> > 
> > -- 
> > Stéphane Graber
> > Ubuntu developer
> > http://www.ubuntu.com
> 
> 
> 
> > _______________________________________________
> > lxc-devel mailing list
> > lxc-devel at lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-devel
> 
> _______________________________________________
> lxc-devel mailing list
> lxc-devel at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20150109/78702a6c/attachment.sig>