From: Alec Thomas (lists_at_swapoff.org)
Date: Thu 08 Apr 2004 - 02:53:34 BST
Sam,
I use the same method of one LV per vserver, but haven't bothered to do
the unification. I for one would welcome this addition.
Regards,
Alec
On Thu, Apr 08, 2004 at 12:17:56PM +1200, Sam Vilain wrote:
> Enrico Scholz wrote:
>
>
> * it has new vserver-build methods; currently the apt-rpm, debootstrap and
> a simple skeleton methods are implemented. New methods are in preparation
> (copy) or are waiting for community input (gentoo, slackware). For RPM
> based distributions, 'vapt-get' and 'vrpm' tools were written which are
> allowing a secure external packagemanagement.
>
>
> Allow me to throw mine into the fold, then; these additions let you have each vserver on a seperate filesystem, whilst still having the benefits of
> unification; all changes are in /usr/sbin/vserver:
>
> STATIC_DIRS="usr lib sbin bin"
> UNIQUE_DIRS="etc var"
>
> mountproc()
> {
> mkdir -p $VROOTDIR/$1/proc $VROOTDIR/$1/dev/pts
> if [ ! -d $VROOTDIR/$1/proc/1 ] ; then
> mount -n -t proc none $VROOTDIR/$1/proc
> mount -n -t devpts -o gid=5,mode=0620 none $VROOTDIR/$1/dev/pts
> fi
> if [ -d $VROOTDIR/shadow/$1/usr -a ! -d $VROOTDIR/$1/usr/bin ]
> then
> for dir in $STATIC_DIRS
> do
> [ -d $VROOTDIR/$1/$dir ] || mkdir $VROOTDIR/$1/$dir
> mount -n --bind $VROOTDIR/shadow/$1/$dir $VROOTDIR/$1/$dir
> done
> fi
> }
> umountproc()
> {
> umount $VROOTDIR/$1/proc 2>/dev/null
> umount $VROOTDIR/$1/dev/pts 2>/dev/null
> if [ -d $VROOTDIR/shadow/$1/usr ]
> then
> for dir in $STATIC_DIRS
> do
> umount $VROOTDIR/$1/$dir 2>/dev/null
> done
> fi
> }
>
> # ... later on, during `vserver XXX build' code:
> if test "$UTIL_VSERVER_AVOID_COPY"; then
> mkdir -p $VROOTDIR/$1/{etc/rc.d/init.d,sbin,var/run,var/log}
> else
> MASTER=/
> [ -d $VROOTDIR/master ] && MASTER=$VROOTDIR/master
> echo "Copying files from $MASTER"
> if [ -d $VROOTDIR/shadow/master ]
> then
> ( cd $VROOTDIR/master;
> cp -ax $UNIQUE_DIRS $VROOTDIR/$1/. ) || exit 1
> echo "Linking files from $VROOTDIR/shadow/master"
> mkdir $VROOTDIR/shadow/$1
> ( cd $VROOTDIR/shadow/master;
> cp -a $STATIC_DIRS $VROOTDIR/shadow/$1/. &&
> cd $VROOTDIR/shadow &&
> $USR_LIB_VSERVER/unify-dirs -il master $1 ) || exit 1
> mountproc $1
> TMP_MOUNT=1
> else
> ( cd $MASTER &&
> cp -ax $UNIQUE_DIRS $STATIC_DIRS $VROOTDIR/$1/. ) || exit 1
> fi
> fi
>
> This all stems from a vague, possibly irrational urge that each vserver should have its own filesystem, rather than letting many vservers share the same
> filesystem and using quotas or a similar mechanism to restrict them. This is convenient for me, as I use reiserfs (the masochism of which pales in comparison
> to the bugs in the ext3 online resizing patches) on LVM managed space, so I can allocate vservers more space as and when required, and have protection against
> possible fragmentation between servers (of course, the widely touted "fact" that Unix filesystems don't suffer from fragmentation may be true, but they're not
> immune to it).
>
> To explain the above in excruciating detail:
>
> * It is assumed that the `master' vserver, in /vservers/master, has its /usr, /lib, /sbin and /bin moved to /vservers/shadow/master. This filesystem will
> contain the operating system files (ie, the four directories mentioned) for all vservers which are `shadowed'.
> * during build time, the new server has /{usr,sbin,bin,lib} copied via a `cd /vservers/shadow; cp -al master/* $vserver/; chattr -R +iI $vserver' analog, if
> those directories have been moved out of /vservers/master to /vservers/shadow/master in the skeleton.
> I'm using a straight copy, followed by a call to my unify-dirs script (which, hopefully, your new vunify is powerful enough to emulate the behaviour of
> without all the segfaults) - which is sub-optimal - a `vcp-al' would be useful - but works for me.
> The other directories (/var and /etc) are simply copied into the vserver's filesystem.
> * during `vserver start' time, if the shadow operating system directories are detected on /vservers/shadow/$1/*, then mount them into place with mount --bind.
> * Maintaining the unification is as simple as (cd /vservers/shadow; unify-dirs -il *)
>
> This is quite effective; even with a lot of software installed in the master image, you only need about 30MB of space on the filesystems you create as a
> minimal starting point for Debian woody vservers. And most of that is the `apt' and `dpkg' databases.
>
> This is all extremely groovy if you have an automatic script that runs the other associated stuff;
>
> lvcreate -L 100M -n myVserver /dev/myVG
> mkreiserfs /dev/myVG/myVserver
> echo "/dev/myVG/myVserver /vservers/myVserver reiserfs defaults 1 69" >> /etc/fstab
> mkdir /vservers/myVserver
> mount /vservers/myVserver
>
> I've had `vserver build' using the above technique building new vservers in *3 seconds* (not counting the mkreiserfs time) in the past.
>
> Would this be a welcome enhancement if brushed up for the current util-vserver release?
>
> --
> Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13
> (include my PGP key ID in personal replies to avoid spam filtering)
>
-- Evolution: Taking care of those too stupid to take care of themselves. _______________________________________________ Vserver mailing list Vserver_at_list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver