What is vRAM?
vRAM or virtual RAM is the amount of allocated memory to a VM. VMware is basing vSphere licenses on the total amount of vRAM allocated to powered on VMs in a vCenter cluster.

• Standard edition vSphere is sold in blocks of 24GB of vRAM per socket (CPU)
• Enterprise vSphere is sold in blocks of 32GB of vRAM per socket (CPU)
• Enterprise Plus in blocks of 48 GB of vRAM per socket (CPU)

This vRAM is allocated to each physical CPU.  So if you have a dual socket box and you want Standard Edition, you must buy 2 licenses, which entitles you to 48GB total of vRAM.  You can purchase additional entitlements to increase the amount of vRAM per server.  So while there is still a "CPU" component to the pricing, this is primarily to tie the virtual ram to a physical device.

Besides different features between the versions, the only other difference is that Standard and Enterprise editions have a maximum of 8 vCPUs for a VM.  Enterprise Plus allows up to 32 vCPUs for a VM. Enterprise plus will be needed for very large applications that require more than 32 vCPUs. VMware is basically shifting to memory based pricing.

Price Increases for Some
In VMware’s example presentation, they showed that a “typical customer” will have cost neutrality.  For most customers with low core density and memory density, this could be the case. However, Elias Khnaser writing in Virtualization Review and an early Beta customer revealed

"But what VMware failed to understand is that it will cost me about three times as much to upgrade to vSphere 5 or to roll out a new environment."

Search "vRAM" or "#vtax"on Tweetdeck and similar comments from others quickly surface.  Beneath this blog posting are links to several blogs that both see problems and no issues with the changes.

For a VMware environment, pricing is fairly straightforward to determine. Assuming you don’t over allocate memory, simply take the total physical memory of your environment, and purchase enough vRAM licenses so the amount of physical RAM = the amount of vRAM. This is memory based pricing, it is just virtual memory. Of course, you don't have to purchase vRAM in the equivalent amount of your RAM. You just need to make sure you have sufficient vRAM to cover your powered on virtual machines.

For customers who over allocate total physical memory on a per host basis, and the practice is not uncommon based on a recent Virtualization Management Index Report from VKernel, that same over-allocated server will now cost you significantly more. Over-allocation at the server level involves deploying more vRAM across your VMs than you have physical RAM. In this case, you are betting that peak memory utilization per VM never hits the total vRAM allocation at the same time. However, in this over-allocation scenario, you pay VMware for use of the virtual memory you are allocating even though you actually don’t have any additional underlying physical resources.

Over-allocation is a bet against all your VMs requiring peak memory at the same time and not a bad strategy if you understand memory usage patterns in your environment. vRAM pricing since it is based on virtual memory consumption and not physical consumption, removes many incentives to over allocate RAM and spread server costs out across as many VMs as possible. This may perhaps be the biggest negative for customers with this pricing change.

Customers who have purchased memory dense machines, regardless of core counts, will see price increases to cover the amount of memory in their systems. Bob Plankers of the Lone Sys Admin has an interesting example on his blog with both pro and con comments about the new pricing. There have been other questions about the impact of this pricing on VDI environments. One blogger encouraged everyone to run the numbers themselves which makes sense.

For older machines that have few cores and few CPUs, and hence not that much memory capability, the new pricing should not impact their environment.  For newer, scale up systems, however, the increased memory to CPU ratio will cause a pricing change.  Going forward, as memory per physical socket increases, this will increase the licensing fees as the servers have more capabilities.

Finally, unless the announcement is not clear, VMware vCenter Operations products will still be based on a per-VM pricing model. VKernel continues to charge on a per socket-based pricing model since we believe charging by the physical resource encourages customers to maximize VM density and lower their overall CAPEX and OPEX costs.

Minimize vRAM Use to Lower Costs
The new pricing model is memory based. It is based on the virtual memory allocated to a powered-on VM regardless of whether the VM is actually using the memory. Hence, the less memory you allocate to a VM, the cheaper your licensing costs.

Capacity management for memory becomes critical. To be effective, VMware customers need to understand the peak memory needs for a VM, and allocate just enough memory to cover these peak needs.  By doing this, they will minimize over allocation of memory to VMs, and increase the number of VMs they can put on a server for a given vSphere license cost. The key here is to understand PEAK memory usage, not average, and allocate sufficient memory to cover peak. Most VMware customers can’t easily get peak usage values for a large environment. To overcompensate for this lack of visibility, they simply over allocate memory to a VM. In the old pricing model, this was OK. In the new model, this will cost you.

VKernel vOperations Suite contains an Optimizer that will reveal both peak and average memory values. This is a significant differentiator with VMware CapacityIQ which only looks at average values.

Chargeback Gets New Life
It is one challenge to identify the VMs in your environment that are over-allocated memory. It is another challenge to convince reluctant application owners to return memory to your pool so you can reallocate the memory and avoid purchasing more vSphere licenses.

Chargeback is an important application to help here. By at least showing IT leadership the cost of memory over allocation, there is more incentive on everyone to reduce memory allocations. But memory-based pricing doesn’t make chargeback any easier as some blogs are claiming. Determining the rate of chargeback for a VM is no simpler than it was with CPU based limitations. Yes, the more memory you consume, the higher your licensing costs. But with so many other costs that are overhead related or not based on consumption, memory-based vSphere licensing is not going to make calculating chargeback any easier.

By shifting to a consumption based model, VMware is highlighting the need for IT to align costs with consumption. However, the same business problems of chargeback still remain. VKernel offers the vOPS Reporting and Chargeback application for quick implementation of chargeback.

Conclusion
VMware’s memory based pricing model announcement just adds more pressure for virtualization admins to properly manage memory capacity. VKernel can help virtual admins with this challenge.

Bryan Semple
Chief Marketing Officer

Related Posts:

• XenDesktop says goodbye to vSphere?
• vSphere 5 licensing with vRAM isn’t that bad at all
• Will VMware's new licensing scheme open the door for Microsoft?
• VMware vSphere 5 licensing aka #vTax : the opinions and math (Contains long list of related posts)
• Is VMware screwing the non-View VDI community with the vSphere 5 licensing changes?