Dec 082010

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 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.

Dec 022010

Note: Please read to the bottom for my initial take on it.  As promised at VMworld Europe, here’s vCloud Request Manager and can be downloaded here.  As always, here’s the overview from the release notes:

VMware vCloud Request Manager provides enhanced governance and control of private cloud infrastructures based on VMware vCloud Director. vCloud Request Manager:

  • Adds sophisticated approval workflows to provisioning requests
  • Automatically tracks software license usage
  • Enforces standardized settings on cloud partitions

My initial take on it: VMware, please stop releasing products with “manager” in the name, that’s soooo 2001.  The vSphere name was akward at first but it definitely beats the hell out of “virtualization manager”.  vCloud Request Manager (VRM?) is integration of some of the functionality of lifecycle manager into vCloud Director.  I’m not convinced yet that this should be a separate product – seems like it should just be a part of Director.  You may have read that some think Lab Manager’s days are numbered being replaced by vCloud Director, this release would seem to signal the same for Lifecycle Manager – only time will tell.  I’ll be kicking the tires thoroughly on vCloud Director and Request Manager and report the findings in an upcoming writeup.

Final thought: it’s 1.0 but I’ll give it the benefit of the doubt.

Dec 022010

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.