vSphere 5.0 Licensing Changes

One of the major announcements today that has gotten customers worked up a little bit is the change in the licensing model with vSphere 5.0. In previous versions licenses were tied to the number CPU sockets, and the various editions had limitations on maximum physical memory supported and the number of processor cores. These limitations were spread over six major SKUs. With v5.0 that’s history, and you now need to keep track of what they call vRAM entitlements and CPU sockets. Oh ya, one SKU got dropped, Advanced edition.

Lifted are the limitations on CPU cores and maximum physical memory. Have a 256GB server with 32 cores? No problem, you can use Standard edition. Nifty? Well, remember the new vRAM licensing concept. This gets a bit confusing at first, so stick with me.

vRAM is the amount of consumed VM memory across the entire environment (within a given SKU, such as Enterprise edition). This not the amount of physical RAM, mind you, but the total amount of RAM allocated to all running VMs. For example, if you have 10 4GB VMs, that would be 40GB of vRAM. Transparent page sharing, ballooning, or other memory conservation features will not help you here.

Now the kicker is that each licensing SKU, such as Enterprise edition, come with a fixed amount of vRAM entitlements. For example, Enterprise edition has a 32GB per socket entitlement. If you have four dual socket servers then you get 256GB of vRAM entitlements (4 x 2 x 32GB). This means on the four physical servers all of your powered on VMs cannot use more than 256GB of RAM. VMware provided the slide below that compares vSphere 4.1 and 5.0 licensing.

Remember vRAM is a pooled asset, so vCenter will manage and track the pooled usage. Linked vCenter instances will pool their memory together. Pools are based on the license SKU, so you have separate pools for each of the five editions. Since it is a pooled asset, you can legally exceed the entitlement on one or more servers, as long as there is excess unused capacity on other servers in the same pool.

What I also found interesting is that VMware will not be selling vRAM only entitlement SKUs. The only way to buy more entitlements is to either upgrade to the next SKU level (.e.g. Enterprise to Enterprise Plus) or buy more socket licenses. According to VMware this change will only result in increased costs for 4% of customers. The VMware chart below shows the list price for the licenses, vRAM entitlements, and features.

How VMware thinks this makes licensing simpler is beyond me. This major licensing change will likely impact large scale designs. So servers like Cisco UCS or large HP blades that can support 384GB or more of RAM could require a lot of new licenses to fully utilize their memory.

Another interesting consideration is VDI, such as XenDesktop. Typically these servers have a lot of memory (96GB to 144GB), and are packed to the gills with running VMs so you can reduce the per-VM hardware costs. The sweet spot for VDI servers has been 2-socket servers packed with memory. For a large scale VDI deployments that has high concurrent usage, licensing could become complex to manage. VDI may not need fancy features like I/O control or storage DRS, so customers may look at lower SKU editions like standard edition. But with the lower vRAM entitlements, you really have to do some careful calculations and likely increase the number of licensed sockets to stay compliant.

—
Update 2: VMware has now announced their vSphere 5.0 Desktop license for VDI. Basically you license desktop VMs in bundles of 100 for $65 each. The host must be dedicated to VDI (no server VMs), and the ESXi functionality is that of enterprise plus, and NO vRAM entitlement limitations. See their blog post here. However, this is only good for NEW vSphere 5.0 Desktop licenses. Customers with existing vSphere enterprise plus licenses that are upgraded to 5.0 are still bound by the vRAM entitlement restrictions.

The calculations below were made prior to the new Desktop SKU. I am glad VMware realizes there are non-View VDI solutions and that customers needed a price break to make VDI more affordable. Thank you VMware!

Update 3: Brian Madden did a more exhaustive VDI cost calculation matrix in his post here.

—

Let’s take an example of ~1800 VDI users. Using current 12-core servers, you could probably get ~90 users per server with 144GB of RAM, allocating 1.5GB per VM. For 1800 users that equates to 20 servers, with no spare capacity. Let’s throw in three servers for extra capacity, for a total of 23 servers.

Standard:
vSphere 4.x: 23 x 2 x $995 = $45,770 (46 licenses)
vSphere 5.0: (1800 VMs x 1.5GB) / 24GB = $111,937 (112 licenses)
$/VDI VM = $25 vs. $62 (240% increase)

Enterprise:
vSphere 4.x: 23 x 2 x $2875 = $132,250 (46 licenses)
vSphere 5.0: (1800 VMs x 1.5GB) / 32GB = $244,375 (85 licenses)
$/VDI VM = $74 vs. $136 (84% increase)

Enterprise Plus:
vSphere 4.x: 23 x 2 x $3,495 = $160,770 (46 licenses)
vSphere 5.0: (1800 VMs x 1.5GB) / 48GB = $199,215 (57 licenses)
$/VDI VM = $89 vs. $111 (25% increase)

Of course these costs do not take into account other unused capacity in the environment, so this is ‘worst case’ pricing. But remember that vRAM entitlements are SKU specific. So if you use standard edition licenses for VDI, but enterprise plus for servers, you need to keep track of two separate vRAM pools. What’s interesting is that the enterprise edition costs substantially more per VDI VM with v5.0 ($136) than enterprise plus ($111), because of the vRAM entitlement differences.  VMware View users may not be hit as hard, but I’m not as familar with those licensing specifics as I support a XenDesktop environment.

As noted in a VMware FAQ, there is no “hard stop” if you reach the vRAM limit in the standard, enterprise and enterprise plus SKUs. There is a hard stop for the vCenter server for Essentials SKU. So in most editions vCenter will only nag you if you are out of compliance, but you won’t be left in the lurch unable to power on VMs. Of course you should adequately predict vRAM usage and purchase licenses in advance to stay ahead of the curve and be completely compliant.

It will be interesting to see how much customers push back on this new ‘simplified’ licensing model, and if VMware changes direction by the time it hits the streets in late Q3 2011. I think this will make customers look at alternatives such as XenServer and Hyper-V more closely. There’s a very active thread on VMware forums about the licensing changes, and its mostly shock and awe.