Update: VMware have since changed their licencing slightly in response to customer outrage (in fact, this post was intented to help that along). vRAM allowances have been increased, but the fact still remains – Virtualizing Exchange on VMware can cost thanks to these changes.

It’s not often I commentate on news, let along licensing changes – but upcoming changes to the licensing model for VMware will have significant implications for organisations looking to virtualise Exchange on the vSphere platform.

Yesterday, with the announcement of the latest incarnation of their virtualisation platform, VMware have introduced a new licensing model that makes major changes to the costs involved with virtualising memory intensive servers.

VMware’s upcoming changes still split features into different editions, and still license customers on a per-CPU basis, but in addition to this, vSphere is now licenced on the memory allocated to virtual machines, known as vRAM.

What is vRAM?

With vRAM each CPU licence comes with an allocation of memory that is assigned to a number of pools and shared amongst the virtual infrastructure. For each edition of ESX, you get the following vRAM amounts included:

• Standard Edition – 24GB per CPU licence
• Enterprise Edition – 32GB per CPU licence
• Enterprise Plus Edition – 48GB per CPU licence

If you need more vRAM, you need to buy more CPU licences for the same edition used on your hosts, and pools of vRAM cannot be shared among editions. So if you’ve got excess Standard Edition vRAM, you can’t offer it to your Enterprise Plus hosts and vice-versa. And just to be clear – this isn’t utilised RAM, it’s allocated RAM. You’re charged for it whether or not particular virtual machines need to use it it’s full allocation right now.

How does this affect virtual Exchange 2010?

Although many VMware employees and bloggers are talking about about how they don’t think people are right-sizing VMs (making sure VMs don’t have more memory than they really need), their thinking ultimately seems to be really be about how you should be sizing for the vSphere licencing, not the application. Exchange performance, especially for the mailbox role benefits from large memory allocations and these are easy to calculate using the Exchange team’s tools and guidance on TechNet. For many installations this may result in a number of Client Access Servers with 8GB RAM, Hub Transport with 4GB, Mailbox servers with upward of 32GB RAM and 16GB RAM for Unified Messaging servers.

These high RAM allocations mattered little, because memory is relatively cheap, especially in a high-density virtual environment. No longer so – as RAM will be need to be purchased a second time in a VMware environment, there is a direct cost associated with each virtual Exchange instance you deploy in addition to your hardware, and possibly in addition to existing VMware licensing:

If you’re wondering where these RAM sizes come from – they are Exchange best practises and the sizing quotes come directly from VMware’s own sample guidance – VMware Exchange 2010 on VMware – Best Practices Guide with the exception of the Unified Messaging role RAM size which comes from Microsoft Best Practices for Virtualizing Exchange Server 2010 with Windows Server 2008 R2 Hyper-V. The pricing comes from VMware’s vSphere 5.0 Licensing, Pricing and Packaging document.

For each of the above VMs, don’t forget you’ll need to multiply these by the number of Exchange VMs you need; so VMware’s example of a clustered environment (in the above whitepaper, page 61) with a couple of UM VMs on Enterprise Edition (320GB RAM allocated in total), this would come in at $28,750 in VMware licensing alone – a minimum increase of $5,750 against 8 CPUs worth of Enterprise Licensing and the full amount if you need to go out and buy the whole 10 CPUs worth of licencing to cover your existing environment

Of course there is an argument that if you’ve already licensed vSphere, you’ll probably be OK – you might have tons of vRAM spare! Maybe, but maybe not according to VMware. As VMware’s own John Troyer says in this VMware forum thread, “we expect almost everybody to come out a little ahead (i.e., some excess vRAM capacity) just from their regular SnS upgrade from vSphere 4”.

So even VMware expect that as you embark on your next project, such as virtualising Exchange, your existing VMware licensing probably won’t cover the kind of requirements outlined above you’ll need to buy a fair bit of additional VMware licensing, even if you current physical infrastructure has enough capacity.

What’s the alternative?

As a VMware advocate who’s been virtualising mission-critical applications on ESX since version 2.1, in 2004, it pains me to say this – but in my opinion, Hyper-V is suddenly looking even more attractive. If you’re got vSphere, you have probably already invested a lot of money in your environment and the maintenance costs were the biggest expense – not enough to dump the investment in money, time and sheer energy to go to another product.

But, things change – if you’ve been in IT longer than 10 years then you’ll remember what happened to Novell in similar circumstances. You already have to licence Windows on your virtual infrastructure, so you have already paid for Hyper-V, and the time and costs to deploy SCVMM may be significantly less than the costs associated with VMware’s new licensing model. If you’re looking for a good pilot project for Hyper-V to prove it is good enough for your needs, Exchange 2010 may well be that project.