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

VMware VI3 foundation

VMware VI3 enterprise

Free Hypervisor

VMs

14

14

14

2 way Server, 4GB Ram

$6000

$6000

$6000

4GB extra RAM

Not needed (with 2x overcommit)

Not needed (with 2x overcommit)

$495

Windows Licences

$5998

$5998

$5998

Virtualization licences

$995

$5750

$0

Total Cost

$12,993

$17,748

$12,493

Price per VM

$928

$1268

$892

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

VMware VI3 enterprise

Free Hypervisor

Total Cost

$17,748

$17,748

Windows Licences

$5998

$5998

Virtualization licences

$5750

$0

2 way Server,

$6000

$6000

RAM

4GB

32GB

VMs

14 (with 2x overcommit)

63

Price per VM

$1268

$281

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 MHVand MHm the memory on the VMware and Microsoft systems respectively , but keeping everything else the same.

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.

There’s a sum of money going to charity. You think Mike’s done enough to claim it for his charity already. I asked him, via a comment on his blog to verify that he met the terms I stipulated (he says the solution is in preparation which disqualifies it), and although he’s answered later comments I haven’t had an answer. Now you’ve made a couple of comments about my hesitation on paying up, because paying Mikes charity means no one else’s gets paid. It’s not a "double or quits" challenge to you, I simply invited you to underwrite the risk to another charity that paying out early – as you think I should – means they miss out. So you’re certain that I should pay Mike’s charity, but you won’t underwrite the risk that I should not. That’s fine, but I think you’ve lost the right to criticize.

Now, lets deal with this bit about insinuating a specific statement from VMware was a lie.

I didn’t home in on a specific sentence. But I believe that whole post, from it’s core premise (Every customer can over-commit memory by a factor of two – despite VMware’s published advice not to do so), through the basis of the the "test" – many identical VMs which are run to be RAM constrained and therefore keep the "lowest common denominator" pages in memory – aiding sharing – and ending up with the basis of the calculation that you can’t spend money on RAM, but you can spend it on software – the whole post was a collection of falsehoods designed to encourage people to believe something which is simply not true.

Let me draw a comparison. Here in the UK politicians of the far right will tell you that "Immigrants cause crime", by rigging their figures some can even prove it. Now I’d call that a lie (and one that fits the "People will fall more easily for a big lie than a small one"). But the position that no Immigrant ever committed a crime is so absurd it doesn’t need to be ruled out.

Andy, if the customer that Mike named were in production then the destination for the money would be assured. However Mike says this is planned, not in production so we’ll have to see where it ends up. (Given a week VM couldn’t muster a production customer doing this).

I haven’t checked, but I don’t think one laptop per child is a registered charity in the country where I am employed, so they wouldn’t be eligable for the charity matching scheme (or UK tax relief either.) I should have said UK charity. I’m aware Mike is making mischief with his choice, a UK registered charity could claim back the income tax I’d paid and get the same again from Microsoft.

And as for "brash wagers" I’ll let you guess if that money would have gone to some other good cause anyway (with Tax relief and Microsoft top up) or if it was my beer fund.

I’ve given Mike a chance to say if his customer is in production or not. If not, I don’t know if Joe might get to name the charity.

I said " where spending the cost of VMware on RAM wouldn’t remove the need to use overcommitment " if Joe spent it on RAM he couldn’t fit it to the server….

@Ken, despite something you’ll see in a few hours, yes you’re right Hyper-V isn’t available for people to deploy in production today. But the decision about what to deploy today wasn’t taken yesterday, but 6 months or more ago. We’re now at a point where people have something they can evaluate to decide if it has a role in their strategy six months or more hence, and for that VMware is no longer the only game in town. They are comfortably the biggest player and that’s not going to end overnight. And we first ship Hyper-V there will be features that *some* customers want that we don’t have.

I think memory over commit is quite low on that list today (excluding one scenario which I want to explore at length another time).

