VMware’s vSphere 5 new licensing model raised eyebrows and tempers across the industry just three weeks ago. Bowing to the negative response, VMware has announced three changes that should appease customers – but will still likely lead to higher virtualization costs for VMware customers.

Customer backlash with original vSphere 5 licensing model
When first announced, the new vSphere 5 licensing model was positioned as being a positive for customers. VMware didn’t however mention that each vSphere 5 CPU-based license came with a fixed amount of virtual RAM (vRAM) entitlements. If your configuration has more vRAM than is entitled for use with the CPU license of vSphere 5, you need additional licenses.

As I’d previously covered, VMware customers complained of 2x to 3x higher licensing costs for vSphere 5 versus vSphere 4.

VMware announced three changes that attempt to address concerns around vRAM as a licensing metric and the resulting increases in cost for a VMware customer. Users commenting on VMware’s forum seem to be less irate with the new changes but still question the vRAM model.

Increasing vRAM entitlements per license
First, the vRAM entitlement per vSphere edition has been increased from 24/24/24/32/48 to 32/32/32/64/96 gigabytes for vSphere Essentials, Essentials Plus, Standard, Enterprise and Enterprise Plus respectively.

Let’s evaluate the result of this modification on our previously discussed customer example. We have a customer with a two-socket processor with no more than 12 cores per socket, with 256GB of RAM.

Under the original vSphere 5 licensing model, the customer needed six CPU-based vSphere Enterprise Plus licenses — not two — to be entitled in order to use the full 256GB of RAM on the system.

Under the revised vSphere 5 licensing model, the customer would need three CPU-based vSphere Enterprise Plus licenses — not two.

The first two CPU-based licenses, sufficient for the two CPUs on the system, would have provided 96GB of vRAM entitlement each, for a total of 192GB.

However, since the scenario included 256GB of RAM, the customer would have had to buy a third vSphere CPU-based licenses in order to use the full 256GB of RAM.

Using the old vSphere 4 licensing model, the customer would only need to purchase 2 CPU-based vSphere Enterprise Plus licenses. As a result, a customer in this situation would still be paying 50 percent more than they did with vSphere 4, but at least its not 300 percent, as was the case with the original vSphere 5 licensing model.

Capping vRAM usage to encourage virtual machines with large amounts of vRAM
The second licensing change VMware announced is that the amount of vRAM counted against any one virtual machine is capped at 96GB. Using our example above, if your system has 256 GB of physical RAM and you want to allocate 128GB of vRAM to two virtual machines, VMware will only reduce your vRAM allocation from 256 to 192GB. As a result, you’d be 64GB under your 256 vRAM entitlement even while using a full 256 GB of vRAM across the two virtual machines.

VMware made reference to the fact that customers could use a 1TB vRAM virtual machine wile only reducing their vRAM allotment by 96GB from the total vRAM pool.

Customers would still need sufficient vSphere CPU-based licenses to use the 1TB, or whatever number, of physical RAM available on the system. As such, this change only applies to how much vRAM is used from within the vRAM pool. This is pertinent for additional vSphere CPU-based licenses that may be needed in following years if the customer surpasses the total pooled vRAM allotment in the previous year.

VMware aims for Tier 1 applications
With the third licensing change VMware now calculates a 12 month average of consumed vRAM rather than tracking the high water mark of vRAM used.

By limiting the vRAM counted per VM to 96GB and tracking a 12 month average of vRAM usage, it’s less likely that a customer will use more than their vRAM allotment per year.

The combination of the second an third licensing change make it much more attractive for customers to run multiple Tier 1 applications on VMware by reducing the licensing hurdles for doing so.

The risk however, especially after the current licensing fiasco, is how licensing may change in the future, after customers are heavily reliant on VMware for even their Tier 1 applications.

As we’ve discussed before, it’s good to evaluate options, especially as open source hypervisors become more mature.

As you move more business critical applications to VMware, consider moving some of your existing, less critical, VMware applications and environments to an open source hypervisor.  Using a mixture of VMware and an open source hypervisor, is likely your best long term option for balancing costs and flexibility.

