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