Management is a different matter. We’ve got VMware customers biting our hands off for the next version of System Center Virtual Machine manager (which isn’t even in Beta yet!). V-motion is higher up the list: if you’re running linux VMs Xen might be worth considering. However the argument "I can’t have 2 minutes planned down time on a VM with Microsoft’s free clustering" when the workload isn’t clustered against an application/OS failure in the VM holds very little water for me. In the case where we talking a Web server in a farm or a node of SQL server cluster. If it’s important it’s clustered. If it’s clustered it doesn’t need Hyper-V. And yes my view is an *OVER* generalization 🙂

But it *is* an exciting time. Microsoft can’t take a market just by showing up (if only !)- I don’t think for a minute VMware will lay down and die; they’re going to give customers more to stay in the game. I’ve long thought we do our best work when there is a strong competitor (and that’s arguable too). Put those together and you’d expect 2009/10 to be the peak of innovation for Virtualization.

(1). The "big lie" [in terms of huge factual error] asserted in that post was that (contrary to VMware’s own guidelines) you can use that Very high levels of memory over commitment **universally** to reduce the amount of RAM needed by servers. The "big lie" [in terms of grand construction] was the artificial creation of figures to suggest spending money on VMware rather than RAM *where the choice exists* the customer will always be worse off buying RAM, and central point of that was that customers fix the size of RAM when specifying a system, not its cost or the number of VMs it is to run. [Joe’s case that you extend the life of existing servers wasn’t one they made]

If no scenario ever existed which benefited from over-commit why bother with the feature (VMware have it, we had it in early builds of Hyper-V and have said it will come back). It seemed obvious to me that the "lie" was in making into the "cure for cancer"

I don’t think I insinuated any given sentence was a big lie.

(2) I laid out terms on which I’d pay money to someone’s favorite charity. I’m only paying once. Now if Mike’s customer meets all the terms I’ll pay his charity. Mike’s most recent reply to his blog post doesn’t answer that but does say the customer would be unsupported.

If Mike doesn’t "win", and Joe sends me something to show he wasn’t just making up what he said, I’ll pay his charity. If Joe doesn’t and someone else does… etc. And since I viewed the money as spoken for when I made the first post if it will go to the NSPCC if nobody has proved a claim.

But I tell you what … since you’re calling me a liar. I’ll pay Mike’s charity right away if you’ll agree to pay mine the same amount if his claim doesn’t meet the conditions I originally laid down – a solution in production (even if unsupported) on the day I made the post.

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.

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.

Steve, it’s a beta product so I can’t show the customers who are running it in production (confidentiality and all that) you’ll just have to wait and see what the scalablity numbers are at release.

My point was that with a Microsoft solution you can run many more VMs for the same money, or the same number of VMs for much less money. And if 60VMs is over doing it, well you can run a few more VMs for a little less money.

The cost of the RAM *is* included in the numbers, thats why there is an extra row in the 14VMs model, and why the Microsoft and VM systems cost the same in the other model. OK, I could have broken out a row which said "Budget for Extra ram" VM ware – zero, MSFT $5,750

Clustering is free with Enterprise and Datacenter editions of Windows, and since those include licenses to run Windows VMs that’s what most people will buy.

V-Motion and VMware HA, don’t guard against application crashes (nor does clustering of VMs in VS 2005 or Hyper-V … re-spelling it makes you look infantile BTW). For true HA you need to have applications which use clustering running on different VM hosts.

I spent a long time with a customer last week who was explaining that their need for VMmotion was because of the number of times they have to patch VMware: not only has windows needed fewer reboots historically, but if you’ve got to reboot the VMs, you reboot the host at the same time. Other needs to move VMs seem to come from poor performance down to excessively over-committing memory.

First – show me a customer running > 60 VMs on Hi-Pervy for a start, and this doesn’t mean internal Microsoft.

Second – your text says "if the customer spent the equivalent of a VI3 license on RAM" but you fail to represent this increase in money in your sums in the right hand column.

