It's quite amusing to see the VMware blogger (Citrix's blog names him as Eric Horschmann) has come back with a screen full of algebra to try justify it the post I commented on yesterday
They look convincing, don't they ? He's right only if you fixed the amount of RAM in the server. But when was that ever a fixed point ? either you want to run 14 VMs on the box, or the budget per box is $17,748. Who ever yelled "Screw the budget, Screw the workload. Keep the memory constant !" ?
Needless to say if your product is adding cost, you want the other figures beefed up to keep the proportion due to you as small as possible. I said the cost of the box was suspiciously high. And would you run 0.5 GB VMs (was that why they chose an out of support OS) . If you were only running 1GB VMs you'd get 3 on the box and use the cheaper Enterprise edition of Windows rather than Datacenter. That would reduce the cost of the Microsoft system, perhaps to the point where it was as cheap to run two small Microsoft boxes as one larger VMware one.
So lets try those figures again shall we ? This time we'll build a server to support 14 VMs. The only cha
Who's cheapest now ?
Now if the customer is prepared to $5,750 (plus support, training, and extra management tools) on VI3 enterprise... what would they get if they spent that on RAM
Who's cheapest now ? Oh look it's Microsoft again.
Now, I mentioned the screenful of algebra and of course this is based on the same fallacious axiom that memory is the same for the two systems. This contains the same error as the first post one line explaining the terms. MH Physical server memory which of course is held to be the same on both systems. In practice, the Microsoft system would have more RAM and therefore better performance. I've reworked the equations allowing for MHV and MHm the memory on the VMware and Microsoft systems respectively , but keeping everything else the same.
CH Cost of server hardware CM Cost of memory per GB CVMW Cost of VMware virtualization software CMS Cost of Microsoft virtualization software COS Cost of operating system software MHV Physical server memory, GB – Microsoft MHM Physical server memory, GB – VM ware MV Memory per VM, GB r Memory overcommit ratio
The cost of the Microsoft system is CH + CM MHm + CMS +COS And the VMware one costs CH + CM MHV + CVMW +COS
If CMS is zero and the systems cost the same then CM MHm = CM MHV + CVMW
Solving this for memory we get MHm = MHV + (CVMW / CM ) (In English if the cost of VM ware is $5000, and Memory costs $100 per GB, then a Microsoft system can have 50GB more memory for the same money)
The Number of Virtual Machines on VMWare is r MHv / MV
And on Microsoft it is MHm / MV
So to run the same number of VMs: MHm = r MHv (in English if VMWare can run an overcommit ratio of 2 Microsoft needs twice as much memory, for the same VM count. In reality a ratio of 1.25 is more realistic, so Microsoft would need 25% more memory.)
Now we have two equations MHm = MHV + (CVMW / CM ) And : MHm = r MHv
So the break even point for VM ware comes when MHV + (CVMW / CM ) = r MHv
MHv =(CVMW / CM ) / (r -1)
if the cost of VM ware is $5000, Memory costs $100 per GB and r =2, then the VMware system needs to have 50GB of RAM and the Microsoft one 100GB of RAM: above that VMWare is cheaper, below that Microsoft is. If you think my figure of r=1.25 is closer to the real world, then the VMWare system would need 200GB of RAM (and in Eric's scenario that means 400 VMs). Just remind me again what the memory and VM count limitations are with VMware....
Three closing points. First there are scenarios which do benefit from being able to overcommit memory (for example if you're setting up training machines and need 100MB more memory than you've got)- we may have to cap the level at which it can be used to prevent customers getting themselves into trouble. But Bob Muglia has said internally and externally that the feature is needed. Whether "needed" means for tick-in-box feature comparisons or real-customer-need is open to interpretation, either way the feature will come back (it was in the Alpha versions). Secondly Validation.Back at IT forum we pre-announced the "Server Virtualization Validation Program" personally I'm hoping that before we give customers the ability to overcommit memory or dynamically add CPUs and memory to running VMs we validate applications to give them confidence that these abilities are safe to use. If memory which a service has asked to be allocated from a non-paged pool is being paged by the virtualization stack, what will the impact be. And finally. People tell me that VMware customers are using over commit rates of 2 or more in production the offer I made yesterday still stands. show me a customer who is running, in production, a VMware VI3 Enterprise system with a 2:1 memory overcommit ratio on all the VMs, where spending the cost of VMware on RAM wouldn't remove the need to use overcommitment then I'll give... lets say $270 to their choice of charity.
Technorati Tags: Windows Server 2008,Windows Server,Virtulization,Hyper-v,VMware,Fud
Andy, I think we're getting ourselves in a loop here. The article is dishonest; it tried to lead people to believe they can use a 2:1 over commit factor every workload and combination of workloads; they can't, plain and simple - VMware's official advice (away from their bloggers) says so. It tried to lead people to believe that VMware was generally cheaper as a result. It isn't
I've never said that no-body can ever benefit from any kind of over commit (and lets face it, with it in the Alpha of Hyper-V and supposedly coming back for V2 I'd be making a rod for my own back if I did). Remember that the post a commenting on sets out the few cases VMware can end up cheaper.
If you don't like the political analogy, to lower his risk of heart attack an Uncle of mine had to take Warfarin. If someone said "Everyone should take Warfarin" I'd say that was dangerous talk, because it's main use is as Rat Poison.
( http://en.wikipedia.org/wiki/Warfarin )
My objection is to the dishonest extrapolation of an exceptional case to be universally true.
(Oh and if I'm going to do a U-Turn, then I should say that I've stated here a couple of times that I didn't attack a particular sentence, I did quote that sentence, but my comments applied to the whole post).
You say I've been misleading ? Far from it. I've given the point at which memory over commit alone cost justifies VMware (the last equation in the above post).
If you start with enough memory in the server, then it can be cheaper - although you'd have so many VMs it would be unsupported. If you can get a high enough over-commit ratio it can be cheaper, but VMware tell you not to do that.
Dennis Chung: I was recently in a debate with an IT Pro about Hyper-V and VMWare. I can't name him
A couple of Stories have been doing the rounds on our internal Virtualization discussions. One was headed
I’m taking a breather from re-recording the voice track for a Video on Live Migration in Hyper-V. When