VMware’s vSphere 5 new licensing model raised eyebrows and tempers across the industry just three weeks ago. Bowing to the negative response, VMware has announced three changes that should appease customers – but will still likely lead to higher virtualization costs for VMware customers.

Customer backlash with original vSphere 5 licensing model
When first announced, the new vSphere 5 licensing model was positioned as being a positive for customers. VMware didn’t however mention that each vSphere 5 CPU-based license came with a fixed amount of virtual RAM (vRAM) entitlements. If your configuration has more vRAM than is entitled for use with the CPU license of vSphere 5, you need additional licenses.

As I’d previously covered, VMware customers complained of 2x to 3x higher licensing costs for vSphere 5 versus vSphere 4.

VMware announced three changes that attempt to address concerns around vRAM as a licensing metric and the resulting increases in cost for a VMware customer. Users commenting on VMware’s forum seem to be less irate with the new changes but still question the vRAM model.

Increasing vRAM entitlements per license
First, the vRAM entitlement per vSphere edition has been increased from 24/24/24/32/48 to 32/32/32/64/96 gigabytes for vSphere Essentials, Essentials Plus, Standard, Enterprise and Enterprise Plus respectively.

Let’s evaluate the result of this modification on our previously discussed customer example. We have a customer with a two-socket processor with no more than 12 cores per socket, with 256GB of RAM.

Under the original vSphere 5 licensing model, the customer needed six CPU-based vSphere Enterprise Plus licenses — not two — to be entitled in order to use the full 256GB of RAM on the system.

Under the revised vSphere 5 licensing model, the customer would need three CPU-based vSphere Enterprise Plus licenses — not two.

The first two CPU-based licenses, sufficient for the two CPUs on the system, would have provided 96GB of vRAM entitlement each, for a total of 192GB.

However, since the scenario included 256GB of RAM, the customer would have had to buy a third vSphere CPU-based licenses in order to use the full 256GB of RAM.

Using the old vSphere 4 licensing model, the customer would only need to purchase 2 CPU-based vSphere Enterprise Plus licenses. As a result, a customer in this situation would still be paying 50 percent more than they did with vSphere 4, but at least its not 300 percent, as was the case with the original vSphere 5 licensing model.

Capping vRAM usage to encourage virtual machines with large amounts of vRAM
The second licensing change VMware announced is that the amount of vRAM counted against any one virtual machine is capped at 96GB. Using our example above, if your system has 256 GB of physical RAM and you want to allocate 128GB of vRAM to two virtual machines, VMware will only reduce your vRAM allocation from 256 to 192GB. As a result, you’d be 64GB under your 256 vRAM entitlement even while using a full 256 GB of vRAM across the two virtual machines.

VMware made reference to the fact that customers could use a 1TB vRAM virtual machine wile only reducing their vRAM allotment by 96GB from the total vRAM pool.

Customers would still need sufficient vSphere CPU-based licenses to use the 1TB, or whatever number, of physical RAM available on the system. As such, this change only applies to how much vRAM is used from within the vRAM pool. This is pertinent for additional vSphere CPU-based licenses that may be needed in following years if the customer surpasses the total pooled vRAM allotment in the previous year.

VMware aims for Tier 1 applications
With the third licensing change VMware now calculates a 12 month average of consumed vRAM rather than tracking the high water mark of vRAM used.

By limiting the vRAM counted per VM to 96GB and tracking a 12 month average of vRAM usage, it’s less likely that a customer will use more than their vRAM allotment per year.

The combination of the second an third licensing change make it much more attractive for customers to run multiple Tier 1 applications on VMware by reducing the licensing hurdles for doing so.

The risk however, especially after the current licensing fiasco, is how licensing may change in the future, after customers are heavily reliant on VMware for even their Tier 1 applications.

As we’ve discussed before, it’s good to evaluate options, especially as open source hypervisors become more mature.

As you move more business critical applications to VMware, consider moving some of your existing, less critical, VMware applications and environments to an open source hypervisor.  Using a mixture of VMware and an open source hypervisor, is likely your best long term option for balancing costs and flexibility.

I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”