First for those who still haven't heard of the VServer project: It allows you to run Linux inside Linux: any distribution inside any distribution. Each virtual server has its own packages, its own services, its own users and is confined to using some IP numbers only and some area(s) of the file system. You can think of them as virtual machines.
For many people, virtual server may look like a great toy: Very high geekness factor. It looks cool, but probably not for everyone. Wrong!
Believe me this will change a lot, but once you figure it out you will never look back. Here are some ideas
A) Many Tasks on the same Box
As the hardware evolves, it is tempting to put more and more tasks on a server. Linux can handle it. Linux is reliable and so on. At some point, you end up with so much stuff and so many people fiddling in the same box that you worry about updating things.
Vservers address this. The same box runs multiple vservers and each one does the job it is supposed to do. If you need to upgrade to php5 for a given project you do so and only tha project is affected.
Also, you can give the root password of a vserver to one administrator and he will be able to perform updates, restart services and so on without having to know about every other project hosted on a server.
B) Resource Independance: Moving vservers
Since vservers are only guests on the hardware they are using, they are not aware of the specifics: They do not contain disk configurations, kernels or network configurations.
Once you have found that a project is using more resource than expected, you can move it to another box without having to fiddle here and there. A vserver is just a directory inside the host server. You tar it and copy it to another box and restart it there.
An administrator can move vservers around without his users knowing what he does.
C) Experimenting and Upgrading.
You have this typical problem. You intend to upgrade a site either with new package (new PHP5) or new features (new version of the Web applications). After having tested all this on the development machine, you are ready to update the production server. Having some experience you do it properly
We have all experienced this. Another solution to this problem would be to install the new production server on new hardware, but this is not as easy, as you have to clone the first server (most people are not confortable doing this) or you do not have the hardware.
Using vserver, all this is very easy
Later you find it does not work as expected and you can't immediately fix it.
You are working on a new project. At this point you have no idea of the resources it will need (load). In general, you have a meeting and make a decision about the new hardware. But in this case we have no idea. So instead, we put the new project on a vserver on the first available linux box, including the workstation of the developer. And we develop. Once the thing is ready, we clone the vserver on some production server and give it a go.
Later once we know how popular the new service is, we can move it again to a more powerful server, as needed, without any fiddling (moving accounts, installing packages, and so on)
As a good example, Herbert has 33 vservers on his notebook allowing him to test various projects and various distributions from rh6.2 to FC3 and Debian.
E) Distribution Independence
We are often talking about our preferred distribution. Should we use FC, Debian or something else ? Should we give a spin to the latest and greatest ?
With vservers, the choice of a distribution is less important. When you select a distribution, you expect it will do the following
The choice is important because every service running on a box will be using the same distribution. Most distributions out there are good and reliable. But they have flaws. For example, a distribution - say XXX - is great but is not delivering the latest and greatest PHP. Now because you have decided to use XXX for some projects, it does not prevent you from using XXY for other projects. So instead of moving to XXY for everything, you move to it as you see fit, project per project.
Takes few hours to investigate vservers, you will never look back.