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 ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ Lxc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lxc-users
