The VMguy

Today I ran into this issue with a customer and wanted to write on it so it does not happen to everyone.  Fault Tolerance on vSphere is an awesome solution to maximize uptime.  There is a CPU scenario that may be a challenge however:

This KB article (http://kb.vmware.com/kb/1008027) reads:

For VMware FT to be supported, the servers that host the virtual machines must each use a supported processor from the same category as documented below:

Intel Xeon based on 45nm Core 2 Microarchitecture Category:
3100 Series
3300 Series
5200 Series (DP)
5400 Series
7400 Series

Intel Xeon based on Core i7 Microarchitecture Category:
3500 Series
5500 Series

AMD 3rd Generation Opteron Category:
1300 and 1400 Series
2300 and 2400 Series (DP)
8300 and 8400 Series (MP)

Please note the requirement “same category.”  As an example, if you have a server with a 54xx series Intel Processor and a Intel 55xx series processor (both have the technology for FT), you can vMotion and DRS between them (via EVC) but you cannot run a Fault Tolerant pair across them.  The Lockstep technology from Intel changed in the 35xx and 55xx CPUs and is not compatible with the previous generations of lockstep.

Sheesh, hard to keep up with all the VMware updates today.  Chargeback 1.0.1 was released today and can be downloaded from here.

Some nice updates included in the release notes:

vCenter Chargeback 1.0.1 provides the following new features:

• Support for Windows Authentication
  This release of vCenter Chargeback supports Windows Authentication for SQL Server databases. If you are using SQL Server for the vCenter Chargeback database or for the vCenter Server database, then you can configure the application to use Windows Authentication instead of SQL Authentication.
• New computing resource and billing policies added
  This release of vCenter Chargeback introduces a new computing resource, vCPU, and two new billing policies,vCPU Count and Memory Size and Fixed Cost and vCPU Count and Memory Size. These policies enable you to calculate cost based on the number of virtual CPUs and the amount of memory allocated to the virtual machines.
• Resource Summary section lists rolled-up usage data for all entities
  The Resource Summary section of the chargeback reports show the rolled-up usage data for all the entities.
• Global fixed cost history is retained
  This release of vCenter Chargeback lets you to set different cost values for different time periods on the same global fixed cost. The old values are retained and not overwritten.
• Ability to undo to the most recent operation on the chargeback hierarchy
  The most recent operation on the chargeback hierarchy can be undone. This undo feature is available for entities that are added or moved in the hierarchy. The undo option is not available for rename and delete operations.
• Ability to use the vCenter Chargeback APIs
  vCenter Chargeback APIs provide an interface to programmatically use the various features of vCenter Chargeback. As an application developer, you can use these APIs to build chargeback applications or integrate vCenter Chargeback with your internal billing systems and compliance policies. Please do note that the APIs released with this version of vCenter Chargeback are only for a technical preview.

You all know the religious argument: whether you should run vCenter in a VM or not.  We’ve discussed in the past some of the pros and cons of doing so.  Today I was running thru the KB digest from the guys in the knowledge base department and came across an interesting scenario I had not thought of yet:

How do you enable EVC (Enhanced vMotion Compatibility) in a cluster that is running vCenter?  On vCenter4, as long as the CPU baseline does not change from what the CPUs are running at currently, you should be able to do this while vCenter is running.  But what if your on 3.5 (which requires all VMs to be down to enable EVC) or if you need to change the baseline from the current when you enable EVC (which also requires the VMs to be down)?

Yes it can be done (if you have enough hosts). All the details can be found in KB article 1013111.  It becomes a “shell game” of moving hosts and VMs.  You basically start a new cluster with no hosts.  Turn on EVC on the new cluster.  Put one of your hosts into maintenance mode and remove it from it’s current cluster.  You can then add that host to the new cluster.  Then you can shut down vCenter and remove it from the inventory (note the storage location) and re-add it into the new cluster and power it on.  You can then balance moving VMs to the new cluster.  This may be able to be done live, unless the baselines are off which will require the VMs to be cold-migrated.  As hosts are emptied of VMs, you can then migrate them to the new cluster.

I don’t believe this should be a major impact on whether to run vCenter in a VM, just one thing to remember if you do.

Many have waited for a long time for this one.  The forecasting tool for your existing virtual platform.  When will I need more CPU?  When will I need more RAM?  Capacity IQ will assist in predicting it for you.  Since this is a 1.0 release, there is no What’s New section in the release notes.  There is a nice summary in the Key Features Section:

Capacity Awareness

• View and analyze past, present, and future capacity states at-a-glance with dashboard graphs and tables.
• Eliminate costly routine monitoring and management tasks through automation using customized capacity thresholds and alerts.

Capacity Optimization

• Reclaim excess capacity from idle, oversized, or powered-off virtual machines.
• Size and allocate capacity for each virtual machine based on historical and future needs.
• Place virtual machines in the most optimal clusters to eliminate further waste.

Capacity Prediction

• Simulate one-time business events to quantify potential business impact.
• Identify the timing of potential capacity shortfalls based on trends and forecasts.
• Purchase and provision capacity as and when needed.

There is one important thing to note from the release notes: “CapacityIQ supports VirtualCenter 2.5, Update 4 and Update 5, managing hosts running ESX Server 3.0.2 through 3.5. CapacityIQ 1.0 does not support VMware vSphere 4.0 or vCenter 4.0.”

You can find the download in the download section here.

Many of my users out there run Microsoft Cluster Services on ESX.  A great questions was asked of me today: have the rules changed with running MSCS on vSphere?  The answer is: a little.

There are 3 scenarios of MSCS clusters and ESX: Cluster-in-a-box (both MSCS nodes are on the same physical host – great for testing), cross-host (where each of the MSCS node VMs resides on different ESX hosts), and physical-virtual (where one MSCS node is physical, one is virtual).  The requirements for MSCS can change, even in the minor updates, so check the documentation often.  Here’s my compiled list of requirements/tips for MSCS on ESX 4.0:

• You are still limited to two-node clusters with MSCS on ESX 4.
• From a storage perspective, you can use local storage (for cluster-in-a-box) or Fiber Channel (for cross-host or physical-virtual clusters).  There is still no support for NFS or iSCSI (I personally think this is because FC and local storage have more predictable performance – although iSCSI is improving on this).
• If you are doing cross-host, both hosts must be running the same version of ESX (this just makes sense really).
• The MSCS node VMs cannot move as part of HA or DRS.  (HA is being a little redundant for MSCS, DRS is because MSCS is so hyper-sensitive to network connectivity that even a ping loss could failover the MSCS cluster).
• You cannot use MSCS with Fault Tolerance  (i.e. FT VM’s can reside on the same physical ESX hosts, but MSCS node VMs cannot run as FT pairs)
• You cannot vMotion MSCS node VM’s.  (Same reason as DRS).
• You cannot use N-Port ID Virtualization (NPIV)
• If you are using FC and using the native multipathing in ESX, you cannot use round robin as a path policy.
• You must use VM hardware version 7 with ESX/ESXi 4.0 (if you migrated the VMs from ESX 3.5 or before, make sure to upgrade your VM hardware version)
• Failover clustering with Windows Server 2008 is not supported with virtual compatibility mode RDM’s, for Win2008 use physical compatibility mode RDMs.
• You cannot use thin-provisioned disks for the Windows OS vmdk’s, they have to be thick.
• For Win2000 and Win2003 use LSI Logic Parallel as the controller type for the shared storage.  For Win2008 use LSI Logic SAS.
• For physical-virtual MSCS clusters, use RDMs in physical compatibility mode (this just makes sense if you think about it)
• You cannot run storage multipathing software in the VMs or on ESX (i.e. no PowerPath VE).
• You cannot over-commit memory for the MSCS node VMs, set the Memory Reservation option for each of the nodes to the amount of memory assigned to the virtual machine.
• Set the disk I/O timeout to 60 sec. or more (HKLM\System\CurrentControlSet\Services\Disk\TimeOutValue) in the registry.

You can find all the details and steps walking you thru the setup of MSCS on ESX in this article .  If you’re not on vSphere yet but you want to run MSCS nodes as VMs, you can find the proper docs for your version of ESX in a freshly updated KB article located here .