I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”

VMware’s vSphere 5 brings new features and performance improvements, as InfoWorld’s Ted Samson reports. vSphere 5 also introduces a new licensing approach, one which many users are claiming will significantly increase prices. Will your organization be impacted by the new pricing? If so, consider using an open source hypervisor to for certain workloads.

New vRAM licensing model
With the introduction of vSphere 5, VMware is evolving its product licensing model to give customers a “pay for consumption” approach to IT.

The new licensing model is still based on CPU cores, but does away with a limitation of physical RAM per server license. Instead, VMware has introduced the notion of virtual memory, or vRAM in VMware’s terminology. vRAM is defined as the virtual memory configured to virtual machines.

vSphere 5 is licensed per processor with a varying amount of pooled vRAM entitlements based on the vSphere package purchased.

According to VMware’s whitepaper on the new licensing model for vSphere 5, vRAM helps customers better share capacity across their IT environment:

An important feature of the new licensing model is the concept of pooling the vRAM capacity entitlements for all processor licenses. The vRAM entitlements of vSphere CPU licenses are pooled–that is, aggregated–across all CPU licenses managed by a VMware vCenter instance (or multiple linked VMware vCenter instances) to form a total available vRAM capacity (pooled vRAM capacity). If workloads on one server are not using their full vRAM entitlement, the excess capacity can be used by other virtual machines within the VMware vCenter instance. At any given point in time, the vRAM capacity consumed by all powered-on virtual machines within a pool must be equal or lower than the pooled vRAM capacity.

Since vRAM entitlements can be shared amongst multiple host servers, VMware suggests that customers may require fewer vSphere licenses.

Prepare for higher VMware vSphere licenses due to available RAM memory
VMware doesn’t mention that the new vRAM-based licensing model could lead to significantly higher license requirements as the per-CPU licensing for vSphere 5 only has limits on vRAM per license.

If your configuration has more vRAM than is entitled for use with the CPU license of vSphere 5, then you would need additional licenses.

For example, the vSphere Enterprise Plus package, priced at $3,495 per CPU, allows up to 48GB of vRAM.

Let’s evaluate a scenario where you have a two socket processor, with no more than 12 cores per socket, with 256GB of RAM. The two processors would require two vSphere licenses, resulting is an entitlement of 96GB of vRAM entitlements (2 x 48GB of vRAM per licensed CPU). However, your server has 256 GB of RAM, all of which needs to be licensed. As a result, you must buy an additional 4 licenses of vSphere 5 Enterprise Plus. In total, you would need 6 licenses of Enterprise Plus which would entitle you to run 288 GB of vRAM, sufficient for your 256GB of physical RAM.

Many users shocked by new VMware vSphere prices
User response to the new licensing at VMware’s community forum has been decidedly negative.

One person commenting on the VMware forum writes: “We just purchased ten dual-socket servers with 192GB RAM each (enterprise license level) and we’ll need to triple our license count to be able to use all available RAM if allocated by VMs.”

Another person claims that their small and medium business will see a 300 percent increase in price as a result of the new model.

The general tone of responses on the VMware community forum has been one of shock at VMware. Fear of having to explain to one’s boss that the cost of VMware virtualization licensing is going to be two or three times higher than expected is, not surprisingly, a key concern.

Echoing the comments of many on the forum, Vince77 writes:

Also, when virtualizing servers the only bottleneck I run into is Memory, VMware also knows that so they now build their licensing (moneymaker) based on that.

And every new version of Windows “likes” more ram to make it run smooth.

Now it’s time to really take a good look at Xenrver or even….. .. HyperV!

An opportunity for open source hypervisors
The new pricing model further increases the price gap between VMware and Red Hat Virtualization or Citrix Xen virtualization solutions.

For instance, Red Hat offers a 1 year subscription for up to 6 managed sockets, regardless of cores per socket, for $4,495 per year. Red Hat’s virtualization offering also doesn’t have any restrictions on RAM entitled for use with a licensed socket.

