I don't think you'd be able to run a virtualisation product inside a virtualised world. That IMO doesn't make sense and normally is intercepted by the product (at least MS handles this that way).
Message was edited by:
"We would like to run Windows 2000, Windows 2003 S, Windows 2003 E, Windows R2 x64 inside a single ESX server with 16GB of RAM"
This is what ESX is for. No need for Virtuozzo.
I will answer your question with a question.
Two different kinds of virtualization - VMware provides HW virtualization and Virtuozzo provides OS virtualization.
You would use ESX to create a dynamic/homogenous hardware environment and then run VZ to support multiple application environments. This could be very beneficial for someone who's running a web hosting environment, especially in their lab.
In this type of a setting, ESX and VZ become complementary rather than competitive.
I have a different opinion on this one (if I can). I see hw virtualization the best solution to fit Heterogeneous environments being consolidated on a single hw platform (i.e. different levels of Windows, Linux etc etc) and specifically where vm's containment is critical (i.e. for DR purposes for example) or where there must be a strong boundary between applications running on the same host (i.e. one vm going blue wouldn't affect others etc etc).
On the other hand, as you mentioned, I see OS virtualization coming into place in Homogeneous deployments where a given OS hosting environment is a common denominator across different deployments (namely web hostings etc etc).
My opinion is that it doesn't make much sense to stack multiple virtualization technologies on a single system due to a number of reasons (such as manageability, problem determination and performance). One of the major advantages of SW Virtuozzo is that you could run hundreds if not thousends of "cointainers" on the same box (Vs the few vm's you could run on ESX) ..... do you realistically want to run those thousends of containers.... in a partition/vm running on ESX ?
Mh ...... quite farnkly this stacking would make sense on something like a mainframe where the hw deployments are not so modular like on the x86 platform ........ on this platform I would suggest to go with either OS virtualization on bare metal OR HW virtualization on bare metal based on the specific requirements to exploit it.
This is of course my opinion.
I still do not really see the benefit of using both
We were thinking of adding OS virtualization inside HW virtualization because we need to emulate about 40 - 60 servers (covering all flavors of windows 2003, windows 2000, and linux) and a complicated WAN-simulating enviroment with less than 60k.
Keep in mind there will be not more than 6 engineers using the system.
sorry.. make that 20-40 server for under 60k
I actually think it's a good way to get a lot of copies of 4-6 OS on a couple boxes. I don't know if licensing costs would eat you up as you'd need virtuozzo for each VM. However, I think you're charting new territory if it will even run.
I do know you should be able to get demo licenses from anyone if they want your business. If you have any reasonable hardware around you could test this with at least one virtuozzo stack at a time and see if it works. I expect VMware wouldn't support what's running under virtuozzo, nor would SWSoft support their product running in a windows VM, but it's worth asking.
I don't think we're disagreeing - VMware does provide the platform to support multiple different OS'es running on the same box, but all those OS instances are running within a homogenous environment (an ESX VM).
So...you can have a VZ instance running W2K3, another running W2K, and yet another running W2K3r2 - all on the same hardware platform. This is something that VZ can't do by itself, it needs a single OS to own all the resources. And this is where ESX really shines - creating lots of isolated, protected containers.
But, I know I'm preaching to the choir - I just didn't say clearly enough what I meant the first time!
If you think about it, VZ would be similar in this situation to say a linked clone. Just a different method of doing it. Not sure anyone can say it is a bad way to do it without first testing the idea.
Of course VZ would be on big hairy variable in the environment.
That said, VMware Lab Manager might be another way to go, as you would get a linked clone approach.
Just my 2 cents
I think that there is a difference between a VMware linked clone and a VZ session.
While a VMware linked clone "only" shares the physical bits written on the disks a VZ session/container shares the "instantiation" of those bits at run-time (or at least some of those). This means that a panic-like error in a linked clone is not supposed to bring any other clone down (or at least this is the idea) while a panic-like error in a VZ stack will bring down everything.
The best way to think about this (I think) is like Virtual Desktop Infrastructure (where your vm's share a single piece of hw) Vs Terminal Services (where your sessions share a single piece of Kernel/OS image) ..........
By the way consider also that running Terminal Services within a VM has caused lots of scalability issues; while I am not sure about the implementation details of VZ I would speculate that it could end up running many small processes simultaneously in the same vm and this will definitely cause a TS-like pattern which is not a very VMware friendly manner to push load on a vm.
This is of course my own 2 cents.