From: Sam Vilain (sam_at_vilain.net)
Date: Mon 25 Nov 2002 - 12:50:19 GMT
> Nope, it does not seem reasonable. Only drawback of using LVM for
> vservers is, that you cannot unify the servers, ...
> OTOH, you get a per vserver quota, that you can change while the server
> is online. With hotpluggable discs (scsi, firewire, usb2.0 come to mind)
> you can even add storage space online, ...
I think the best solution is to unify the /usr filesystem, and potentially
other directories where there might be binaries which would benefit from
unification (/lib, /sbin, etc). Everything `local' to a virtual server is
put in on a per-vserver filesystem on the LVM - especially /usr/local (make a
symlink to /opt/local), /home and /var.
So you'd have:
/vservers - an ext2 LVM filesystem with unification
/vservers/vs1 - non-unified LVM filesystem (any type)
/vservers/vs1/usr - loopback mount to /vservers/shadow/vs1/usr
/vservers/vs1/lib - loopback mount to /vservers/shadow/vs1/lib
/vservers/vs1/... - loopback mount to /vservers/shadow/vs1/...
/vservers/shadow/vs1 represents VS1's `shadow' of the unified filesystem. `cp
-al' can be used quite easily to make new vservers (fast, too - spawn a new
vserver in seconds).
You can use the unify-dirs script then to unify them easily and in smaller
chunks (the script is admittedly very memory-hungry when processing large
numbers of files).
Sam.