Yellow Bricks

by Duncan Epping

ESX

Performance stats gone

· ·

Clint discovered the following:

Source –
Ran into a problem while doing some performance testing on some test VMs. We found that we had no historical performance data for the VM or Host. All we had was real time data. This can be a major issue, especially when you are trying to troubleshoot or like in this case get performance data for a performance test! My co-worker did some research and found that we are not an isolated event. This is a bug in VC 2.5.

The Fix

We found a few references to doing a “repair” install of VC 2.5. So we went ahead and tried it and it worked. We also found references to the performance data getting corrupted. In that case they had to restore the database to a prior dataset and re-install the VC.

I’ve seen the same at several customer sites and indeed the fix that Clint describes, repair of VirtualCenter, works.

Weird scripted install problems

· ·

Today I was testing a scripted installation for a customer. All day long I had weird problems with the script. But whenever I reviewed my script their seemed to be nothing wrong with it. I wrote the scripts with Notepad++ and double checked them with vi and nano. You can imagine I almost threw my laptop out the window of sheer frustration. Notepad++ has a function called “convert to unix format” and although I could not find any weird characters, returns of whatsoever… it did solve my problem. After having a closer look at Notepad++ it seems like there’s a setting to avoid this behaviour:

I should have known it isn’t a good idea to edit linux script files on a Windows host, if only VMware would release a linux version of the VirtualCenter client…

Support for Microsoft Cluster Server (MSCS) in 3.5 update !

· ·

I received an email stating the following:

Microsoft Cluster Server is supported with VMware ESX 3.5 Update 1. Support is similar to ESX 3.0.1 with the following additions:

  • Both 64 bit and 32 bit Windows 2003 guests are supported with MSCS.
  • Boot from SAN for VMs using MSCS is now supported.
  • Majority Node Set clusters with application-level replication (for example, Microsoft Exchange 2007 Cluster Continuous Replication (CCR)) is now supported.

For details regarding MSCS support, including a number of important restrictions, please see the document “Setup for Microsoft Cluster Service.” For information concerning supported storage arrays, refer to the Storage/SAN Compatibility Guide for ESX Server 3.5 and ESX Server 3i.

load balancing active/active SAN’s

· ·

Ernst, a regular poster of the Dutch VMug, posted a script for load balancing paths to an active/active SAN. What it does is select the next path for a LUN, in other words if there are four paths LUN1 will be reached via Path1, LUN2 via Path2 etc.

The script, also available for download here:

#!/bin/bash
for PATHS in 2 4 6 8
do
STPATHS=${PATHS}
COUNTER=”1″

for LUN in $(esxcfg-mpath -l | grep “has ${STPATHS} paths” | awk ‘{print $2}’)
do
esxcfg-mpath –lun=${LUN} –path=$(esxcfg-mpath -q –lun=${LUN} | grep FC | awk ‘{print $4}’ | awk ‘{print NR “S\t ” $0}’ | grep ${COUNTER}S | awk ‘{print $2}’) –preferred
COUNT=`expr ${COUNTER} + 1`
COUNTER=${COUNT}
if [[ ${COUNTER} -gt ${STPATHS} ]]
then
COUNTER=”1″
fi
done
done

This will result in the following outcome with “esxcfg-mpath -l”:

Disk vmhba2:1:4 /dev/sdh (512000MB) has 4 paths and policy of Fixed
FC 16:0.1 50060b0000646c8a<->50060e8004f2e812 vmhba2:1:4 On active preferred
FC 16:0.1 50060b0000646c8a<->50060e8004f2e873 vmhba2:2:4 On
FC 19:0.1 50060b0000646062<->50060e8004f2e802 vmhba4:1:4 On
FC 19:0.1 50060b0000646062<->50060e8004f2e863 vmhba4:2:4 On

Disk vmhba2:1:5 /dev/sdi (512000MB) has 4 paths and policy of Fixed
FC 16:0.1 50060b0000646c8a<->50060e8004f2e812 vmhba2:1:5 On
FC 16:0.1 50060b0000646c8a<->50060e8004f2e873 vmhba2:2:5 On active preferred
FC 19:0.1 50060b0000646062<->50060e8004f2e802 vmhba4:1:5 On
FC 19:0.1 50060b0000646062<->50060e8004f2e863 vmhba4:2:5 On

Disk vmhba2:1:6 /dev/sdj (307200MB) has 4 paths and policy of Fixed
FC 16:0.1 50060b0000646c8a<->50060e8004f2e812 vmhba2:1:6 On
FC 16:0.1 50060b0000646c8a<->50060e8004f2e873 vmhba2:2:6 On
FC 19:0.1 50060b0000646062<->50060e8004f2e802 vmhba4:1:6 On active preferred
FC 19:0.1 50060b0000646062<->50060e8004f2e863 vmhba4:2:6 On

Disk vmhba2:1:7 /dev/sdk (307200MB) has 4 paths and policy of Fixed
FC 16:0.1 50060b0000646c8a<->50060e8004f2e812 vmhba2:1:7 On
FC 16:0.1 50060b0000646c8a<->50060e8004f2e873 vmhba2:2:7 On
FC 19:0.1 50060b0000646062<->50060e8004f2e802 vmhba4:1:7 On
FC 19:0.1 50060b0000646062<->50060e8004f2e863 vmhba4:2:7 On active preferred

Disk vmhba2:1:8 /dev/sdl (512000MB) has 4 paths and policy of Fixed
FC 16:0.1 50060b0000646c8a<->50060e8004f2e812 vmhba2:1:8 On active preferred
FC 16:0.1 50060b0000646c8a<->50060e8004f2e873 vmhba2:2:8 On
FC 19:0.1 50060b0000646062<->50060e8004f2e802 vmhba4:1:8 On
FC 19:0.1 50060b0000646062<->50060e8004f2e863 vmhba4:2:8 On

Disk vmhba2:1:9 /dev/sdm (512000MB) has 4 paths and policy of Fixed
FC 16:0.1 50060b0000646c8a<->50060e8004f2e812 vmhba2:1:9 On
FC 16:0.1 50060b0000646c8a<->50060e8004f2e873 vmhba2:2:9 On active preferred
FC 19:0.1 50060b0000646062<->50060e8004f2e802 vmhba4:1:9 On
FC 19:0.1 50060b0000646062<->50060e8004f2e863 vmhba4:2:9 On

In other words, when you run this script each LUN will be addressed via a specific path and all HBA’s and SAN Disk Controllers will be used instead of the default first path / first controller policy. This will result in a better performance and distribution of load on the SAN Disk Controllers.