Over a 5 year period, Red Hat’s solution would cost $26,970.

To compare with Red Hat, a customer would buy at least 6 processor licenses of VMware vSphere Enterprise Plus with product support and subscription over 5 years for $3,495 per processor license and 5 years of support and subscription at $874 per year per processor.

Over a 5 year period, VMware’s solution would cost at least $47,190, or at least 74 percent higher than Red Hat.

I stress, “at least”, to take into account the fact that VMware’s pricing could be significantly higher if additional processor licenses were required to entitle for the amount of RAM being used.

As the pricing gap gets closer to 100 percent higher using VMware versus a leading open source virtualization solution, and open source virtualization solutions become more mature, customers will have to reconsider open source options. I’m not suggesting a wholesale shift from VMware to an open source alternative – such migrations seldom happen, and often never as quickly as pundits would suggest.

I am suggesting that you evaluate the new vSphere pricing and usage of server virtualization to determine if a portion of your virtualization needs couldn’t be better served, at a lower cost, using an open source solution.

This balance between enterprise-grade commercial software product, and less mature, but compelling, open source software product has been playing out over much of the software market.

VMware’s vSphere 5 pricing could simply serve to accelerate the shift towards a mixture of commercial and open source in the virtualization arena.

I should state: “The postings on this site are my own and don’t necessarily represent IBM’s positions, strategies, or opinions.”

I was quite busy at work today so I’m only catching up on blog reading now. My arch nemesis has been busy :-) BTW, when do you do your day job? Can I get a job at Alfresco???? :-)

Kidding aside….Matt says:

“$500 million is a hefty premium given XenSource’s revenues, which were still pretty modest (less than $10 million in 2007 and almost $0 in 2006). Citrix, in other words, paid a massive premium (50-500X (!!!)) for the brand and position that XenSource presumably has with the Xen hypervisor.”

Couldn’t agree with him more. Citrix overpaid. It happens. But this is 100% because XenSource is a virtualization vendor. If, we were talking about the CRM marketplace, I’ll wager a dinner that the multiple would have been an order of magnitude less. With VMware worth over $21B, I’m sure I could sell my in-law’s dog for several thousands by renaming him Virtualization Beagle.

By the way, how many of you have heard or thought about Citrix in the past 5 years? Did anyone know they have revenues over one billion dollars? Exactly. This acquisition is as much a reason for Citrix to get back in the public/customer/investor eye as it is about a technology acquisition. Don’t be surprised if Citrix gets acquired by a larger vendor down the road. Using this deal to assigning a high multiple to OSS is, if you ask me, wishful thinking.

In another post Matt quotes a friend of his who said the following about what the Citrix deal means:

“It is about having new technology in the arsenal to go after older competitors that have not revamped their technology. The lack of investment in technology by both start-ups and the established players in the early part of the decade is now catching up with them by making them exposed to new, open source entrants that were able to survive in the shadows of the dinosaurs.”

This comment just didn’t fell right. Is it really true that open source entrants have new whiz bang technology that larger software vendors couldn’t replicate because the larger vendors hadn’t spend enough on R&D in 2000-2003?. Here’s what the financial numbers show:

Yes, R&D spending was lower in 2000 & 2001, but investments picked up quite quickly thereafter, so I doubt this has a material impact on competitive positions in 2007 vs. OSS.

Correct me if I’m wrong but wouldn’t it take a lot less than $500M to develop competing technology to Xen. Alternatively, it’s open source, so Citrix could have forked Xen and had the technology for next to free. However, building a competitive offering or forking Xen would not deliver the user base of Xen, the linkage with RHEL/SUSE or the Linux kernel in the future. Tell me that this deal had to do with acquiring a brand and a user base / widely distributed technology. Don’t tell me this is about innovation that can’t be matched by larger Traditional vendors.

To be fair, in a previous post Matt did suggest that the deal was driven by brand & ‘ownership position’ of Xen. I’m not sure why he leapt to the conclusion the deal had anything to do with technology innovation.