The VMguy

You may remember from a recent article that I wrote about the VMware licensing dilemmas, that one of the scenarios I mentioned was SRM licensing when a customer wants to protect only a small percentage of VMs.  In the per-CPU licensing model, a customer would have to license all of the CPUs in a cluster even if they wanted to protect only 10% of the VMs.  VMware has announced that Per-VM licensing will be available on September 1, 2010.  Customers will now be able to license SRM on a Per-VM basis.  Customers who like their per-CPU model will be able to continue that purchasing method until December 15, 2010.  After that, it’s per-VM only.

There are a few things to think about with regard to licensing  first, vSphere 4.1 now allows for DRS affinity so that VMs only move between certain hosts of a cluster.  I’m still waiting for a definite answer from my VMware friends but that should allow you to protect some VM’s and set their DRS Affinity to only the hosts that you own SRM CPUs for and still keep the full cluster for the unprotected VMs. Previously, VMware would recommend that you create a separate cluster for your “protected” VMs if they were a small subset of the whole.  Now with DRS Affinity, you can dictate that certain “protected” VMs only move between a subset of a cluster.  We’ll still have to wait and see the final ruling from VMware but I’m thinking that would work in the short-term for those in the per-CPU dilemma.

The second feature of the new licensing that I really like is the rolling average of VMs over the last twelve months.  What that translates to is that now I need to buy what my daily average of VMs protected would be over a 12 month period.  If I have certain points of the year where my VM count spikes, this average would be monitored by vCenter and alarm if I am going over my licensing limits.  However, I would only need the average number of protected VMs over the past year.  The system will continue to run after going over your limit but that’s definitely not something I would condone (Famous VMware SE saying: ethics don’t ship in the box people).

The per-vm licenses are sold in blocks of 25 and range from $1,250 to $11,250 depending on the product.  Per-vm licensing will be available for Chargeback, Appspeed, SRM, and, later this year, CapacityIQ.  You can find more information on VMware’s website here.

The last question I had was, “How do I know what my rolling average is for those licenses?”  The good news is that once you enter in a license key, the new license reporting manager in vSphere 4.1 will tell you what your rolling average is year-to-date.  Looks like someone was planning ahead.

I’ve always been a fan of this little backup app.  It has just been upgraded to v1.2 and can be downloaded here.  Good information in the enhancements section of the release notes:

The following enhancements have been made for this release of Data Recovery.

File Level Restore (FLR) is now available for use with Linux.
Each vCenter Server instance supports up to ten Data Recovery backup appliances.
The vSphere Client plug-in supports fast switching among Data Recovery backup appliances.
Miscellaneous vSphere Client Plug-In user interface enhancements including:
The means to name backup jobs during their creation.
Additional information about the current status of destination disks including the disk’s health and the degree of space savings provided by the deduplication store’s optimizations.
Information about the datastore from which virtual disks are backed up.

You can also see a nice little writeup from the developers and a little video showing the new stuff here.

vCenter 4.0 was updated to Update 2 tonight.  You can download the new release here.  For reference, here’s the what’s new section from the release notes:

This release of VMware vCenter Server 4.0 Update 2 offers the following improvements:

Guest Operating System Customization Improvements: vCenter Server now supports customization of the following guest operating systems:
Windows XP Professional SP2 (x64) serviced by Windows Server 2003 SP2
SLES 11 (x32 and x64)
SLES 10 SP3 (x32 and x64)
RHEL 5.5 Server Platform (x32 and x64)
RHEL 5.4 Server Platform (x32 and x64)
RHEL 4.8 Server Platform (x32 and 64)
Debian 5.0 (x32 and x64)
Debian 5.0 R1 (x32 and x64)
Debian 5.0 R2 (x32 and x64)

Not the big release we’re all waiting for but an important one nonetheless. You can download the updated release here.  As always, here’s the very important what’s new section from the release notes:

The following information provides highlights of some of the enhancements available in this release of VMware ESX:

