VMware added over 130 new features to the next version of their flagship hypervisor, vSphere 5. Due to be released in Q3 of 2011, vSphere 5 will see the next step in the evolution of virtualization, enabling a number of new technologies and providing a solid infrastructure for cloud computing. Along with improved features, VMware is also introducing a new licensing model meant to prepare vSphere for the future.
Processors are changing. VMware has acknowledged that the current emphasis on licensing by processor, with restrictions on the number of cores, will not match up to where CPU capabilities are going. With vSphere 4, CPU licenses had core limitations that varied between either 6 cores or 12 cores, based on edition.
Processors with 8 and 12 cores are becoming more common, and will soon be the standard. To accomodate this, VMware has removed all limitations based on processor cores from its vSphere 5 licensing model. However, as new servers with two twelve core processors and high memory capacities become more common, VMware has placed a new emphasis on memory in its licensing model. To be specific, virtual memory is allocated to a running virtual machine.
Let’s first break down the licensing models for vSphere 4 and vSphere 5, then review a few possible scenarios:
| vSphere 4 |
| Edition |
Price |
| Standard |
$795 |
| Advanced |
$2,245 |
| Enterprise |
$2,875 |
| Enterprise Plus |
$3,495 |
|
| vSphere 5 |
| Edition |
Price |
| Standard |
$995 |
| Enterprise |
$2,875 |
| Enterprise Plus |
$3,495 |
|
Scenario One – 4 Moderate Servers:
CPU Per Server = 2 x 6-Core CPU
RAM Per Server = 96GB
CPU in Pool = 8
RAM in Pool = 384GB
vRAM Licensed in Pool = 384GB
In this scenario, nothing will change. The only potential impact would be if you heavily oversubscribed memory and actually had more than 384GB of vRAM assigned to running VMs simultaneously. Though not recommend, this could be done. In that case, one additional license would be added to the pool; the additional CPU would not be assigned to a server, but the additional vRAM would be consumed from the pool. |
|
Scenario Two – 4 Larger Servers:
CPU Per Server = 2 x 6-core CPU
RAM Per Server = 128GB
CPU in Pool = 8
RAM in Pool = 512GB
vRAM Licensed in Pool = 384GB
In this scenario, migrating to the vSphere 5 licensing model would likely not have an immediate impact unless more than 75% of physical RAM was currently committed to running VMs. Once 384GB of vRAM is allocated, an additional license will be required. The CPU of the new license will not be used, but the licensed vRAM pool will grow to 432GB. If the environment grows beyond 432GB of allocated vRAM, then add another license and grow the vRAM pool to 480GB. |
|
Scenario Three – 4 Very Large Servers:
CPU Per Server = 2 x 8-Core
RAM Per Server = 192GB
CPU in Pool = 8
RAM in Pool = 768GB
vRAM Licensed in Pool = 384GB
This scenario is most likely going to impacted. Historically, this is a rare configuration that is general only used in a few special cases. Often, the CPU in this scenario will max out long before the RAM is consumed. In this scenario, additional licenses will have to be purchased for the purpose of adding additional RAM to the vRAM pool. The amount of additional licenses will be driven by overall consumption, and not tied directly to any one server. |
|
Scenario Four – 2 Very Large Servers (migrating from 4 large servers)
CPU Per Server = 2 x 12-Core
RAM Per Server = 192GB
CPU in Pool = 4
RAM in Pool = 384GB
vRAM Licensed in Pool = 192GB
This is a hardware refresh scenario resulting from migrating from the 4 Moderate Servers shown in Scenario one in order to leverage higher CPU core densities and higher RAM capacities of the newer servers. Though there are only 4 CPUs in this configuration, you already owned 8 CPU licenses from scenario one. Those additional licenses would bring the vRAM pool up to 384GB, matching the physical RAM in the pool. You would be going from scenario one with 48 CPU cores and 384GB RAM, to scenario four with 48 CPU cores and 384GB RAM. This scenario cuts 4 physical servers down to 2 and 8 CPU sockets down to 4, but does not change overall CPU or memory capacities. Likewise, licensing requirements would be unchanged. |
|
Scenario Five – 4 Moderate Servers:
CPU Per Server = 2 x 6-Core CPU
RAM Per Server = 96GB
CPU in Pool = 8
RAM in Pool = 384GB
vRAM Licensed in Pool = 384GB
In this scenario, the servers are dedicated for a disaster recovery role. Their resources are generally unused. By connecting the vCenter server in this environment to your production vCenter server (as linked vCenter servers), you not only gain better visibility for administration but you will also bring an additional 384GB of vRAM into your production pool for allocation. In a linked configuration, all vCenter servers will pool their licenses into one aggregate pool. |
|
Summary:
There are now two factors to consider in determining license needs. First, determine licensing needs based on physical CPU count. Then assess the total vRAM allocation across all VMs within your environment (which may span multiple locations if using linked vCenter servers). Your license count will need to be sized to cover both of those numbers.
One option to consider is leveraging unused vRAM capacity from environments that may traditionally not consume high levels of vRAM. These could include environments hosting Unified Communications deployments or even disaster recovery environments. Simply use the linked vCenter feature to combine all of these licenses into a common pool. I have always recommended organizations link all of their vCenter servers together, for the many administrative advantages this configuration provides. However, with the new licensing model, such a configuration can also provide for better license utilization.
In terms of availability and agility, it is also important to note that vRAM limits are “soft” limits that are monitored and alerted on, but will not actually prevent a virtual machine from being powered on. You are bound by your End User License Agreement to comply with these license limits, but VMware has chosen to monitor based on this metric and not actually impose hard limits that may negatively impact your ability to respond to business demands.
Related links:
http://www.vmware.com/files/pdf/vsphere_pricing.pdf
http://www.vmware.com/files/pdf/techpaper/Whats-New-VMware-vSphere-50-Platform-Technical-Whitepaper.pdf
http://www.virtu-al.net/2011/07/14/vsphere-5-license-entitlements/
Today, I wanted to step away from a technical post to wish John Troyer a happy birthday. In fact, John is the friend that inspired me to first start blogging. In 2009, I received an email from John Troyer that informed me I had won a vExpert award from VMware. This was a new program that VMware was starting, and John Troyer was at the helm. That year, at VMWorld 2009, John organized some events for us and held a vExpert forum. There, he had Jason Boche and Steve Kaplan speak about their experiences in blogging, and I decided to start my own. That turned in to me writing for Tech Target, and eventually led to me leaving my employer of 12 years to work with Steve Kaplan at INX.