I wanted to point out a couple of good uses for vservers other than for hosting. (Obviously, I think they rock for hosting, but that's a different story.)
First, a little background. The Linux vserver project (http://www.linux-vserver.org) involves a patched kernel and some userspace tools for managing vservers. The result is servers that essentially behave like native linux (in just about any flavor) except that they can't interact with the kernel or reconfigure the hardware. There's essentially no performance hit, unlike vmware, since you just run one kernel.
Pros: Each vserver behaves for most purposes like an isolated server. Each developer on a shared server can have be root in his/her own vserver. Different versions of just about everything? No problem. Want to dist-upgrade debian today? Sure, why not?
Most applications work out-of-the-box. Vservers look and feel exactly like a 'real' server, until you really kick the tires.
Cons:
-Extra disk space. There are some file unification options, but you *will* need more disk.
-You do have to build a kernel, and if you want a vserver flavor that you can't find a build script for, it can be finicky to set the first one up. If you haven't built a kernel before, don't try it on a remote server! (What do you mean I forgot to compile in the network drivers? ARGH.)
-Some things (like IPTables) only work in the parent server.
-Each vserver needs an IP address.
Things I like vservers for:
Development-ish stuff:
- isolated development environments. You can spawn an exact duplicate of your production server and upgrade/change/etc without risking the production server. (You can change glibc for kicks, and if you don't like the results, just delete the vserver. All the "I wonder what would happen if..." questions are suddenly much safer to answer.)
- since vservers can be exact clones, no issues with discrepancies in libraries, permissions, etc.
- simulate distributed systems.
Production-ish stuff:
- Small now, big later: Put AOLserver in one vserver, postgreSQL in another. When you're ready to split into two physical servers, just rsync one vserver to the new machine. Vservers are very easy to relocate. You don't even have to pg_dump. Also useful for upgrading to a beefier machine. Build a kernel on the new machine, rsync the vserver, and start it up. (Ok, test, test, test first.)
- Keep a backup of your site ready to go, just in case. If your production site lives in a vserver, having a backup of the whole vserver allows you to put the backup online as quickly as you can get AOLserver to start, if something happens to mess up your install.
- run services in separate vservers for security. An attacker who gets into one vserver doesn't automatically get the whole machine.
Aside: there's nothing more annoying than knowing you checked in those bug fixes on _some_ development vserver, that you might or might not have deleted already. A centralized CVS repository (running in a vserver..?) is a good idea.
Anyway, I think they're really useful. More information at http://www.linux-vserver.org if anyone wants it.
