[Lxc-users] Proposal for an FHS-compliant default guest filesystem location

[Brian K. White]

On 11/8/2010 1:14 PM, Michael H. Warfield wrote:
> On Mon, 2010-11-01 at 08:40 -0500, Serge E. Hallyn wrote:
>> Quoting Walter Stanish (walter.stanish at saffrondigital.com):
>>> http://lxc.git.sourceforge.net/git/gitweb.cgi?p=lxc/lxc;a=commitdiff_plain;h=c01d62f21b21ba6c2b8b78ab3c2b37cc8f8fd265
>>
>> This commit only moves the location of the 'templates', which are
>> just scripts that install a guest fs.  It doesn't/shouldn't move
>> the location of the actual guest fs's.
>>
>>> Therefore I humbly propose:
>>>   - the establishment of /var/lib/lxc as the default top-level
>>> directory for guest filesystems
>
>> AFAICS we are still using /var/cache/lxc right now.  Which I like
>> better than /var/lib/lxc.  If it has 'lib' in the pathname, it should
>> have libraries!
>
> Actually, I would beg to differ with you on that since it's in /var and
> that's where system applications write and store data.  Libraries
> (meaning linked libraries, dynamic and static) should be under /usr
> or /lib since they are not generally written to.  You could have
> libraries in there, I suppose, but I would not consider that the safest
> place for them and most of what you find there is not libraries, unless
> you mean "libraries" in the sense of "libraries of files" as in a
> "collection of files", which is another sense of the word.  But then,
> that would certainly be an applicable location for the machine
> configuration files as now.
>
> Mailman is another example application which keeps most of its python
> code under /usr/lib/mailman while longer term storage of lists,
> archives, and databases are stored in /var/lib/mailman.
>
> Samba is another fine example of this and, in fact, we (the Samba team)
> and the distros moved away from using /var/cache/samba for things like
> the tdb databases and storing extraneous data such as Windows device
> drivers the server can serve up.
>
> Personally, I like and use /srv/lxc for my VMs and don't see any
> conflict with the FHS.  It is, after all, a site local configuration
> sort of thing that gets set up when you build the images and comprises,
> potentially, entire FHS-like sub hierarchies for the VMs.
>
>>>    (eg: /var/lib/lxc/<guestname>)
>>>   - all use of /etc/lxc/<guestname>/rootfs should be considered deprecated
>
> For the cgroup mount point, I've been using /var/lib/cgroup and I think
> (believe) that was the consensus of a discussion quite some time ago and
> is what's recommended in some howtos.  For the container mount-points
> and storage of the registered configuration files(s), /var/lib/lxc works
> just fine and would be in agreement with the strategy if /var/lib/cgroup
> for the cgroups, IMHO.

Why in the world would you want to break the ability to safely back up 
just /etc and know that you got practically everything needed to 
re-create a server without having to back up the entire server full of 
redundant junk that would be better to come from new install media?

Yes there are already special cases that break this assumption but they 
are few and should be reduced and avoided not embraced and increased.

I have rsync/backup scripts that just grab /etc, /home, /srv, and a 
couple application specific data dirs, and this not only makes my 
backups (and restores, and migrations, and clones) small and fast, it 
makes it easier to move to newer versions of the distribution, different 
cpu platforms, and even different OS's.

I'd like config files in /etc/lxc/<guestname>/config just like most 
other things work.

/srv/lxc sounds good to me for the rootfs's for the same reason I want 
/etc/lxc for the configs.

cgroups is another issue.
/cgroup makes sense because of /proc /sys /dev etc, but there are also 
/dev/pts and /sys/kernel/debug etc so mounting kernel virtual fs's on / 
is not universal.

I think, just talking about the undifferentiated (distribution agnostic) 
default here, it might make sense to have a lxc-specific cgroup mount 
point in one of:
/var/run/lxc/cgroup
/var/lxc/cgroup
This way lxc can organize itself and tend to it's own needs without 
caring how/where/if the distribution mounts a generic system cgroup fs 
or not. Your lxc start/stop/status scripts can safely know the location 
of the mount, and can safely write the notify/release options and/or 
delete the unused cgroups itself and/or lxc-stop/start could manipulate 
them itself safely too.

And the expect and encourage most distributions to override that with 
their particular system wide generic or separate cgroup mount points 
organized according to their particular design principles.

The special empty directory for the pivot_root mount point should 
probably be in /usr/lib/lxc as was discussed some time ago. (I don't 
remember if that's what was decided, just that it was discussed)

-- 
bkw