The VMguy

The way I see it, there are two dilemmas that VMware has in the way their licensing is designed today.  One of them works against VMware and one works against VMware customers (or at least makes it harder for them).  The former is definitely the bigger of the two so lets discuss that one first.  This topic comes up frequently when new versions of ESX are coming out.  We’ve already heard that an update is coming this year so I figured that since today is the half-way point in the year, this was a good time to bring up the topic again.

You probably noticed by now that there is a limitation in Standard and Enterprise editions of vSphere to a maximum of 6-cores per CPU.  The Advanced and Enterprise-Plus editions of vSphere have a licensed limit of 12-cores per CPU.  Now that Intel’s 8-core CPUs and AMD’s 12-cores are out, what’s next?  Intel and AMD are sure to develop a proc with more than 12 cores (and probably sooner than we all think).  What will happen to VMware’s licensing then?  You have to remember that from a revenue standpoint, when a 24 core proc comes out, customers will be able to run twice as many workloads on that proc (or at least 50% more).  Moore’s Law states that processing performance of CPUs will double every two years.  With the processors doubling in power so quickly, customers are typically not doubling their number of VMs in the same time period.  The result is that customers tend to have a diminishing need to increase their ESX per-CPU licensing.  I know that there are exceptions to this rule, but in the SMB space the majority are not growing that fast (at least not in this economy).  The increase in processor performance actually works against VMware’s current licensing model. It not good to have a direct connection between your main revenue stream and someone else’s CPU release schedule.  What will happen?  What’s the right answer?  Your guess is as good as mine.  Will they go to a per-vm model?  Increase their current limits?  Find some middle-ground between the two?  Will they “grandfather” their customers like AT&T did with the iPad data plans?  Only VMware knows.  My opinion is that this is an issue that has to be dealt with eventually.  Maybe this will be the year, maybe next.

The second licensing dilemma that I run into is in Site Recovery Manager.  It’s no secret that SRM is my favorite non-ESX product from VMware.  As you probably know, SRM is licensed by the physical CPU where the protected virtual machines reside or could reside.  Here’s where that model breaks down:  let’s say I have a smaller customer who’s policy is only to have a DR plan for 5 of their most critical Virtual Machines.  Those five VMs run in a cluster comprise of 5 dual CPU hosts with HA and DRS enabled.  According to the SRM licensing model, I need 10 CPUs of SRM for those 5 VMs.  That does not fly well.  The solution I’ve heard some engineers mention is to create a separate smaller cluster for just the protected VMs.  I’m not fond of that idea because it goes against the consolidation principal.  I’ve never felt that lowering your consolidation ratio was justified because it did not fit a licensing model.

I know there are people much smarter than me at work trying to find a solution to both of these scenarios.  I’m hopeful that they will get resolved in a way that’s fair to both sides.  Maybe this is the year, maybe it is not.  Either way, we’ve made it thru half of 2010, perhaps the answers lie in the last 6 months of the year.