Hardware virtualization support (like VT/Pacifica) is not a panacea -- first it is just a beginning, many things are not implemented, and many things are implemented, well, in a suboptimal fashion. Say, a context switch between a guest OS and a hypervisor requires as much as 2000 CPU cycles in Intel CPU (and it's not better with AMD, if you ask). So you want to avoid that and modify a guest OS to do things without a need to jump to hypervisor.
Speaking of security, again, there is no silver bullet. Security is better than you care for it, as we do care (and VMWare does care, although they had some security issues in the past (with bridged network adapter AFAIR) -- which proves my point it is not more secure in theory).
Back to hardware-aided virtualization, I didn't say we can not use VT or the future technologies from hardware vendors. Actually we do have a few VT-enabled boxes in our labs and will be using their features in future versions of Virtuozzo/OpenVZ.
Speaking of complexity, it is indeed complex. Any OS is complex. VMWare itself is very complex. Any stuff that is not trivial is complex.
The questions are: whether it works, and is it maintainable?
Whether it works? OpenVZ and Virtuozzo works just fine -- ask anybody who's using it, get a cheap Virtuozzo VPS from one of the HSP, or just install it on your Linux box and see for yourself.
Is it maintainable? OpenVZ stable kernel is based on Linux kernel 2.6.8 (with tons of backported fixes and driver updates). We have recently ported it to 2.6.15 and 2.6.16, and also to the kernels from Fedora Core 5 (here) and SUSE 10 (here). So I think it is maintaintable.
[VMWare] has some performance issues, and Xen's paravirtualization gets a fine balance, that is to have a minimal set of modification of the guest OS.
Hmm, isn't that Xen which requires a modified Linux kernel? Is that "a minimal set of modifications"? Are you kidding? In contrast, in OpenVZ's VE you run an unmodified Linux distribution, the only missing piece is the kernel which is provided by the host OS. There are modifications (like removing getty from/etc/inittab), but they are not strictly required.
What's the point then? OpenVZ also runs a modified Linux kernel. Well, the point is you can not have hundreds of VMs with Xen (or VMWare), but you can -- with OpenVZ. OpenVZ is also more stable -- but Xen will cure this, I believe, so this is not the point in the long term.
Basically, VMWare is at the one end of the scale -- can run anything, bad performance, scalability and density, OpenVZ is on the other end -- can run Linux 2.6 only, native performance, best possible scalability and density, easier management. Xen is somewhere in the middle of all this.
OpenVZ provides a kind of virtualization called OS-level virt, or partitioning, or slicing. Basically you divide your Linux box into multiple small linux boxes, called virtual environments (VEs).
In each VE you can have different Linux distro installed. Consider FC4, FC5, CentOS and Debian running on the same box, so you can compile and test you app in all these distros, without a need to reboot or have a dedicated boxes for each of those.
To further understand between three different kinds of virtualization, read this small article
Speaking of security, every major hosting service provider is using Virtuozzo, selling cheap VPSs (virtual environments) with root access for like $15/month, so every evil hacker out there can buy one and try to exploit the box. They can't -- otherwise all those HSPs will be in big trouble.
Why they can't -- because OpenVZ/Virtuozzo security is on a good level. We do care about security a lot.
Speaking of VMware and Xen -- there is still a single point of failure in those solutions -- VMWare itself and host OS in case of VMWare, and hypervisor and Dom0 in case of Xen. So, it is neither better nor worse in theory.
In practice, though, security is good when people do care about it. For obvious reasons (a lot of customers in HSP world) Virtuozzo (and OpenVZ) does care for security. But don't take my word for that -- go try it out, download and install OpenVZ, expose a few virtual environments to the outside world, give their passwords to everybody and see if they can break your system. Why not?
Very short answer -- Solaris Containers is the same technology as OpenVZ or VServer. Their isolation is OK as well, their resource management is worse than that in OpenVZ. There are some system-wide resources that you can not limit for a containter -- which can create problem if an application inside a containter goes crazy (or a container is owned by a c00l ha>
Remember, Solaris Containers are a recent feature, while Virtuozzo was available as a product since year 2001. So, Solaris is doing the right things and great things, but it still has a way to go.
All of the OpenVZ aspects and features (like User Beancounters) can be turned on or off in kernel.config. I.e. OpenVZ kernel can be compiled without (or with) any of OpenVZ features.
How VMWare can be independent of host OS if it runs on top of it? I mean there is a single point of failure here: if host OS dies every VMWare instance dies with it.
And the question is not just performance -- indeed, with hardware band-aids like AMD Pacifica and Intel VT performance will be better. The question is density, scalability, and manageability (it is funny you even mentioned it -- see below).
Density: you can run hundreds of virtual environments in OpenVZ, you can run tens of guests in VMWare. Makes sense?
Scalability: can VMWare effectively utilize "big hardware" like 64-way SMP box with 64 GB of RAM? OpenVZ can -- absolutely no problem, there are no additional SMP hacks needed etc. More to say, a single virtual environment can use all those resources if needed.
Manageability: From a sysadmin point of view, VMWare guest is just like a physical server. If you want to apply software updates, you have to log in into each one and run an update procedure. One by one, the very same way you'd do it with separate physical boxes. In contrast, in OpenVZ you can actually see and access all the virtual environments from the host OS, making mass-management possible. You can apply updates en masse. You can do mass-management. Makes sense?
Indeed, VMWare (or other solutions of the kind, like Parallels or QEmu) makes sense if you want to run different operating systems, different kernels etc. It makes much sense in development labs, at home or when you have just one server. But if you have a rack of servers -- OpenVZ/Virtuozzo/other solutions of the kind makes much more sense, due to the reasons cited above -- scalability, density, manageability.
Not sure what do you mean by the term "scale". I can imagine the same phrase being said about a multiuser (or multitask) operating system: "that concept that system has multiple users (processes) makes OS too much more complicated". Well, you know that all this multi* stuff is a reality, and the next step in OS evolution is multiple virtual environments. Think of it for a minute.
Indeed, this is what guys like IBM did on a big million dollar mainframes. And this is what now possible to do on your laptop. And it makes sense.
Virtuozzo is in production since 2001, according to http://www.swsoft.com/en/company
It is way ahead of Solaris Zones, which, by the way, still lacks proper resource management, similar to that found in OpenVZ/Virtuozzo. And why resource management is of paramount importance is described in Andrey's interview.
I'm not quite following you. What do you mean by "true virtualization"? Emulation? First of all, "virtualization" is a broad concept, it means making something that is not real look like real. Virtuozzo and OpenVZ does just that. From a point of view of a virtual environment only, it looks pretty much like a real server (with the only exception he can not use another kernel and/or load kernel modules).
Speaking of security, Virtuozzo is used by almost every major hosting service provider, and they sell cheap VPSs. If the level of security isolation provided by VZ is not strong enough, all those providers are screwed.
OpenVZ has undergone a throughout security review by a leading security expert Solar Designer last year; some bugs (including a few bugs in the mainstream Linux kernel 2.6) were found and fixed (and submitted to mainstream). Of course that does not mean it is free of bugs -- so I urge you to give it a try and find it out for yourself.
In theory the concept of OS-level virtualization is not weaker than other approaches as it comes for security. In practice, one should take a lot of care to make sure his software is secure. We at OpenVZ do care much for security, because it is a vital feature of OpenVZ (and Virtuozzo, for that matter).
Quicker turn around if you need new servers, since normally they already have the spare hardware it's 1 or 2 days to get a new server
*shameless plug* if you own a physical server running OpenVZ, you can have a new VE (virtual environment, virtual server) in a minute. I'm not kidding -- it's just a few commands, and you are all set. Basically, you just have to choose which Linux distro do you want, and supply an IP address, name server, and the root password -- and you'll have your new shiny server in a minute.
You might try evaluating OpenVZ then -- to me it looks like it does not have any of the disadvantages you mentioned. If you plan it right and do not oversell, you can guarantee the certain quality of service to every virtual environment (VE).
In addition, OpenVZ has dynamic resource management (you can't give more memory to Xen guest during runtime, can you? but it is trivial with OpenVZ) and much higher scalability (hundreds of VEs vs. tens of guests).
As for the scalability across multiple servers -- I think nobody really do it in Intel PC world -- it's a real challenge to implement. But I think it will be done in the next 10 years or so. For now, OpenVZ can offer you a live migration feature -- when you need more resources than this very physical server can provide, you just migrate your VE to a better one, and then upscale its resource limits.
Well, say in OpenVZ you have near-zero performance overhead (and thus very-very-close-to-native performance -- in some situations you can not measure the overhead at all, in some others it is like 2-3%), so it won't do any harm to performance if you virtualize your real servers.
From the performance side, each VE in OpenVZ has its set of limits and guarantees. And those guarantees will be met unless you "oversell". I.e. if you plan things right it will work right.
And there are some benefits from the virtualization that you must not forget about. Some people, say, use OpenVZ to run a single virtual environment -- just because there is added value -- you can clone your VE, say, or migrate it to another box without a need to care much about hardware differences, etc. etc. Live migration is another piece of cake -- you can leave your apps running while doing hardware maintenance -- just migrate it to another physical server!
He actually mentions Zones: Vendors following single OS image approach include Virtuozo, Vservers and Zones. This method groups user processes into resource containers and manages access to physical resources. While this approach can scale well, it is hard to get strong isolation among the different containers.
The problem with the article, as I see it, is that he claims something without supporting his words, and the quote above is the excellent example. Why he thinks that it is hard to get strong isolation in OS-level virtualization is beyond my imagination. Consider Virtuozzo which is used on thousands of boxes and let ISPs sell cheap virtual environments VE with root access -- they would not be able to use Virtuozzo in case isolation is weak and VE root can do something evil to the system. The fact it, hosting is a very hostile environment, and almost every major ISP uses Virtuozzo or OpenVZ -- that means it works and isolation is strong enough.
If you are so happy with Xen, I suggest you try OpenVZ (http://openvz.org/ -- I bet you'll be even more happy. Unlike Xen, OpenVZ does not have that big I/O overhead (our tests shows Xen guests do I/O about 30% slower than native system). The biggest thing though is you can run not 3 but 30 virtual environments, and dynamically manage their resources (like adding/removing memory from the environment without any need to restart it).
Finally, live migration for OpenVZ will be released Real Soon Now.
If you need to run Linux on Linux, take a look at OpenVZ -- compared to VMware, it has *much* higher scalability and lower overhead. And it *is* stable.
The result is that you can't actually USE 100 ves with 1 GB of ram.
I was actually able to run 200 VPSs on the same 1 GB of RAM, but the swap was horrible and the apache performance was very low -- but it worked! In case with 100 VPSs each running apache, sendmail, xinetd and sshd -- there was little to no swapping, and apache performance (serving a few 10Kb static pages) under high apache load was just fine.
So when I say "100 VPSs" it is indeed 100 VPSs - no tricks, no cheating, and you can try it yourself. Ask for more configuration details if needed.
Definitely, if you use MySQL and some other stuff like that, you can end up with as low as 1 VPS -- that basically depends on MySQL configuration and server (VPS) load.
Speaking of memory allocation, under openvz/virtuozzo, it is possible to cause the system to mmap much larger areas into memory than the memory limits allow. I read on the openvz mailing list (or maybe forums, in any case the message was from an swsoft employee) that this problem exists in both vservers and openvz. I won't detail exactly how you do it, but I did verify that it works.
Currently we know of no such exploits in OpenVZ or Virtuozzo -- so can you be more specific here and provide some info or URLs to those posts?
Sure we do understand that kernel is a critical piece in such a technique as used by OpenVZ -- and we do care about our kernel quality. This is the reason OpenVZ is still based on 2.6.8 -- for the same reasons RHEL4 is still based on 2.6.9 kernel -- stability. Actually, the fair share of OpenVZ patch is just bug fixes and driver updates, not virtualization. And we do *a lot* of quality testing in house -- to make sure kernel is stable and solid as a rock, and it is very stable. Feel free to prove otherwise -- we will be happy to hear about bugs or security holes in OpenVZ.
Or perhaps you are saying that Virtuozzo is not designed to support as many concurrent VPSs as UML on the same machine?
Virtuozzo/OpenVZ is designed to support hundreds and thousands VPSs on the same machine. I'm not sure about UML (it was limited to 40 instances per box a few years ago, due to a limit of tun/tap devices in kernel), but we are able to run hunrdeds and thousands of VPSs on a decent hardware. Say, a box with 4Gb of RAM can easily accomodate about 800 Virtuozzo VPSs (with no or little swapping) -- and I personally done that and seen that, it is not like "somebody said something". With more RAM comes more VPSs - they scale up in a linear fashion.
And yes, Virtuozzo *is* designed to be very efficient and lean on hardware. In SWsoft QA labs they do a lot of performance and scalability testing, making sure Virtuozzo gives the best it can.
Finally, what is the reason why people spend money for Virtuozzo, if they can have UML for free? Perhaps it works better for them?
I used to run X Window inside an OpenVZ VPS (based on Fedora Core 4) and access it via VNC from my desktop. Runs perfectly fine, even xscreensaver is working:)
It is not quite like that. First of all, OpenVZ *is* able to run different distros in different virtual environments, as the *only* common part between those environments is the kernel -- OpenVZ kernel.
Second, Xen approach has its advantages and disadvantages. Among Xen advantages are, say, ability to run different kernels simultaneously, including non-linux (bsd) kernels as well, (theoretically) better isolation. But it comes with a price: greater virtualization overhead, lower resource utilization (thus lower density), inability to dynamically reallocate resources. Say, you can not run 100 Xen instances on a box with 1GB of RAM, but it's a trivial thing to do with OpenVZ.
Consider the third variant -- VMware. It gives you even more isolation and ability to run *any* OS, not modified at all. But again, as with Xen, it comes for a price: yet lower performance and density.
All the three approaches have their pros and cons -- and it's up to the user to decide which one suits his tasks and environment better.
Slashdot Mirror
Hardware virtualization support (like VT/Pacifica) is not a panacea -- first it is just a beginning, many things are not implemented, and many things are implemented, well, in a suboptimal fashion. Say, a context switch between a guest OS and a hypervisor requires as much as 2000 CPU cycles in Intel CPU (and it's not better with AMD, if you ask). So you want to avoid that and modify a guest OS to do things without a need to jump to hypervisor. Speaking of security, again, there is no silver bullet. Security is better than you care for it, as we do care (and VMWare does care, although they had some security issues in the past (with bridged network adapter AFAIR) -- which proves my point it is not more secure in theory). Back to hardware-aided virtualization, I didn't say we can not use VT or the future technologies from hardware vendors. Actually we do have a few VT-enabled boxes in our labs and will be using their features in future versions of Virtuozzo/OpenVZ.
Speaking of complexity, it is indeed complex. Any OS is complex. VMWare itself is very complex. Any stuff that is not trivial is complex.
The questions are: whether it works, and is it maintainable?
Whether it works? OpenVZ and Virtuozzo works just fine -- ask anybody who's using it, get a cheap Virtuozzo VPS from one of the HSP, or just install it on your Linux box and see for yourself.
Is it maintainable? OpenVZ stable kernel is based on Linux kernel 2.6.8 (with tons of backported fixes and driver updates). We have recently ported it to 2.6.15 and 2.6.16, and also to the kernels from Fedora Core 5 (here) and SUSE 10 (here). So I think it is maintaintable.
[VMWare] has some performance issues, and Xen's paravirtualization gets a fine balance, that is to have a minimal set of modification of the guest OS.
Hmm, isn't that Xen which requires a modified Linux kernel? Is that "a minimal set of modifications"? Are you kidding? In contrast, in OpenVZ's VE you run an unmodified Linux distribution, the only missing piece is the kernel which is provided by the host OS. There are modifications (like removing getty from /etc/inittab), but they are not strictly required.
What's the point then? OpenVZ also runs a modified Linux kernel. Well, the point is you can not have hundreds of VMs with Xen (or VMWare), but you can -- with OpenVZ. OpenVZ is also more stable -- but Xen will cure this, I believe, so this is not the point in the long term.
Basically, VMWare is at the one end of the scale -- can run anything, bad performance, scalability and density, OpenVZ is on the other end -- can run Linux 2.6 only, native performance, best possible scalability and density, easier management. Xen is somewhere in the middle of all this.
Have you actually read the interview?
OpenVZ provides a kind of virtualization called OS-level virt, or partitioning, or slicing. Basically you divide your Linux box into multiple small linux boxes, called virtual environments (VEs).
In each VE you can have different Linux distro installed. Consider FC4, FC5, CentOS and Debian running on the same box, so you can compile and test you app in all these distros, without a need to reboot or have a dedicated boxes for each of those.
To further understand between three different kinds of virtualization, read this small article
Speaking of security, every major hosting service provider is using Virtuozzo, selling cheap VPSs (virtual environments) with root access for like $15/month, so every evil hacker out there can buy one and try to exploit the box. They can't -- otherwise all those HSPs will be in big trouble.
Why they can't -- because OpenVZ/Virtuozzo security is on a good level. We do care about security a lot.
Speaking of VMware and Xen -- there is still a single point of failure in those solutions -- VMWare itself and host OS in case of VMWare, and hypervisor and Dom0 in case of Xen. So, it is neither better nor worse in theory.
In practice, though, security is good when people do care about it. For obvious reasons (a lot of customers in HSP world) Virtuozzo (and OpenVZ) does care for security. But don't take my word for that -- go try it out, download and install OpenVZ, expose a few virtual environments to the outside world, give their passwords to everybody and see if they can break your system. Why not?
You are damn right pal!
The obvious difference though is x86 crowd is now doing it in software, not in hardware -- and so it's much cheaper.
Very short answer -- Solaris Containers is the same technology as OpenVZ or VServer. Their isolation is OK as well, their resource management is worse than that in OpenVZ. There are some system-wide resources that you can not limit for a containter -- which can create problem if an application inside a containter goes crazy (or a container is owned by a c00l ha>
Remember, Solaris Containers are a recent feature, while Virtuozzo was available as a product since year 2001. So, Solaris is doing the right things and great things, but it still has a way to go.
We surely do understand that.
All of the OpenVZ aspects and features (like User Beancounters) can be turned on or off in kernel .config. I.e. OpenVZ kernel can be compiled without (or with) any of OpenVZ features.
How VMWare can be independent of host OS if it runs on top of it? I mean there is a single point of failure here: if host OS dies every VMWare instance dies with it.
And the question is not just performance -- indeed, with hardware band-aids like AMD Pacifica and Intel VT performance will be better. The question is density, scalability, and manageability (it is funny you even mentioned it -- see below).
Density: you can run hundreds of virtual environments in OpenVZ, you can run tens of guests in VMWare. Makes sense?
Scalability: can VMWare effectively utilize "big hardware" like 64-way SMP box with 64 GB of RAM? OpenVZ can -- absolutely no problem, there are no additional SMP hacks needed etc. More to say, a single virtual environment can use all those resources if needed.
Manageability: From a sysadmin point of view, VMWare guest is just like a physical server. If you want to apply software updates, you have to log in into each one and run an update procedure. One by one, the very same way you'd do it with separate physical boxes. In contrast, in OpenVZ you can actually see and access all the virtual environments from the host OS, making mass-management possible. You can apply updates en masse. You can do mass-management. Makes sense?
Indeed, VMWare (or other solutions of the kind, like Parallels or QEmu) makes sense if you want to run different operating systems, different kernels etc. It makes much sense in development labs, at home or when you have just one server. But if you have a rack of servers -- OpenVZ/Virtuozzo/other solutions of the kind makes much more sense, due to the reasons cited above -- scalability, density, manageability.
Not sure what do you mean by the term "scale". I can imagine the same phrase being said about a multiuser (or multitask) operating system: "that concept that system has multiple users (processes) makes OS too much more complicated". Well, you know that all this multi* stuff is a reality, and the next step in OS evolution is multiple virtual environments. Think of it for a minute.
Indeed, this is what guys like IBM did on a big million dollar mainframes. And this is what now possible to do on your laptop. And it makes sense.
Virtuozzo is in production since 2001, according to http://www.swsoft.com/en/company It is way ahead of Solaris Zones, which, by the way, still lacks proper resource management, similar to that found in OpenVZ/Virtuozzo. And why resource management is of paramount importance is described in Andrey's interview.
I'm not quite following you. What do you mean by "true virtualization"? Emulation? First of all, "virtualization" is a broad concept, it means making something that is not real look like real. Virtuozzo and OpenVZ does just that. From a point of view of a virtual environment only, it looks pretty much like a real server (with the only exception he can not use another kernel and/or load kernel modules).
Speaking of security, Virtuozzo is used by almost every major hosting service provider, and they sell cheap VPSs. If the level of security isolation provided by VZ is not strong enough, all those providers are screwed.
OpenVZ has undergone a throughout security review by a leading security expert Solar Designer last year; some bugs (including a few bugs in the mainstream Linux kernel 2.6) were found and fixed (and submitted to mainstream). Of course that does not mean it is free of bugs -- so I urge you to give it a try and find it out for yourself.
In theory the concept of OS-level virtualization is not weaker than other approaches as it comes for security. In practice, one should take a lot of care to make sure his software is secure. We at OpenVZ do care much for security, because it is a vital feature of OpenVZ (and Virtuozzo, for that matter).
And in case you want to have a dedicated network device in an OpenVZ VE, use something like
vzctl set VEID --netdev_add ethX --save
No probs, here is the extract from vzctl(8) man page:
/dev/device from VPS.
Device access management
--devnodes device:r|w|rw|none
Give access (r - read, w - write, rw - read write, none - no
access) to special file
"Dom tehnicheskoy knigi" ("Tech book house") on Leninskiy prospect, 40, should have a lot of CS books in English.
Quicker turn around if you need new servers, since normally they already have the spare hardware it's 1 or 2 days to get a new server
*shameless plug* if you own a physical server running OpenVZ, you can have a new VE (virtual environment, virtual server) in a minute. I'm not kidding -- it's just a few commands, and you are all set. Basically, you just have to choose which Linux distro do you want, and supply an IP address, name server, and the root password -- and you'll have your new shiny server in a minute.
You might try evaluating OpenVZ then -- to me it looks like it does not have any of the disadvantages you mentioned. If you plan it right and do not oversell, you can guarantee the certain quality of service to every virtual environment (VE). In addition, OpenVZ has dynamic resource management (you can't give more memory to Xen guest during runtime, can you? but it is trivial with OpenVZ) and much higher scalability (hundreds of VEs vs. tens of guests). As for the scalability across multiple servers -- I think nobody really do it in Intel PC world -- it's a real challenge to implement. But I think it will be done in the next 10 years or so. For now, OpenVZ can offer you a live migration feature -- when you need more resources than this very physical server can provide, you just migrate your VE to a better one, and then upscale its resource limits.
Well, say in OpenVZ you have near-zero performance overhead (and thus very-very-close-to-native performance -- in some situations you can not measure the overhead at all, in some others it is like 2-3%), so it won't do any harm to performance if you virtualize your real servers. From the performance side, each VE in OpenVZ has its set of limits and guarantees. And those guarantees will be met unless you "oversell". I.e. if you plan things right it will work right. And there are some benefits from the virtualization that you must not forget about. Some people, say, use OpenVZ to run a single virtual environment -- just because there is added value -- you can clone your VE, say, or migrate it to another box without a need to care much about hardware differences, etc. etc. Live migration is another piece of cake -- you can leave your apps running while doing hardware maintenance -- just migrate it to another physical server!
> What about Solaris Zones?
He actually mentions Zones: Vendors following single OS image approach include Virtuozo, Vservers and Zones. This method groups user processes into resource containers and manages access to physical resources. While this approach can scale well, it is hard to get strong isolation among the different containers.
The problem with the article, as I see it, is that he claims something without supporting his words, and the quote above is the excellent example. Why he thinks that it is hard to get strong isolation in OS-level virtualization is beyond my imagination. Consider Virtuozzo which is used on thousands of boxes and let ISPs sell cheap virtual environments VE with root access -- they would not be able to use Virtuozzo in case isolation is weak and VE root can do something evil to the system. The fact it, hosting is a very hostile environment, and almost every major ISP uses Virtuozzo or OpenVZ -- that means it works and isolation is strong enough.If you are so happy with Xen, I suggest you try OpenVZ (http://openvz.org/ -- I bet you'll be even more happy. Unlike Xen, OpenVZ does not have that big I/O overhead (our tests shows Xen guests do I/O about 30% slower than native system). The biggest thing though is you can run not 3 but 30 virtual environments, and dynamically manage their resources (like adding/removing memory from the environment without any need to restart it).
Finally, live migration for OpenVZ will be released Real Soon Now.
If you need to run Linux on Linux, take a look at OpenVZ -- compared to VMware, it has *much* higher scalability and lower overhead. And it *is* stable.
Yes we are :) Nice to meet you ;)
The result is that you can't actually USE 100 ves with 1 GB of ram.
I was actually able to run 200 VPSs on the same 1 GB of RAM, but the swap was horrible and the apache performance was very low -- but it worked! In case with 100 VPSs each running apache, sendmail, xinetd and sshd -- there was little to no swapping, and apache performance (serving a few 10Kb static pages) under high apache load was just fine.
So when I say "100 VPSs" it is indeed 100 VPSs - no tricks, no cheating, and you can try it yourself. Ask for more configuration details if needed.
Definitely, if you use MySQL and some other stuff like that, you can end up with as low as 1 VPS -- that basically depends on MySQL configuration and server (VPS) load.
Speaking of memory allocation, under openvz/virtuozzo, it is possible to cause the system to mmap much larger areas into memory than the memory limits allow. I read on the openvz mailing list (or maybe forums, in any case the message was from an swsoft employee) that this problem exists in both vservers and openvz. I won't detail exactly how you do it, but I did verify that it works.
Currently we know of no such exploits in OpenVZ or Virtuozzo -- so can you be more specific here and provide some info or URLs to those posts?
Sure we do understand that kernel is a critical piece in such a technique as used by OpenVZ -- and we do care about our kernel quality. This is the reason OpenVZ is still based on 2.6.8 -- for the same reasons RHEL4 is still based on 2.6.9 kernel -- stability. Actually, the fair share of OpenVZ patch is just bug fixes and driver updates, not virtualization. And we do *a lot* of quality testing in house -- to make sure kernel is stable and solid as a rock, and it is very stable. Feel free to prove otherwise -- we will be happy to hear about bugs or security holes in OpenVZ.
Or perhaps you are saying that Virtuozzo is not designed to support as many concurrent VPSs as UML on the same machine?
Virtuozzo/OpenVZ is designed to support hundreds and thousands VPSs on the same machine. I'm not sure about UML (it was limited to 40 instances per box a few years ago, due to a limit of tun/tap devices in kernel), but we are able to run hunrdeds and thousands of VPSs on a decent hardware. Say, a box with 4Gb of RAM can easily accomodate about 800 Virtuozzo VPSs (with no or little swapping) -- and I personally done that and seen that, it is not like "somebody said something". With more RAM comes more VPSs - they scale up in a linear fashion.
And yes, Virtuozzo *is* designed to be very efficient and lean on hardware. In SWsoft QA labs they do a lot of performance and scalability testing, making sure Virtuozzo gives the best it can.
Finally, what is the reason why people spend money for Virtuozzo, if they can have UML for free? Perhaps it works better for them?
I used to run X Window inside an OpenVZ VPS (based on Fedora Core 4) and access it via VNC from my desktop. Runs perfectly fine, even xscreensaver is working :)
It is not quite like that. First of all, OpenVZ *is* able to run different distros in different virtual environments, as the *only* common part between those environments is the kernel -- OpenVZ kernel.
Second, Xen approach has its advantages and disadvantages. Among Xen advantages are, say, ability to run different kernels simultaneously, including non-linux (bsd) kernels as well, (theoretically) better isolation. But it comes with a price: greater virtualization overhead, lower resource utilization (thus lower density), inability to dynamically reallocate resources. Say, you can not run 100 Xen instances on a box with 1GB of RAM, but it's a trivial thing to do with OpenVZ.
Consider the third variant -- VMware. It gives you even more isolation and ability to run *any* OS, not modified at all. But again, as with Xen, it comes for a price: yet lower performance and density.
All the three approaches have their pros and cons -- and it's up to the user to decide which one suits his tasks and environment better.