The VMguy

I’ve taken about 5 emails from different customers this week on this topic so I felt it warranted a quick article.  There are two main changes coming one week from today: first, the sale on the upgrade to Enterprise Plus is about to end.  Second, some products are permanently switching to per-VM licensing (and maybe for some, not for the better).  Both of these are changing on December 15th.  Make sure to read to the end for my analysis of the perVM licensing.

License Sale

Upgrade to vSphere Enterprise for $495 per CPU (normally $685/CPU) – Support and Subscription is required with purchase.  Pretty self-explanatory on the differences.  I’m a huge fan of Host Profiles, distributed switches and storage IO control.

50 Seats of View Premier with vSphere Enterprise Plus Upgrades – Customers who purchase Enterprise Plus (Ent+) will get 50 concurrent Desktops of View Premier Edition and 1 year of Production Support and Subscription.  This promo also includes all of the bundles that upgrade vSphere to Ent+ (including the $495 upgrade above).

15 VMs of CapacityIQ with upgrades to Standard, Advanced, Enterprise and Ent+ – Customers who purchase or upgrade upgrade to any of these editions or bundles containing any of these editions get 15 VMs of CapIQ.  Essentials and Essentials Plus bundles are not eligible.

The official disclaimer from VMware: “VMware reserves the right to amend the terms, conditions and requirements of these promotions.  List Pricing is for reference purposes only and is subject to change without notice and my vary within region. Please refer to your reselling partner or www.vmware.com for a quotation or actual product pricing.”

PerVM Licensing

CapIQ, AppSpeed, Chargeback, and Site Recovery Manager are switching to perVM licensing from perCPU.  Customers can stay on their perCPU licenses or they can convert.  Customers who convert will get 10 VMs of Appspeed for each CPU, 10VMs of CapIQ for each CPU, 20 VMs of Chargeback for each CPU and 5 VMs of Site Recovery Manager per CPU, respectively.  As I mentioned, customers can stay on their existing licenses and renew support for them if they want.  They will not be able to buy any new perCPU licenses after December 15th, 2010 for these 4 products listed above.  This is where I see a bit of a storm brewing.  Customers who run many VMs per host and want to protect most of them are in for a bit of a rude awakening.

My take on PerVM Licensing

Let’s say a customer runs SRM perCPU today.  They have 4 hosts running 100 VMs total and SRM protects them all.  Each host has 2 CPUs.  In the old licensing model, they needed 8 CPUs of SRM that retailed for $1,750 each.  8 x 1,750 = $14,000 (let’s exclude Support and Subscription for the moment to make the numbers easier but I recognize that SnS is required).  Under the new model, the PerVM licensing comes in packs of 25 VMs.  For our example we need 4 packs of 25 VMs that retail for $11,250 each or 4 x 11,250 = $45,000.  Yes, you just read that right.  The customers cost for SRM in our example just went from $14k to $45k.

The new licensing does benefit some customers however.  Those with large farms that want to protect a minority of their VMs.  Those customers can now just buy a pack of VMs and protect only the ones they need.  They can even split the licenses between sites and cross-replicate.  This is where this licensing model really helps.  It helps the customers who just want to do some SRM.

The last point I want to make is buried in the FAQ on PerVM Licensing.  If you are currently running perCPU SRM in a cluster, if you need to add a host after December 15th and you need SRM licenses for that new host, you will need to convert your licenses at a ratio of 5:1 for SRM and then purchase perVM for all your existing protected VMs that are not covered by your converted licenses.  I have a bad feeling this is going to be a wakeup call for some customers.  Another note: there’s no switching back.  Once you go perVM, you cannot go back to perCPU.

I try very hard to look out for my customers and keep them informed.  These licensing changes may benefit some customers wanting to start out with a small number of protected VMs with SRM.  However, most of my SRM customers are like the $45k example shown above.  I don’t see these licensing changes being a benefit to them.  Normally, I don’t discuss licensing in my blog articles.  Some customers have negative attitudes when it comes to licensing.  Some maybe got burned in the past, or just don’t like to talk about spending money.  My goal here is to make sure you can see how these changes can affect you before the impending deadline.  Sometimes I can see a storm brewing from off in the distance.  I just hope that the storm does not cause a disaster, the likes of which even SRM cannot recover from.

Note: Please read to the bottom for my take on the new releases.  As promised during VMworld Europe, just released is CapacityIQ 1.5.  As always you can find the download here.  Here’s the What’s New Section from the release notes:

CapacityIQ 1.5 includes the following new features and enhancements:

• Storage Analytics – Adds disk space and disk I/O trending and storage analysis. The dashboard and views provide visibility into consumption of storage resources and ways to identify capacity bottlenecks. The data is optimized for vSphere and accounts for thin provisioning, I/O control, and linked clones.
• Resource optimization – Adds storage-aware workload modeling and what if scenarios to forecast future capacity needs. CapacityIQ provides outlier detection and filtering capabilities for improved analytics.
• Scheduled Reports – Adds report scheduling with email capabilities for automated delivery of capacity utilization and optimization reports.
• Performance and scalability improvements – Improves the response time in the interface and raises the scalability limits to 6000 powered on virtual machines and 8000 registered virtual machines.
• Virtual machine-based licensing – Supports virtual machine and CPU-based licensing. If you obtain a virtual machine-based license for CapacityIQ, install and manage the license from vCenter Server instead of the Administration Portal. You can continue to manage CPU-based licenses in the Administration Portal.

My initial take on it: Storage trending is a good addition.  It’s nice that it takes into account thin disks, etc.  Scheduled Reports is a nice add for proactive reporting.  Licensing going to vCenter for managing the license keys should have been done in v1.0.  I don’t like managing per-cpu licenses one way and per-vm another.  Overall sounds like a worthwhile release.  I’ll be plugging this into the lab later this week to kick the tires first hand.  Any additional pros and cons will be posted in an update.

I had a very interesting discussion with a customer about optimizing their storage replication for use with Site Recovery Manager.  We discussed the best practice of separating the VMware ESX VM swap files as per The SRM Best Practices Guide.  He was aware of that design suggestion and had already taken the initial steps to implement it.  He then went on to ask me if it would be beneficial to seperate out the Windows Page File onto a non-replicated datastore.  I had never heard of that suggestion before.  It seemed logical to do so.  If we shouldn’t replicate the VM swap file, why replicate the Windows Paging file?  They both perform similar functions at different layers of the software stack.  I powered up my web browser and headed over to Google for some searching.

I found a few references here and there.  Most customers keep the paging file inside the standard VM disks to avoid making the environment too complex.  I was about to give up and suggest he not separate the paging file, until I came across this discussion in the VMware communities.   Read the rest of this entry »

Second on the release list is an update to the standalone Converter (the better one IMO).  You can download the updated release here.  Some nice new features listed in the what’s new section of the release notes:

The VMware vCenter Converter Standalone 4.3 includes the following new functionality:

• Support for VMware vSphere 4.1 as source and destination targets
• Support for importing powered-off Microsoft Hyper-V R1 and Hyper-V R2 virtual machines
• Public API and sample code for submitting and monitoring Converter jobs
• Support for importing Windows 7 and Windows 2008 R2 sources
• Ability to throttle the data transfer from source to destination based on network bandwidth or CPU
• IPv6 support

Discontinued Support

• Support of the following operating systems is discontinued:
  • Windows 2000
  • Windows NT
• Support for OVF format is discontinued
• Support for VCB image sources is discontinued
• Linux installation support is discontinued

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.