vSphere 5 Licensing Thoughts

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/

Comments

vSphere 5 Licensing Thoughts — 4 Comments

  1. Scenario 4 is where we are at (5x256GB RAM). This is where VMware doesn’t appear to have thought far enough ahead. We’re running 5x96GB RAM now and have yet to even come close to CPU. 5×96 cluster is 2×4-core Nehalem. 5x256GB is 2×8-core Westmere. Faster CPUs yet. Our only saving grace at the moment is an inactive DR cluster. That will prop up our vRAM pool for a bit yet. Unfortunately, we bought the new cluster with the expectation of going to 512GB per host in a year or two. When we do that, we will need to seriously evaluate the value of VMware. Unfortunately, HyperV looks REALLY good to those who control budget dollars.

  2. LOL at scenario 3!

    “Historically, this is a rare configuration that is general only used in a few special cases.”

    You can say that again! Historically 8-core cpu’s were non-existant. Not so today. Not so a year ago even.

    No… This year we would get a DL580 G7 with 4 Intel E7-4870 cpus and 512GB RAM. It would be a 13GB/core ratio which is a fair amount when you take HT into account – and the fact that people would be running Windows 2008R2 64bit in VMs. It would show up as 80 logical cpus. It would easily run 120 guests, each with 4GB RAM allocated.

    It would cost 14000 USD to license with vSphere 4.1 Enterprise Plus.
    It would cost 35000 USD to license with vSphere 5 Enterprise Plus.

    Even if I were to have no oversubscription of RAM and leave 25% of the pRAM unused I’d be looking double the price for my vSphere license…

  3. Vidar,

    I completely agree. As larger configurations become more common, I would hope that VMware would raise the allocation allowed with each license. I still shy away from large memory configurations, due to the cost of memory. Two servers with 96GB RAM can be cheaper than one with 192GB RAM (not as much the case now as a year ago). Another issue I have had with large configurations has been memory speeds. Going over 96GB RAM will generally require a drop in memory speed from 1333MHz to 1066MHz.

    The new licensing model does seem to encourage scaling vertically to 96GB RAM, then horizontally from there. In coming years, that will seem like a very small box. However, I see the reasoning. If a two CPU server will do twice the work in two years, VMware would have to double their price just to maintain profitability. Number of CPU is no longer a valid way to assess the power of a server, while RAM is still more consistent with the ability of a server. I am not sure this was the best route, or that the limits are at the right level, but I do understand the reasoning for a change.

  4. Michael,

    Beware the emphasis on CapEx. The accepted numbers usually fall around $3 in OpEx for every dollar in CapEx, so weigh the operating costs of Hyper-V before being wowed by the upfront purchase price. Besides, Hyper-V is not free in an enterprise environment. There is still licensing and support costs. Less, maybe…free, no. And feature set, no comparison. Further, I truly hope that by the time you are ready to increase your memory, VMware has increased the allotment per license. I don’t see how they number can remain constant over time.

    In a larger environment, I would also recommend discussing an ELA. They are not as scary as they used to be, and can completely change the entire licensing discussion. This could negate the entire vRAM limit discussion.