Reading through the vSphere 5 Communities Licensing Thread, one is struck by some of the similarities between this debate and its associated heartburn and the heartburn and debate over how we pay taxes to the government. When it comes to taxes we have certain expectations as to how the system should work. 

Here some things that we expect of our tax system:

  • The notion of vertical equity. What this means in English is that people who can afford to pay less should pay less, and people who can afford to pay more should pay more.
  • The notion of horizontal equity. This means simply that people at similar income levels and similar situations should pay the same taxes as each other (or at least live by the same rules).
  • Taxes should be predicable into the future. This is true for consumers, but especially true for businesses as businesses need to be able to make an investment today, and know how the returns from that investment will be taxed in the future. A corollary of this is that things should not change radically on you after you have invested in something based upon one set of terms and one set of assumptions.
  • Compliance (figuring out how much you owe), should not be a burdensome task. It should be easy to get the data and keep the data that you need to figure out how much you owe.
  • The tax system should not penalize what is generally accepted to be desirable behavior. For example  the tax system should not penalize you for working extra hard if you choose to do so.
  • Finally and most importantly the tax system should encourage growth. At an individual level it should make it easy for people to advance, and at business level it should make it easy for new businesses to be formed and existing ones to grow.

The vSphere 5 Pricing (per CPU and per GB of vRAM)

The table below shows the pricing for each of the vSphere 5 editions, the CPU entitlement and the vRAM entitlement for each license, as well as the resulting cost per CPU entitlement and cost per vRAM entitlement.

Product/Edition Essentials Essentials
Plus 
Standard Enterprise Enterprise
Plus 
 vSphere 5 Pricing by Edition per Metered CPU and vRAM resources
Price $495 $4,495

$10,000

$17,495

$21,995

Included CPU’s 6 CPU’s 6 CPU’s 8 CPU’s 6 CPU’s 6 CPU’s
$/CPU $83 $749 $1,250 $2,916 $3,666
Included GB vRAM 24 24

24

32 48
$/GB of vRAM $21 $187 $417 $547 $458

Applying the above Concepts to vSphere 5′s new vRAM Pricing

Let’s apply these concepts one at a time to the new vRAM pricing for vSphere 5:

  • Vertical Equity. Here VMware has always been fair. The Editions of vSphere that are targeted at the SMB and SME markets (while missing many of the nice high end features in the Enterprise Editions) are considerably less expensive than the full enterprise editions that large enterprises use. Therefore small businesses who can arguably afford to pay less for a virtualization platform are afforded this option by VMware. Of course this ignores the question of why SMB’s and SME’s who can get Hyper-V for free should pay anything for vSphere, but that is another article entirely.
  • Horizontal Equity. Here is where things start to get tricky. VMware makes the point that the vRAM entitlements are large enough to handle the needs of “most” of their customers. However it is already clear that customers who have pushed the envelope on density just a bit, or who have virtualized lots of memory heavy applications will have to pay a lot more for vSphere 5 than they paid for vSphere 4. So this boils down to whether or not a customer with 4,000 VMware hosts who is pushing the envelope on density is the “same” as a customer who is not. It also gets down to who should benefit as the customer drives up density. It would seem that the benefit of driving up density is a benefit of the platform and that the customer having paid once for the platform should not have to pay more to get the maximum benefit from it. The vSphere 5 licensing therefore fails this test.
  • Predictable into the Future. It should be easy to forecast  your licensing costs. With vSphere 5 this requires knowing what applications will be running in the environment, and what their vRAM allocations will be. However, the vSphere team cannot be expected to know how much memory applications will use in the future. The next version of a purchased application could simply require more memory (which may be specified by the applications vendor and out of the customer’s control). Having your application vendor change that memory specification should not cause you to have to go get more vSphere licenses. Similarly if the team building an application decides to increase its functionality, or make some other change that boosts memory needs that should not drive the need for more vSphere 5 licenses. VMware does get an enormous amount of credit for grandfathering all existing ELA customers under their existing terms. So all existing ELA customers will be able to buy vSphere 5 under the same terms that they are currently buying vSphere 4 in their existing ELA. So the new licensing fails this test for people who in in complex situations and who are not under ELA’s.
  • Compliance should be easy. When it comes to vSphere 5 licensing that means that it should be easy to figure out how many licenses you need right now and how many you will need into the future. If you have one vSphere environment all pointing to one vCenter then this is not so hard. If, as is the case with many enterprises, there are multiple disparate virtual data centers owned and run by different groups, then consolidated reporting and analysis could be almost impossible. This is also an area where “pooling of vRAM” just does not work. If the test group has purchased N vSphere 5 licenses that have a certain amount of vRAM associated with them, they are not going to let another group use “their” vRAM just because it is technically in the same pool. The new licensing therefore also fails this test.
  • Desirable behavior should not be penalized. In this context desirable could mean many different things. For example, for a performance critical application, ensuring that the application met its response time goals would be highly desirable. In order for this to be achieved, it may make sense to allocate 20% more memory to the application that it uses at its peak in order to ensure that memory bottlenecks never occur. In this case meeting the desired goal of applications performance is in fact inhibited by this new licensing as this new licensing will in the aggregate make being conservative about memory allocations more expensive. This also gets back to the previous point about who should benefit when the customer pushes the density envelope. Clearly it is in VMware’s interest for customers to do this, as it improves the overall value of the vSphere story. For VMware to slap a tax on density therefore seems to make no sense. The new licensing therefore fails this test as well.
  • Promote growth. This is where the new vRAM entitlements may in fact be a fatal mistake for VMware. Because it may turn out that with this new pricing, adding new applications to an existing environment (increasing density) may become much more expensive than it was before. It may also turn out that virtualizing the next 60% of applications that are not virtualized yet may be more expensive than anticipated, since those applications are likely to be more memory intensive than what has been virtualized to date. The new vSphere licensing clearly fails this test.