Third and most important – how much does it cost to add the functionality to Hi-Pervy that is missing, but which is standard with VI3? vMotion (quick migration is not the same thing), DRS (doesn’t exist in Hi-Pervy), HA (how much for MSCS?) – the list goes on and on, not to mention VMsafe..etc

First, Hyper-V is a beta product. I don’t feel it is appropriate to compare a shipping product to what amounts to vapor-ware.

Second, memory over-commit is a nice feature. It is not a make-or-break feature. I have seen many people achieve greater than 2:1 over-commit with a homogeneous VM load. I also know that most enterprise users design their systems to not require over-commitment (usually due to a good dose of caution).

Third, the hypervisor is not the important piece of the virtualization stack. It is the management features that are implemented on top of the hypervisor that bring the true value to the business. VMotion is often cited as the "killer" feature that VMW has over MSFT…and it is a huge advantage. James, your position that you reboot the host at the same time as you reboot the VMs doesn’t fly in my book. First, you’re assuming that every VM on the host needs to be rebooted – what if I have a mixed OS environment? My Linux VMs don’t need to be rebooted, neither do my Solaris, Novell, or whatever. Why should I have to spend my time trying to figure out whether I should put a VM on "Host A" rather than "Host B" because there’s another critical component of the _application_ running on another VM that I don’t want to be on the same host? Let my DRS anti-affinity rules take care of that for me. The list goes on and on.

Honestly, I look forward to Hyper-V becoming a "real" product – and, hopefully, a true contender in the hypervisor space. Having multiple strong players can only help the end user. I’m also looking forward to MSFT (and CTX) – hopefully – introducing some really cool features that VMW doesn’t have so that there’s a compelling reason to do a hard-core comparison of "features that matter" before making a decision.

To wrap it up: Today, if a customer is looking for a virtualization solution, VMware is – in my humble opinion – the clear winner. Tomorrow is another day, and there are storm clouds on the horizon…I’m excited to see what the landscape looks like when the clouds clear 🙂

Show you a customer? Look right here! I am using at least a 2:1 on all my ESX servers. So your argument is I could have spent VMware cost on RAM. Wrong — my servers maxed out at 14 GB. So VMware allowed me to utilize the servers I have to get the results I need NOW.

I’m delighted to see your brash wagers are going toward supporting charity! Can we assume Microsoft will be matching your donation with further $270 to One Laptop Per Child since this it’s a company policy?

These two recent posts started on the premise that you insinuated that a VMware quote, "VMware Infrastructure’s exclusive ability to overcommit memory gives it an advantage in cost per VM the others can’t match." was a "really big lie".

You’ve since recognised that "there are scenarios which do benefit from being able to overcommit memory" and the VMware bloggers have, in response to your post, demonstated the cost saving.

Hey, it’s not my money but now your wager only hangs on the technicality of whether it is "in production" or not and since your ‘big lie’ catchphrase looks now like another even bigger lie I think you should do the decent thing and put your money where your blog is!

I haven’t called you a liar, but I am pointing out that you’ve certainly insinuated that the VMware statement was a lie and it now looks like your statement about VMware was, if not FUD and extremely misleading, just wrong. You’ve since admitted that the feature in question has a use and it has been shown that the figures can add up in a scenario. I don’t personally care whether it’s not ‘in production’ or not.

Sorry to disappoint you but I’m not getting drawn into any ‘double or quits’ wagers you’ve laid down! If I want to give money to charity, I’ll give it on my terms, thank you very much and I personally don’t feel the need to use your silly and brash IT wagers as an excuse to give (or not).

You’ve accused a VMware article of being misleading but I hope you can see that your bold arguments have been just as, if not even more misleading.

First off, memory overcommitment wasn’t a practical, affordable solution in your eyes. Now you’ve admitted ‘there are scenarios which do benefit from being able to overcommit memory’ AND you’ve conceeded that it can also be cost effective solution; these elements formed the basis of your wager! You’ve even resorted to now changing the terms of the wager so that now the solutiuon apparently had to be in-production on the day of your post!

Drawing on the UK Politician comparison, I’d say you’ve done a good example of a ‘u-turn’!