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

Walter Stanish walter.stanish at saffrondigital.com
Mon Nov 8 18:31:36 UTC 2010


Glad to see some further discussion.

> 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.

The thing is, the FHS does say "no program should rely on a specific
subdirectory structure of /srv existing or data necessarily being stored
in /srv" which makes it a poor choice for example when considering
eg: the default directory to deploy "lxc-create -T <type>" template script
generated guests to. Handling 10,000 what-ifs in bash isn't super
enjoyable... if things go down the 'make it ultra configurable' path
(not a bad thing) then perhaps we need to mature the template scripts
to use a shared library of bash functions...

Services that are more daemon oriented do have no problem
reconfiguring their default path, however for lxc-utils this information
is presently distributed throughout a number of places, some of
which are ignored or overwritten by various distributions' packages,
it becomes somewhat harder to manage 'on the fly' reconfiguration...

That's what originally prompted this post, actually.

So while /srv could work, I do think /var is more suitable in this case.

> > >   (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.

References please?

Judging from the existing /dev /sys and /proc mounts, anything kernel-centric
that is going to become a base-expectation in future should probably not
reside in /miles/of/subdirectories/that/are/potentially/mounted/later/in/the/boot/process/than/real/root/thereby/causing/untold/issues

Hope you can understand my point ... basically if you've mounted /cgroup
then you're set.  If you've mounted /var/lib/cgroup then want to (re)mount /var
you have issues...

> 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.

Personally I see lxc.conf more suited to /etc/lxc/guestname.conf or
/etc/lxc/guestname/lxc.conf but it's very much a dont-really-care
scenario.  /etc would be the traditional option.  And since we are talking
about virtualising an entire system, it's not without precedent to
segregate the configuration information and the filesystem (eg: VMware
installs often do this), eg: by leaving config in /etc/lxc/* and filesystems
elsewhere.  IMHO.

- Walter




More information about the lxc-users mailing list