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