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
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
PingBack from http://wareserver.couchfan.com/2008/03/14/quick-roundup/
I believe you also failed to change Microsoft for Micro$oft in you comment...
"Hi-Pervy" - honestly what ever next.
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.
I don't deny that some customers need live migration, but the demand we're seeing for Hyper-v and SCVMM (see http://vmblog.com/archive/2008/03/03/netuitive-survey-shows-vmware-users-unhappy-with-current-management-tools.aspx ) tells me that there's a very large segment of the market who can live without it.
Much ado about nothing.
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 :)
You asked for a customer that was using memory overcommit in the real world. We just posted such an example. Go here for the details: http://blogs.vmware.com/virtualreality/2008/03/memory-overcomm.html.
And thank you for the kind donation to the less fortunate in our world.
@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.
@Mike I've answered on your blog.
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?
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....
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!
That's my virtual two cents!
(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.
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).
Andy. Last point first.
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.
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'!