VMware vSphere 5 licensing demystified

VMware’s vSphere 5 licensing model enables businesses move to usage-based costing. Here’s a look at the updated vRAM pooling option in vSphere 5 licensing.

Server virtualization player VMware recently vSphere 5, following the widespread success of the product’s earlier version, vSphere 4. VMware vSphere 5 facilitates the move to shared infrastructure-as-a-service. Since the release of VMware vSphere 5, there has been a buzz in the market, mainly due to the vSphere 5 licensing scheme by VMware, rather than any revolutionary features of the latest release. VMware has altered the vSphere 5 licensing model to enable customers to move to a more cloud-like, “pay for consumption” mode. This tip explains the VMware vSphere 5 licensing model and its implications for users.

Vsphere 4 licensing v/s vSphere 5 licensing

The vSphere 5.0 licensing model is per processor (CPU) with pooled vRAM entitlements. In vSphere 4 and vSphere 4.1, VMware used a per-CPU licensing model based on the number of server cores. But in vSphere 5 licensing, VMware has linked cost to the amount of physical that businesses allocate to virtual machines on the host. Users can pool the allocation, called vRAM, across the entire data center, without any size limits on the pooling.  Vsphere 5’s virtual machines support up to 32 virtual CPUs, compared with eight virtual CPUs for vSphere 4. Vsphere 5’s virtual machines can also hold up to 1 TB of virtual RAM, compared with 256 GB for the predecessor.

The pooling of vRAM makes vSphere 5 licensing extremely flexible, and can reduce the number of required vSphere licenses since vRAM entitlements can be shared among multiple hosts. There are no restrictions on how vRAM is consumed across virtual machines and CPUs. At any given point in time, the amount of vRAM consumed by active virtual machines on a CPU could exceed the base entitlement of the vSphere 5 license assigned to that CPU. As long as the total consumed vRAM across all virtual machines managed by one of more VMware vCenter instances is less than or equal to the total available vRAM, vSphere is correctly licensed. Following user inputs on the initial VSphere 5 licensing model, VMware capped the amount of vRAM count in any given VM. Now, not even the “monster” 1TB vRAM VM, will cost more than one vSphere Enterprise Plus license.

Vsphere 5 licensing options

The following vSphere 5 editions are available, along with the earlier and revised licensing options:

vSphere 5 edition vRAM (GB) entitlement per physical CPU Max vCPU/VM
vSphere 5 Hypervisor (free version) 8 32 8
vSphere 5 Essentials 24 (max. 6 processor license, total 144GB) 32 (max. 6 processor licenses, total 144GB) 8
vSphere 5 Essentials plus 24 (max. 6 processor license, total 144 GB) 32 (max. 6 processor licenses, total 144 GB) 8
vSphere 5 Standard 24 32 8
vSphere 5 Enterprise 32 64 8
vSphere 5 Enterprise plus 48 96 32

Why the change in vSphere 5 licensing?

vSphere 4.x licensing did not reflect the fact that vSphere excels at pooling physical hardware resources across the entire data center and presenting them as a single, unified, shared infrastructure — an innovation that is one of the core pillars of cloud infrastructure. The hardware-based licensing model of vSphere 4.x made it difficult for users to transition to the usage-based cost and charge-back models that characterize cloud computing and IT-as-a-Service. As CPU vendors offer multi-CPU cores and configurations change frequently, it was logical for VMware to divert from the core licensing model.

Vsphere 5 licensing example

Consider the case of a user with two 2-CPU hosts, desirous of licensing the vSphere Enterprise edition, which has vRAM entitlement of 64 GB per CPU. Each physical CPU requires a license, so a minimum of four vSphere Enterprise licenses are required. More licenses will be required if the user needs to use vRAM over and above the 256 GB (4 x 64 GB) vRAM entitlement with four licenses.