Conclusion
VMware has done the right thing by taking care of their enterprise customers and making sure that they know that they can purchase vSphere 5 licenses under the terms of their existing ELA’s. The vast majority of smaller customers who run a small number of purchased applications are unlikely to be impacted by the new vRAM licensing, as there is probably plenty of vRAM headroom to take care of their needs. The issue is with customers who are not quite large enough to have an ELA, and who have sophisticated mixes of purchased and internally developed applications – and who are trying to push the density envelope in order to maximize their return from their investment in VMware.  These customers are going to have to look at the new licensing in the above terms and make their own decisions.

Share this Article:

Share Button
Bernd Harzog (324 Posts)

Bernd Harzog is the Analyst at The Virtualization Practice for Performance and Capacity Management and IT as a Service (Private Cloud).

Bernd is also the CEO and founder of APM Experts a company that provides strategic marketing services to vendors in the virtualization performance management, and application performance management markets.

Prior to these two companies, Bernd was the CEO of RTO Software, the VP Products at Netuitive, a General Manager at Xcellenet, and Research Director for Systems Software at Gartner Group. Bernd has an MBA in Marketing from the University of Chicago.

Connect with Bernd Harzog:


Related Posts:

3 comments for “VMware vSphere 5 vRAM Pricing and Taxes

  1. July 29, 2011 at 12:32 PM

    The new vSphere 5 vRAM pricing has been a hot button issue with a lot of my clients recently. While some will be affected more than others, the crux of the issue seems to be that for a long time VMware pushed memory over subscription as a way to squeeze more VMs onto a single host. Now they are saying that you will have to pay for what they were advising. This new licensing scheme puts people back in the old management mindset where they are closely managing the RAM on each server (now a VM on a host.) Customers will need a lot of help with audits and maximizing environment utilization prior to moving to vSphere 5.

  2. Bharzog
    July 29, 2011 at 12:50 PM

    The need to “closely manage” and “get a lot of help with audits and environment utilization maximization” is what concerns me greatly on behalf of VMware. vSphere is infrastructure software. It should not be hard to deploy. In fact VMware has made vSphere 5 remarkably easy to deploy (see Steve Beaver’s post) at a technical level. To put all of the economic and management overhead on top of what is now a very simple technical process is, in my humble opinion, not in VMware’s interest (nor is it in the interest of VMware’s customers).

Leave a Reply

Your email address will not be published. Required fields are marked *


nine + = 18