From: Jacques Gelinas (jack_at_solucorp.qc.ca)
Date: Wed 24 Oct 2001 - 07:00:18 BST
On Tue, 23 Oct 2001 23:00:49 -0500, Rik van Riel wrote
> I'm absolutely impressed by vserver. It is simple, effective
> and redicilously easy to figure out. It took me a full 5 minutes
> to setup a vserver and that was mostly because I didn't read the
> documentation before starting ...
It's adictive...
Lately, I was in a meeting talking about backup strategy and crash
recovery. I could not stop myself and told "Well if all our server
are vservers, we can have a backup server which can take
over any server without re-configuration"
I sometime put vservers in my coffee...
> One minor nitpick, 'vserver <foo> build' could use 'mount --bind'
> on the 2.4 kernels; this would save both disk space and memory use,
> and 'mount --bind' also accepts options like read only mounts so
> root inside the vservers cannot mess with the files.
The problem here is granularity. What do you want to share between
vservers: /usr, everything, ...
We came with a different solution and Sam Vilain puts the final touch on this.
We are using hard links with the vunify script. Basically, for a given package
say glibc, vunify identifies all the files, other than config file and establish
a hard link between one vserver and a reference vserver. Just doing that
with glibc, perl, binutil and bash and you save 60 megabytes (or more, this
was tested on a rh6.2 vserver). Then vunify puts the file immutable
so you end up with a safe sharing.
Ultimatly, vunify will be changed to unify every common RPM. So you will
end up saving lots of disk space. You can think of 50megabytes per vserver.
Further, you will gain performance since all those binaries and shared objects
will be effectivly shared in memory (same inode).
But there is a flaw. This is good if your vservers are all running the same
package and the vserver administrator is always you. Now if one vserver
needs a new package, you must un-unify the package (vunify already
handles that), but the vserver administrator can't do it (He does not
have the capability to operate on the immulable bit).
Sam came with a very simple solution: Another bit. The first one is now
called immutable_file and the other is immutable_linkage. Combined
together, you can make sure a vserver is
-sharing files to save space and gain performance
-can't modify those files
-can delete (or not) those file, so an RPM update
do work.
Sam contribution can be found at http://sam.vilain.net/immutable
---------------------------------------------------------
Jacques Gelinas <jack_at_solucorp.qc.ca>
vserver: run general purpose virtual servers on one box, full speed!
http://www.solucorp.qc.ca/miscprj/s_context.hc