Next, the user creates 20 virtual machines, each with 4 GB of vRAM, and plans to run five virtual machines on each of the four CPUs. Both hosts are in the same vRAM pool, as they are connected to the same vCenter server running the same vSphere edition. This vRAM pool allows VMware Distributed Resource Scheduler (DRS) and VMware vMotion to move the virtual machines between any of the CPUs without needing additional licenses. Even if all 20 virtual machines were running on a single CPU, no additional vRAM capacity would be required, because the pooled vRAM entitlement would not be exceeded.

In vSphere 5 licensing, users can increase vRAM capacity in two ways:

  • Add vSphere licenses of the same edition.
  • Upgrade licenses to an edition with a higher vRAM entitlement.

In the above example, suppose the user adds an additional host with a single CPU. This necessitates purchase of an additional license of vSphere Enterprise, raising the vRAM capacity by another 64 GB to a total of 320 GB. The user adds 10 virtual machines that have 8 GB of vRAM each on the host. Although the 80 GB of vRAM running on the host is more than its single CPU is entitled to, the other two hosts have enough excess vRAM, so no additional licenses are required.

Upgrade path

Vsphere customers with an active SnS contract are entitled to upgrade to vSphere 5.0 at no extra charge. Organizations that purchased vSphere 4.x Standard with vMotion and Storage vMotion are entitled to vSphere 5.0 Enterprise Edition. Users with an expired SnS must pay reinstatement fees to purchase supported upgrades.

Reinstatement fees are based on the following criteria:
• The applicable SnS fees for the current contract term.
• Fees that would have been paid for the period of time that the customer’s SnS contract was not active.
• A 20 percent fee on the sum of the fees in the preceding two criteria.


vSphere 4.0 vSphere 5.0
Enterprise Plus Enterprise Plus
Enterprise → Enterprise
Advanced → Enterprise
Standard → Standard 
Essential Plus → Essential Plus 
Essentials → Essentials


Vsphere 5 license pricing 

  Standard Enterprise




Price (license only) $995 $2875 $3495
vRAM 24 32 GB 32 64 GB 48 96 GB
vCPU/VM 8 8 32
High Availability Available Available Available

 Data Recovery


Available Available Available



Available Available Available

Virtual Serial Port Concentrator


Not Available Available Available

Hot Add


Not Available Available Available



Not Available Available Available

Fault Tolerance


Not Available Available Available

Storage APIs for Array


Not Available Available Available

Storage vMotion


Not Available Available Available

Distributed Resource Scheduler & Distributed Power Management


Not Available Available Available

Distributed Switch


Not Available Not Available Available

I/O Controls (Network and Storage)


Not Available Not Available Available

Host Profiles


Not Available Not Available Available

Auto Deploy*


Not Available Not Available Available

Policy-Driven Storage*


Not Available Not Available Available
Storage DRS* Not Available Not Available Available

* in vSphere 5.0

Drawbacks of vSphere 5 licensing

In vSphere 4.1, a user who configured the entire RAM on a 128 GB, two-socket server required only two licenses. With vSphere 5, that user will need three licenses, even if the usage is only 96 GB of (and has made an allocation of the entire 128 GB). In such cases, Vsphere 5 licensing could prove costlier than the previous model, but in the long run it may be beneficial due to leveraging of pooled licensing options.

Vsphere 4 and vSphere 5 licensing comparison 

Total number of hosts = 1

CPU count = 2

Cores/CPU = 12


Target utilization = 100%


















License GB)

vSphere 4.1

License Count


vSphere 5.1

License Count



License Cost for

vSphere 4.1


License Cost for

vSphere 5.1

Standard 2 24 64 64 $995 24 32 4 32 $ 3980 $ 2985
Enterprise 2 24 64 64 $2875 32 64 4 21  $ 11500  $ 2875
Enterprise Plus 2 24 64 64 $3495 48 96 2 21  $ 6990 $ 6990


Anuj SharmaAbout the author: Anuj Sharma is an EMC Certified and NetApp accredited professional. Sharma has experience in handling implementation projects related to SAN, NAS and BURA. He also has to his credit several research papers published globally on SAN and BURA technologies.

Read more on Server virtualisation platforms and management