Enablement of Fault Tolerance Functionality for Intel Xeon 56xx Series processors— vSphere 4.0 Update 1 supports the Intel Xeon 56xx Series processors without Fault Tolerance. vSphere 4.0 Update 2 enables Fault Tolerance functionality for the Intel Xeon 56xx Series processors.
Enablement of Fault Tolerance Functionality for Intel i3/i5 Clarkdale Series and Intel Xeon 34xx Clarkdale Series processors— vSphere 4.0 Update 1 supports the Intel i3/i5 Clarkdale Series and Intel Xeon 34xx Clarkdale Series processors without Fault Tolerance. vSphere 4.0 Update 2 enables Fault Tolerance functionality for the Intel i3/i5 Clarkdale Series and Intel Xeon 34xx Clarkdale Series processors.
Enablement of IOMMU Functionality for AMD Opteron 61xx and 41xx Series processors— vSphere 4.0 Update 1 supports the AMD Opteron 61xx and 41xx Series processors without input/output memory management unit (IOMMU). vSphere 4.0 Update 2 enables IOMMU functionality for the AMD Opteron 61xx and 41xx Series processors.
Enhancement of the esxtop/resxtop utility— vSphere 4.0 Update 2 includes an enhancement of the performance monitoring utilities, esxtop and resxtop. The esxtop/resxtop utilities now provide visibility into the performance of NFS datastores in that they display the following statistics for NFS datastores: Reads/s, writes/s, MBreads/s, MBwrtn/s, cmds/s, GAVG/s(guest latency).
Additional Guest Operating System Support— ESX/ESXi 4.0 Update 2 adds support for Ubuntu 10.04. For a complete list of supported guest operating systems with this release, see the VMware Compatibility Guide.

A minor release from last week but I had to mention it as it’s my second favorite non-ESX product from VMware (after SRM).  Basically they made some enhancements to how HA capacity is computed for Capacity IQ calculations.  You can download the new version here.  In addition, here’s the what’s new section from the release notes:

CapacityIQ 1.0.3 is a maintenance release that supports additional VMware High Availability (HA) settings.

CapacityIQ factors reserved capacity to meet VMware HA failover commitments. CapacityIQ uses the VMware HA settings to calculate CPU and memory capacity for clusters and datacenters. The VMware HA settings do not affect host and virtual machine capacity calculations.

CapacityIQ 1.0.2 uses the enabled status of VMware HA and number of host failures in the Admission Control Policy settings of the vSphere Client as factors for modeling and forecasting capacity. CapacityIQ 1.0.3 adds the percentage of cluster resources reserved as failover spare capacity and the dedicated failover host number as factors for capacity.

The following VMware HA settings are the factors that affect CapacityIQ calculations:

Enabled or disabled status of high availability.
CapacityIQ detects VMware HA settings to calculate CPU and memory capacity for clusters and datacenters. If you do not use a VMware HA cluster, CapacityIQ sums up the capacity of all hosts in the cluster.
Number of host failures that the cluster tolerates.
CapacityIQ detects the number of host failures that the cluster tolerates and excludes the hosts with the most CPU and memory capacity. For example, if a cluster has 10 hosts and you set the number of host failures to three, CapacityIQ detects which three out of the ten hosts have the most CPU and memory capacity and excludes those hosts in the calculation. The CapacityIQ calculations of VMware HA CPU capacity and VMware HA memory capacity occur separately and the hosts that CapacityIQ excludes might be different for the CPU and memory calculations.
Percentage of cluster resources reserved as failover spare capacity.
CapacityIQ sums up the capacity of all hosts and multiplies that value by
(1-<percentage_reserved_as_failover_spare_capacity>). For example, if a cluster with 20 hosts has a total of 100GHz, and 20 percent of hosts are set aside for failures, the calculation for the VMware HA CPU capacity of the cluster is 100 × (1-.2).
Dedicated failover host.
CapacityIQ excludes the capacity of a dedicated failover host and sums up the capacity of the rest of the hosts. For example, if a cluster has three hosts with 9GHz, 8GHz, and 6GHz, and the 9GHz host serves as a dedicated failover host, the calculation for the VMware HA CPU capacity of the cluster is 8GHz + 6 GHz.
This maintenance release does not include any additional enhancements beyond the support of VMware HA settings.