VMware announced an update in the licensing for vSphere 5. There has been a lot of discussion. Especially about the introduction of vRAM as a limitation to the amount of VMs you can deploy. It’s good to see that VMware is open for discussion about their licensing change and has taken the reactions of customers and partners about it in consideration.
This change isa the result of some good discussion about the vSphere 5 licensing change. In my opinion these new vRAM entitlement are a better representation of the 90% of customers, the amount that VMware was targeting, that should not be affected by the licensing change. This makes it possible for most vSphere 4 customers to migratie to version 5 without having to buy extra licenses and I think that was the message that came out of the discussion between VMware, its customers and its partners.
These are the changes made by VMware with regards to licensing :
An increased vRAM entitlements for all vSphere editions, including the doubling of the entitlements for vSphere Enterprise and Enterprise Plus. This change addresses concerns about future-looking business cases that were based on future hardware capabilities and the previous vSphere licensing model. Below is a comparison of the previously announced and the new vSphere 5 vRAM entitlements per vSphere edition:
|vSphere Edition||Previous vRAM entitlement||New vRAM entitlement|
|vSphere Enterprise+||48 GB||96 GB|
|vSphere Enterprise||32 GB||64 GB|
|vSphere Standard||24 GB||32 GB|
|vSphere Essentials+||24 GB||32 GB|
|vSphere Essentials||24 GB||32 GB|
A capped amount of vRAM is counted in any given VM, so that no VM, not even the “monster” 1TB vRAM VM, would cost more than one vSphere Enterprise Plus license. This change also aligns with our goal to make vSphere 5 the best platform for running Tier 1 applications.
An adjusted of the model to be much more flexible around transient workloads, and short-term spikes that are typical in test & development environments for example. We will now calculate a 12-month average of consumed vRAM to rather than tracking the high water mark of vRAM.
For more information see the blog post on the VMware partner blog site here.