peacon virtualisation blog by James Pearce

 ”With the introduction of VMware vSphere 5, VMware is evolving the product’s licensing to lay the foundation for customers to adopt a more cloud-like IT cost model based on consumption and value rather than physical components and capacity” - Mark Peek, VMware CFO

Which ever we cut it, the problem is clear: consumption based costing works well as a method of charging someone else for resources you own.  The problem for VMware is quite simple: their customers own the hardware already.  So effectively, the deal is to pay 100% of the hardware and operational costs associated with it, and then rent that capacity you’ve already bought back via VMware on top.  What!?

It’s clearly flawed and one has to wonder how this was able to get to such a major product launch with such glaring problems even on top of that – vSphere 5 supports 1TB RAM for VMs, but by the way that will cost you $70k to license.  And then there was the 8GB vRAM restriction on the free-licensed Hypervisor, rendering the product next to useless.

Community Backlash

Quite simply, what could VMware have been thinking?

Such has been the uproar that VMware has (relatively) quickly had to come back with another attempt, broadly doubling most vRAM limits previously announced and thankfully putting a very reasonable 32GB cap on the free Hypervisor (which in my mind makes it fit-for-purpose for it’s expected useful life).

Then quite separately there is the issue of existing customers on SnS agreements; VMware’s own upgrade terms state “Upgrades require that the Replacement License at least contain all of the functionality of the Original License”, which clearly they won’t.  I’d expect some out-of-court settlements on this point for those customers large enough to take it up.

Profits

But even now the simple fact is that host licenses previously had much larger RAM caps – 256GB per host for Essentials, Standard and Advanced, for example.  So why the change?

The argument goes that per-processor licensing is unsustainable for VMware, since increasing core counts have reduced the number of processors required.

But this actually doesn’t stack up either with their financial results nor with processor performance increases over time.  Announcing the results of Q2 this year, Mark Peek reported,

“Total second quarter revenues increased 37% year-over-year and license revenues increased 44%. Our non-GAAP operating margin was a record 31.6% and benefited from the strong sequential increase in license revenue. We expect margins to return to below 30% in the third quarter.

Trailing 12-month free cash flows were $1.6 billion, an increase of 56% from a year ago. Our balance sheet remains strong, with cash and investments of $3.7 billion and unearned revenues of $2.1 billion.”

OK, so under vSphere 4 licensing, revenues and profits exceeded market expectations.  And this in a very flat global economy.

So what about performance?  It’s very familiar that Moore’s Law, predicted to be saturated within a decade for the last three, continues skyward with CPU performance (and RAM and disk capacity too).  To pick out an example, look at the relative performance of 2x Intel 5680′s vs. 2x Zeon 2GHz – this works out at around 60% annual compound growth rate between their respective launches.  Core counts simply have to increase as above about 3 or 4GHz, the chips simply get too hot and electricity moves too slowly.

Economy

Outside of VMware’s offices, the economic outlook is rather bleak to say the least.  In the UK, the truth is that Government cuts haven’t even begun (public sector spending is still actually increasing month-on-month), and the Euro zone is in all but meltdown.  Meanwhile the US is only really just contemplating cuts… things are clearly going to get a lot tougher over the next five years.

So what can be the effect of fundamentally increased licensing cost and complexity?  The revisions to vRAM limits help a bit, right now, but the sting comes twice,

• With still no word on how VMware plan to keep up with Moore’s Law, it is effectively impossible to budget for a vSphere deployment.
• The rolling annual average vRAM consumption based charging adds a layer of complexity and uncertainly and actively drives businesses to embark on paper exercises to avoiding license cost, for example shutting down test VMs over the weekend.  Again, how can the resultant year-end cost adjustment be budgeted for?

Outlook

In common with many of the bloggers and VMware communities members, I’ve personally spent thousands of hours on the product, and simply put I love the technology.  It’s made it possible to save a stack of cash in tough trading times, increase service levels and reduce IT’s impact on the environment.  This is clearly a killer combination, and exactly why VMware finds itself where it is.

But the purchasing decision has to be based on return on investment.  Since we can’t now quantify the costs over the products expected useful life, except to use a worst-case scenario, it is now very difficult indeed to propose a VMware based solution, especially in light of the comments from the competitors.

vRAM based charging creates headaches at every level and fundamentally changes VMware’s roll, especially in the SME, from one of enabler to one of restricter.

And while I hate to say it, Microsoft has confirmed they have no plans to go down the vRAM(/vTAX) route, “No Memory Tax. Hyper-V supports up to 1 TB of physical memory per server and up to 64 GB per VM today.”  If only it would support NFS.

Yesterdays vSphere 5 product launch was certainly slick and impressive, with the headline features being right on the money… but one of the more interesting points, the already infamous move to a ‘vRAM’ licensing model, has potentially serious implications for the SME customers currently running on Essentials.

The new model is simple enough – it adds the RAM allocated to running VMs in to the licensing mix.  But the limits vmware have set are already outdated, and therefore give the product no shelf life at all.

Take an Essentials Plus customer with three two-socket hosts, each with a fairly standard 96GB RAM, running well utilised.  Factor in Veeam Essentials for backup and perhaps replication, the latter being to a second Essentials cluster, and today under vSphere 4, the license cost would be:

• vSphere Essentials Plus, for primary site – $4,495
• vSphere Essentials, for secondary site – $495
• Veeam Essentials – $2,000
• Total $6,990

Fast-forward to vSphere 5, which seems to offer SME customers very little new functionality, and the cost will rocket because of the RAM being used in this example.  The Essentials kits cannot be extended past 24GB per CPU (and it has been reported that this will be an enforced limit in the Essentials kits), so the customer would need to look to Standard editions.  But this affects the Veeam licensing too.

Assuming Essentials (144GB total vRAM) would be enough for a limited functionality DR site, the license cost will rise thus:

• vSphere Standard Acceleration Kit, for primary site – $10,000
• vSphere Standard Additional CPU License due to vRAM limits – $995
• vSphere Essentials, for secondary site – $495
• Veeam Management Suite – 6 sockets – $7,200
• Total $18,690

In an instant, the hypervisor layer licensing cost rose over 2.5x, with barely any new features to show for it.

And this is today – we all know that RAM requirements increase over time with Moore’s law – it’s been that way since the 1960′s.  This is quite different to the CPU licensing we’ve seen before, where increasingly power and core count has reduced the CPU count needed over time.  Which, I guess is vmware’s reasoning.

But unless the licensed vRAM amounts are continually adjusted, vmware might just find their customers leaving at rates following Moore’s law too.