So they have some prototype of the OS kernel, releasing it under non-commercial free license?
It has just occurred to me that a guy named Linus Torvalds did the same back in 1991, releasing an OS kernel called Linux under a free, strictly non-commercial license. He later got the clue and changed it to GNU GPL.
Apparently Microsoft is 17 years behind; will they get the clue? I doubt it.
See what the problem is -- a provider can oversell, and they oversell, sometimes way too aggressively. As long as you are not the owner of a physical server, you can not do anything about it but buy from more sane provider. This has nothing to do with the technology itself. As for technology, see the HP labs evaluation.
In fact, free OpenVZ has most of what you tell about VMware. Live migration is here, and it does not require to have a SAN or a dedicated NIC, or pay for vmotion. High availability with clustering can be set up (see here). And finally, you don't have to pay a performance penalty if you want virtualization.
The commercial product based on OpenVZ (i.e. Virtuozzo) has all that plus web-based and gui management tools, P2V migration tools etc. etc.
It also makes sense to point out that Xen also has a live migration feature, although I haven't tried it.
my hosts migrated to a Xen3 machine and I must say the speed *increase* was quite impressive
This probably relates to the fact that people usually run 5-20 Xen guests and 50-200 OpenVZ VEs on the same box.
that was running with less physical RAM allocated, and more swap
In OpenVZ, you should not take a look at what free or cat/proc/meminfo shows you -- instead you have to take a look into/proc/user_beancounters to see how much RAM etc. you have.
Xen trades off performance for much better isolation and security.
I guess I have to correct you here. Xen trades off performance for an ability to run different kernels, and this has nothing to do with either isolation or security. So, Xen is good when you want to run different kernels (different OSs).
OpenVZ, on the other hand, employs a single kernel model, which makes it suitable for you if you only want to run Linux (different distros are possible, different kernels are not). But in this very field OpenVZ is way better than Xen -- not only in terms of performance, but also scalability, manageability, density, and usability.
Speaking of isolation and security, OpenVZ runs on thousands of ISP/HSP servers, and everyone can buy a VE (Virtual Environment) for about 10-15 bucks a month. There one have a root account and can try to exploit the system in all the possible ways. So far those HSPs are not out of business yet, that practically proves the system is secure and properly isolated. More to say, security comes from the constant care, and we (OpenVZ team) do care for security a lot, see this blog entry for some more details.
Let me answer this way:
Show me a single exploitable security hole in OpenVZ, or the way for a VE to do a Denial-of-Service for other VEs (i.e. the case of improper isolation) -- when we'll talk.
OpenVZ is ok if all of your child environments run the same OS and you don't care about them stealing each other's resources.
OpenVZ isolates VEs from each other pretty good, unless you misconfigure it. The problem here is you can't configure the system properly (i.e. you oversell way too much). See this article to get the details on how to configure your system in a proper manner.
Here are some typical usage scenarios for OS-level virtualization; server consolidation is number one I believe. All that also applies to Xen and VMware (although their overhead in those cases would be higher); in addition, they can run *different* operating systems on the same box -- this is what OpenVZ don't do.
OpenVZ is an OS-level virtualisation -- this is quite different technology from that of Xen and VMware. OpenVZ provides separate isolated containers within a *single* kernel image, while Xen makes possible to run *different* kernels on the same piece of hardware. More info about those differences is here; the only thing I want to add is VMware is moving into Xen direction.
Well, OS-level virtualization should have the best possible performance, leaving all the others behind. It's purely from the theory -- less overhead means better performance.
From the other side, speaking of testing practice, all tests are very error-prone. By tweaking some parameters here and there you can improve performance by, say, 10%, or make it fall behind. The bottom line is: do not ever trust the tests, do your own (and expect to spend a few months doing that).
You are right. There are other solutions available, and there will be more to come.
By the way, paravirtualization is quite different from OS-level virtualization (which OpenVZ and others do). For now, Xen is the only open source solution in the paravirt. area (other is VMware, there is also a patch from Rusty Russel to add an interface for hypervisors), while in OS-level virt. we have as many as four players, and at least two open source solutions. Who are those players and solutions? See below (taken from
OpenVZ blog). Why this is good? Because competition is good. Why it works and Xen does not? Because OS-level virt. is a less dirty hack than a hypervisor.
* Eric Biederman wants to have so-called namespaces in kernel. Namespaces are basically a building blocks of containers, for example, with user namespace we have an ability to have the same root user in different containers; network namespace gives an ability to have a separate network interface; process namespace is when you have an isolated set of processes. All the namespaces combined together creates a container. But, as Eric states, an ability to use not all but only selected namespaces gives endless possibilities to a user.
* IBM people (ex-Meiosys) want application containers, and for them the main purpose of such containers is live migration of those. The difference between app. container and the "full" (system) container is a set of features: for example, an application container might lack/proc virtualization, devices, pseudo-terminals (needed to run ssh, for example) etc. So, an application container might be seen as a subset of a system container.
* OpenVZ wants system containers that resemble the real system as much as possible. In other words, we want to preserve existing kernel APIs as much as possible inside a container, so all of the existing Linux distributions and applictions should run fine inside a container without any modifications. Of course, the goal is not 100% achievable, for example we do not want the container to be able to set the system time.
* Linux-VServer wants just about the same as OpenVZ, it's only that their implementations of various components are different, and their level of a container resembling a real system is a bit lower (for example, in networking).
Well, you can run different distros in different containers on the same system (yep, the kernel will be the same and in most cases it is not a problem). Really, I do not have problem running all the distros you mentioned (we haven't tried FC6 yet though...but I do not foresee any major problem here).
Speaking of security - all those HSP would went out of business very soon if VPSs they sell would be hackable. Also - if you have any knowledge about yet unclosed holes - security@kernel.org is a better place for it than doing a FUD on slashdot.
Speaking of containers usage -- it is not just for HSPs, it is mostly for the server consolidation. And in this scenario one usually does not need to mix different OSs on a singe box, just because one has 100+ of linux boxes and 100+ of other OS boxes -- so one consolidates those to, say, 40 linux boxes and 50 other os boxes.
Also note the maintainability of vmware vs. Containers. If you use vmware for consolidation -- you end up with the same number of servers to manage. In case of containers you can manage (i.e. apply a software update) all of them in parallel, it is not needed to login to each system.
Also note the dynamic resourse mgmt in containers. You can not increase the RAM amount for a VM while it is running - but it's a trivial thing to do for a container. Resizing a disk image online is also a problem with VMs - but just a matter of changing per-container disk quota.
I can continue this comparison, but the general idea is - if you do not require multiple kernels, using containers is much more efficient and (!) natural. And if you do want multiple kernels - you can actually mix two approaches, i.e. run containers inside a VM, and have the best of both worlds.
No, I am not trying to sell something -- OpenVZ is free software (free as in freedom). By the way, OpenVZ developers fixed a lot of bugs in mainstream, so they are rather fixing your kernel than fucking it up.
All of the OpenVZ code is #ifdef'd so if no appropriate options are selected the code is not compiled in.
Finally, you do not understand what containers are useable for...hmm I can try and give you some examples if you like. Basically, the same isolation/security that you'd rather use VMware for -- the only thing is with containers you do not have to pay performance penalty.
Also, containers are hardware-independent, they can be managed "en masse" (unlike VMware VMs), they can be live migrated from box to box. And in case you do not want to run different kernels -- containers are much better/efficient to use than full VMs.
Speaking of multiple root users on the box -- each and every HSP sells those cheap VPSs based on one of the existing implementation of containers. They sell it as cheap as $10/month or so -- and the root access is included. So go buy one and try to crack the system. I mean, please do not spread the "it's totally insecure" FUD if you do not have any real experience with that.
It hurts the same way that multitask operating systems hurt - there is definitely some overhead for task switching. Really, single task OSs gives more CPU to the task and thus are more efficient.
In multiuser operating systems there are a lot of checks for uids, gids etc.
Now the question - do we want multiuser and multitask OSs? Do we want ownership and permission checks on files? Do we want resourse limits (such as ulimit, disk quotas)?
That's a pity that a few talks about containers (OS-level virtualization, a la advanced Jails, a la Solaris Zones/Partitions) were not covered at all. There were (at least) four of them: - Eric Biederman's talk about namespaces - Cedric Le Goater's talk about application mobility (a.k.a. live migration of containers) - A BOF on containers, moderated by Dave Hansen - A BOF on the resource management (one of the components of containers), moderated by Dipkanar Sarma
There was also a half-an-hour discussion about containers on the Kernel Summit. Let me summarise all these in a few lines: 1. Containers are a real alternative (or a good addition) to Xen and paravirtualization. In most cases they can be used for same applications, without incurring all the Xen's overhead and dirty hacks) 2. Everybody wants containers in the mainstream kernel 3. There are different implementations (IBM's stuff, OpenVZ, Linux-VServer, and Eric's) and their developers need to agree upon them what to submit/push into mainline. This is hard to do, but a required step. 4. Resource management: User Beancounters from OpenVZ is a good (the only?) candidate for inclusion into mainstream.
Indeed, OS-level virtualization approach (as in Solaris Zones, Jails or OpenVZ) performance can not be beaten by para-virtualization approach just because OS-level virt. has the least possible overhead (and, say, does not have an overhead of running multiple kernels which both Xen and UML have).
If you run all the apps on the same box you gonna have problems. Here are just a few.
System-wide resources. There are some system-wide resources like the number of open files, number of sockets, IPC shared memory pages, physical memory pages, virtual memory pages, swap, number of processes etc. etc. Basically, any app can go mad and abuse one of those resources, rendering the whole system (and all the other apps) unusable. This is the most serious problem I believe. You can limit some of the resources -- like disk space, using per-user and per-group disk quotas -- but you can not control all of them. In contrast, in OpenVZ each VPS has a set of resource limits (and guarantees) and a VPS owner can not eat the whole box (unless configured to do so).
Users, libraries, distros. Different apps like different environments -- for example, app A requres library B version C. Not every application can run on every distro -- we have to face the truth. This is not a serious problem usually, but it arises sometimes. In OpenVZ you can have different sets of libs, different distros in different VPSs.
Security. Intruder hacked your old sendmail and got a local user. At the very least, he can now see the other processes and files. In some worse scenario he might find yet another hole and have a root user -- and all your apps are now had.
There are some other things like that as well. To conclude, virtual environment gives you the needed level of isolation between apps. Besides that, there are some added benefits -- like you can migrate your VE to another box without restarting your application(s)...
Well you might call it chrooting, but it is very advanced chrooting. No, even not like jail, much more advanced than that. Just read the article (and probably OpenVZ docs, too), or try it for yourself to see the difference.
> true isolation between nodes (with vservers other users can often bind to your ips etc)
No, in OpenVZ VPS you can not bind to somebody else's IP -- virtualized network is one of the differences between Linux-VServer and OpenVZ. Seriously, consider reading the interview itself -- it is mentioned there as well.
> resource limitation
Resource limiting, or, I'd rather call it resource management, because it is not just the limits but also the guarantees -- another big part of OpenVZ.
> ability to run differently-configured kernels, or even different operating systems
Indeed this is what OpenVZ or any other OS-level virtualization solution can not do, naturally. Still, I can not consider that requirement as a requisite condition for the technology to be called "virtualization".
Using OpenVZ or Virtuozzo, you can live migrate all your Virtual Environments (VEs) to another physical server before rebooting your box. "Live migrate" here means no need to reboot VEs, means no existing network connection will be broken etc. etc. After you've done your maintenance on the physical server (be it adding more RAM, or kernel upgrade, or switching from one distro to another -- you just migrate your VEs back. Also note that if another server has different NIC or SCSI controller -- you don't have to worry.
This (ability to do live migration and be independent of hardware) is just one little piece of functionality that OS-level virtualization provides.
OS-level virtualization approach (like OpenVZ) is not adding much overhead per se. So in case of proper planning it will work out right.
Speaking of proper planning, OpenVZ has a sophisticated resource management capabilities in kernel (and Virtuozzo provides GUI tools to manage that, among the other things). There exist a set of per-VE limits and guarantees (and guarantees are met in case you do not oversell).
I know some people who use Virtuozzo, OpenVZ or Linux-VServer to host a single VPS. This does not makes sense from the first sight, does it? What about the second?..
The idea is virtualization (OS-level virtualization) provides some benefits without sacrificing much of anything. So what it provides?
Virtual Environment (VE) do not depend on the hardware, so you can move a VE to another box without changing anything. Every sysadmin will love that. No need to edit/etc/fstab or/etc/modprobe.conf.
VE can be cloned. If you want to change something but afraid it will not work, you clone your VE and change the clone.
VE can be migrated to another physical server live (with no service outage -- to networked users it will be seen as a delay in response, not as any downtime). We are releasing this feature for OpenVZ this week.
In the term "OS-level virtualization" by "OS" they mean kernel.
So, in OpenVZ, it is kernel which provides those virtual environments, and you can have any app or any linux distro running inside that virtual environment (as long as stuff is compatible with the kernel; in OpenVZ case this requires distro which can be used on a 2.6 kernel).
Speaking of "recentness", current development branch of OpenVZ kernel is 2.6.16 based (here). You can actually use it, but we can not guarantee it is as stable and matured as the current stable 2.6.8-based kernel.
Speaking of technologies, you just can not achieve a level of density which you have in OpenVZ (VServer, Solaris Zones, etc.) with either Xen or VMWare.
Running multiple kernels is indeed a strange idea -- kernel is designed to be run on top of hardware; kernel is a piece of software to be used between hardware and application software. This is what Linux does, this is what Windows kernel does, this is what OpenVZ does.
If you run kernel on top of something else (VMware virtual machine, Xen hypervisor) you are gonna have problems. Let me give you just a couple of examples.
Say, each kernel caches the stuff read from (written to) disk. How can you unify that caching process if you are having multiple kernels? I do not say impossible, I say extremely tricky. Disabling cache is not an option - your performance will drop.
Say, you want to give more memory to your virtual server. In case of OpenVZ, this is just a single "vzctl set" command, no problems, you just raise the limits the same way you do for disk quota. But how can you explain the kernel running inside a VMWare or Xen what it can use more memory now? I do not say impossible, I say extremely tricky.
And there are a lot of dirty dirty hacks needs to be done to fix such stuff.
Slashdot Mirror
So they have some prototype of the OS kernel, releasing it under non-commercial free license?
It has just occurred to me that a guy named Linus Torvalds did the same back in 1991, releasing an OS kernel called Linux under a free, strictly non-commercial license. He later got the clue and changed it to GNU GPL.
Apparently Microsoft is 17 years behind; will they get the clue? I doubt it.
See what the problem is -- a provider can oversell, and they oversell, sometimes way too aggressively. As long as you are not the owner of a physical server, you can not do anything about it but buy from more sane provider. This has nothing to do with the technology itself. As for technology, see the HP labs evaluation.
In fact, free OpenVZ has most of what you tell about VMware. Live migration is here, and it does not require to have a SAN or a dedicated NIC, or pay for vmotion. High availability with clustering can be set up (see here). And finally, you don't have to pay a performance penalty if you want virtualization.
The commercial product based on OpenVZ (i.e. Virtuozzo) has all that plus web-based and gui management tools, P2V migration tools etc. etc.
It also makes sense to point out that Xen also has a live migration feature, although I haven't tried it.
I guess I have to correct you here. Xen trades off performance for an ability to run different kernels, and this has nothing to do with either isolation or security. So, Xen is good when you want to run different kernels (different OSs).
OpenVZ, on the other hand, employs a single kernel model, which makes it suitable for you if you only want to run Linux (different distros are possible, different kernels are not). But in this very field OpenVZ is way better than Xen -- not only in terms of performance, but also scalability, manageability, density, and usability.
Speaking of isolation and security, OpenVZ runs on thousands of ISP/HSP servers, and everyone can buy a VE (Virtual Environment) for about 10-15 bucks a month. There one have a root account and can try to exploit the system in all the possible ways. So far those HSPs are not out of business yet, that practically proves the system is secure and properly isolated. More to say, security comes from the constant care, and we (OpenVZ team) do care for security a lot, see this blog entry for some more details.
Let me answer this way: Show me a single exploitable security hole in OpenVZ, or the way for a VE to do a Denial-of-Service for other VEs (i.e. the case of improper isolation) -- when we'll talk.
Here are some typical usage scenarios for OS-level virtualization; server consolidation is number one I believe. All that also applies to Xen and VMware (although their overhead in those cases would be higher); in addition, they can run *different* operating systems on the same box -- this is what OpenVZ don't do.
OpenVZ is an OS-level virtualisation -- this is quite different technology from that of Xen and VMware. OpenVZ provides separate isolated containers within a *single* kernel image, while Xen makes possible to run *different* kernels on the same piece of hardware. More info about those differences is here; the only thing I want to add is VMware is moving into Xen direction.
Well, OS-level virtualization should have the best possible performance, leaving all the others behind. It's purely from the theory -- less overhead means better performance.
From the other side, speaking of testing practice, all tests are very error-prone. By tweaking some parameters here and there you can improve performance by, say, 10%, or make it fall behind. The bottom line is: do not ever trust the tests, do your own (and expect to spend a few months doing that).
You are right. There are other solutions available, and there will be more to come.
By the way, paravirtualization is quite different from OS-level virtualization (which OpenVZ and others do). For now, Xen is the only open source solution in the paravirt. area (other is VMware, there is also a patch from Rusty Russel to add an interface for hypervisors), while in OS-level virt. we have as many as four players, and at least two open source solutions. Who are those players and solutions? See below (taken from OpenVZ blog). Why this is good? Because competition is good. Why it works and Xen does not? Because OS-level virt. is a less dirty hack than a hypervisor.
* Eric Biederman wants to have so-called namespaces in kernel. Namespaces are basically a building blocks of containers, for example, with user namespace we have an ability to have the same root user in different containers; network namespace gives an ability to have a separate network interface; process namespace is when you have an isolated set of processes. All the namespaces combined together creates a container. But, as Eric states, an ability to use not all but only selected namespaces gives endless possibilities to a user.
* IBM people (ex-Meiosys) want application containers, and for them the main purpose of such containers is live migration of those. The difference between app. container and the "full" (system) container is a set of features: for example, an application container might lack /proc virtualization, devices, pseudo-terminals (needed to run ssh, for example) etc. So, an application container might be seen as a subset of a system container.
* OpenVZ wants system containers that resemble the real system as much as possible. In other words, we want to preserve existing kernel APIs as much as possible inside a container, so all of the existing Linux distributions and applictions should run fine inside a container without any modifications. Of course, the goal is not 100% achievable, for example we do not want the container to be able to set the system time.
* Linux-VServer wants just about the same as OpenVZ, it's only that their implementations of various components are different, and their level of a container resembling a real system is a bit lower (for example, in networking).
O.K., this looks like an ethical question, and looks like my ethical principles is a bit different of yours. Anyway...
Well, you can run different distros in different containers on the same system (yep, the kernel will be the same and in most cases it is not a problem). Really, I do not have problem running all the distros you mentioned (we haven't tried FC6 yet though...but I do not foresee any major problem here).
Speaking of security - all those HSP would went out of business very soon if VPSs they sell would be hackable. Also - if you have any knowledge about yet unclosed holes - security@kernel.org is a better place for it than doing a FUD on slashdot.
Speaking of containers usage -- it is not just for HSPs, it is mostly for the server consolidation. And in this scenario one usually does not need to mix different OSs on a singe box, just because one has 100+ of linux boxes and 100+ of other OS boxes -- so one consolidates those to, say, 40 linux boxes and 50 other os boxes.
Also note the maintainability of vmware vs. Containers. If you use vmware for consolidation -- you end up with the same number of servers to manage. In case of containers you can manage (i.e. apply a software update) all of them in parallel, it is not needed to login to each system.
Also note the dynamic resourse mgmt in containers. You can not increase the RAM amount for a VM while it is running - but it's a trivial thing to do for a container. Resizing a disk image online is also a problem with VMs - but just a matter of changing per-container disk quota.
I can continue this comparison, but the general idea is - if you do not require multiple kernels, using containers is much more efficient and (!) natural. And if you do want multiple kernels - you can actually mix two approaches, i.e. run containers inside a VM, and have the best of both worlds.
No, I am not trying to sell something -- OpenVZ is free software (free as in freedom). By the way, OpenVZ developers fixed a lot of bugs in mainstream, so they are rather fixing your kernel than fucking it up. All of the OpenVZ code is #ifdef'd so if no appropriate options are selected the code is not compiled in. Finally, you do not understand what containers are useable for...hmm I can try and give you some examples if you like. Basically, the same isolation/security that you'd rather use VMware for -- the only thing is with containers you do not have to pay performance penalty. Also, containers are hardware-independent, they can be managed "en masse" (unlike VMware VMs), they can be live migrated from box to box. And in case you do not want to run different kernels -- containers are much better/efficient to use than full VMs. Speaking of multiple root users on the box -- each and every HSP sells those cheap VPSs based on one of the existing implementation of containers. They sell it as cheap as $10/month or so -- and the root access is included. So go buy one and try to crack the system. I mean, please do not spread the "it's totally insecure" FUD if you do not have any real experience with that.
It hurts the same way that multitask operating systems hurt - there is definitely some overhead for task switching. Really, single task OSs gives more CPU to the task and thus are more efficient.
In multiuser operating systems there are a lot of checks for uids, gids etc.
Now the question - do we want multiuser and multitask OSs? Do we want ownership and permission checks on files? Do we want resourse limits (such as ulimit, disk quotas)?
Same answer applies to containers.
That's a pity that a few talks about containers (OS-level virtualization, a la advanced Jails, a la Solaris Zones/Partitions) were not covered at all. There were (at least) four of them:
- Eric Biederman's talk about namespaces
- Cedric Le Goater's talk about application mobility (a.k.a. live migration of containers)
- A BOF on containers, moderated by Dave Hansen
- A BOF on the resource management (one of the components of containers), moderated by Dipkanar Sarma
There was also a half-an-hour discussion about containers on the Kernel Summit. Let me summarise all these in a few lines:
1. Containers are a real alternative (or a good addition) to Xen and paravirtualization. In most cases they can be used for same applications, without incurring all the Xen's overhead and dirty hacks)
2. Everybody wants containers in the mainstream kernel
3. There are different implementations (IBM's stuff, OpenVZ, Linux-VServer, and Eric's) and their developers need to agree upon them what to submit/push into mainline. This is hard to do, but a required step.
4. Resource management: User Beancounters from OpenVZ is a good (the only?) candidate for inclusion into mainstream.
Indeed, OS-level virtualization approach (as in Solaris Zones, Jails or OpenVZ) performance can not be beaten by para-virtualization approach just because OS-level virt. has the least possible overhead (and, say, does not have an overhead of running multiple kernels which both Xen and UML have).
If you run all the apps on the same box you gonna have problems. Here are just a few.
System-wide resources. There are some system-wide resources like the number of open files, number of sockets, IPC shared memory pages, physical memory pages, virtual memory pages, swap, number of processes etc. etc. Basically, any app can go mad and abuse one of those resources, rendering the whole system (and all the other apps) unusable. This is the most serious problem I believe. You can limit some of the resources -- like disk space, using per-user and per-group disk quotas -- but you can not control all of them. In contrast, in OpenVZ each VPS has a set of resource limits (and guarantees) and a VPS owner can not eat the whole box (unless configured to do so).
Users, libraries, distros. Different apps like different environments -- for example, app A requres library B version C. Not every application can run on every distro -- we have to face the truth. This is not a serious problem usually, but it arises sometimes. In OpenVZ you can have different sets of libs, different distros in different VPSs.
Security. Intruder hacked your old sendmail and got a local user. At the very least, he can now see the other processes and files. In some worse scenario he might find yet another hole and have a root user -- and all your apps are now had.
There are some other things like that as well. To conclude, virtual environment gives you the needed level of isolation between apps. Besides that, there are some added benefits -- like you can migrate your VE to another box without restarting your application(s)...
Well you might call it chrooting, but it is very advanced chrooting. No, even not like jail, much more advanced than that. Just read the article (and probably OpenVZ docs, too), or try it for yourself to see the difference.
> true isolation between nodes (with vservers other users can often bind to your ips etc)
No, in OpenVZ VPS you can not bind to somebody else's IP -- virtualized network is one of the differences between Linux-VServer and OpenVZ. Seriously, consider reading the interview itself -- it is mentioned there as well.
> resource limitation
Resource limiting, or, I'd rather call it resource management, because it is not just the limits but also the guarantees -- another big part of OpenVZ.
> ability to run differently-configured kernels, or even different operating systems
Indeed this is what OpenVZ or any other OS-level virtualization solution can not do, naturally. Still, I can not consider that requirement as a requisite condition for the technology to be called "virtualization".
Using OpenVZ or Virtuozzo, you can live migrate all your Virtual Environments (VEs) to another physical server before rebooting your box. "Live migrate" here means no need to reboot VEs, means no existing network connection will be broken etc. etc. After you've done your maintenance on the physical server (be it adding more RAM, or kernel upgrade, or switching from one distro to another -- you just migrate your VEs back. Also note that if another server has different NIC or SCSI controller -- you don't have to worry. This (ability to do live migration and be independent of hardware) is just one little piece of functionality that OS-level virtualization provides.
OS-level virtualization approach (like OpenVZ) is not adding much overhead per se. So in case of proper planning it will work out right. Speaking of proper planning, OpenVZ has a sophisticated resource management capabilities in kernel (and Virtuozzo provides GUI tools to manage that, among the other things). There exist a set of per-VE limits and guarantees (and guarantees are met in case you do not oversell).
I know some people who use Virtuozzo, OpenVZ or Linux-VServer to host a single VPS. This does not makes sense from the first sight, does it? What about the second?..
The idea is virtualization (OS-level virtualization) provides some benefits without sacrificing much of anything. So what it provides?
Virtual Environment (VE) do not depend on the hardware, so you can move a VE to another box without changing anything. Every sysadmin will love that. No need to edit /etc/fstab or /etc/modprobe.conf.
VE can be cloned. If you want to change something but afraid it will not work, you clone your VE and change the clone.
VE can be migrated to another physical server live (with no service outage -- to networked users it will be seen as a delay in response, not as any downtime). We are releasing this feature for OpenVZ this week.
In the term "OS-level virtualization" by "OS" they mean kernel.
So, in OpenVZ, it is kernel which provides those virtual environments, and you can have any app or any linux distro running inside that virtual environment (as long as stuff is compatible with the kernel; in OpenVZ case this requires distro which can be used on a 2.6 kernel).
Thanks!
Speaking of "recentness", current development branch of OpenVZ kernel is 2.6.16 based (here). You can actually use it, but we can not guarantee it is as stable and matured as the current stable 2.6.8-based kernel.
Speaking of technologies, you just can not achieve a level of density which you have in OpenVZ (VServer, Solaris Zones, etc.) with either Xen or VMWare. Running multiple kernels is indeed a strange idea -- kernel is designed to be run on top of hardware; kernel is a piece of software to be used between hardware and application software. This is what Linux does, this is what Windows kernel does, this is what OpenVZ does. If you run kernel on top of something else (VMware virtual machine, Xen hypervisor) you are gonna have problems. Let me give you just a couple of examples. Say, each kernel caches the stuff read from (written to) disk. How can you unify that caching process if you are having multiple kernels? I do not say impossible, I say extremely tricky. Disabling cache is not an option - your performance will drop. Say, you want to give more memory to your virtual server. In case of OpenVZ, this is just a single "vzctl set" command, no problems, you just raise the limits the same way you do for disk quota. But how can you explain the kernel running inside a VMWare or Xen what it can use more memory now? I do not say impossible, I say extremely tricky. And there are a lot of dirty dirty hacks needs to be done to fix such stuff.