VMware Storage Alphabet Soup and Making the Most of VMwares Multipathing

Having recently moved into an enviroment where the storage is a little alien to me, I thought would be helpful to buff up on some storage knowledge and thought it might help some readers too.
Here is a diagram of a midrange san:

(Thanks Virtualgeek for this picture)


See the two items list as "Data Processor(head) A" and "Data Processor(head) B"?
Traditionally if you are using Active/Active Processor array you should use "Fixed" as the Multipathing method and In an Active/Passive array use "MRU".

However this changed with:
ALUA:Symmetric Logical Unit Access
Essentially in midrange san enviroments (EMC Clariion etc), this allows an unoptimized and an optimized path to a lun through different heads.

ESX(4) the HBA is aware of optimized and unoptimized paths as it knows which head has control of the LUN!
Suddenly we can use MRU with Active/Active heads.

MRU Most recently used:Use the Optimized Path unless it is not avalible then use the Unoptimized path (ESX 4.0/vSphere only)

Fixed: Always use this LUN unless it is unavalible.

NMP:Native MultiPath Driver:

MMP:Multipath Plugin (EMC Powerpath)

Round Robin: Within ESX server's iSCSI HBA it sends 4000 IO blocks down one path then moves to the next path.

Custom Policy:
Use the following commmand to tweak the iSCSI HBA
esxcfg-mpath --lun vmhba32:0:8 --policy custom --custom-hba-policy any --custom-max-blocks 1024 --custom-max-commands 50 --custom-target-policy any


References:
http://www.vmware.com/pdf/vi3_35/esx_3/r35/vi3_35_25_iscsi_san_cfg.pdf
http://www.vmware.com/pdf/vi3_35_25_roundrobin.pdf
http://virtualgeek.typepad.com/virtual_geek/2009/09/a-couple-important-alua-and-srm-notes.html
http://virtualgeek.typepad.com/virtual_geek/2008/08/celerra-virtual.html

Having problems connecting Outlook 2007 to Exchange 2003? SPN might be to blame

Afternoon,

I was having some problems today connection Outlook 2007 to an Exchange 2003 SP2 box today.

Here is the Error message that was being recieved:

The connection to Microsoft Exchange is unavailable. Outlook must be online or connected to complete this action.


After a couple of hours playing around I managed to narrow this down to Outlook 2007 now authenticating with kerberos and not being able to find the Service Prinical Name for the global catalog server.

Authentication via Outlook 2003 (NTLM) was perfect, as was HTTPS (OWA) this was just affecting Kerberos.

Here is how I fixed it:
1) Install Windows Server 2003 Support tools:SUPPTOOLS.MSI
2)Run setspn -L ExchangeServerName you will see something like this:

Registered ServicePrincipalNames for CN=,CN=Computers,DC=example,DC=com:
exchangeAB/
exchangeAB/.example.com
exchangeMDB/
exchangeMDB/.example.com
exchangeRFR/
exchangeRFR/.example.com
SMTPSVC/
SMTPSVC/.example.com
HOST/
HOST/.example.com


exchangeAB/
exchangeAB/.example.com

The above line is the one we are interested in. We need to change it:

setspn -D exchangeAB/ExchangeServerName ExchangeServerName
setspn -D exchangeAB/ExchangeServerName.example.com ExchangeServerName


Then re-add the details:

setspn -A exchangeAB/GlobalCatalogServerName GlobalCatalogServerName
setspn -A exchangeAB/GlobalCatalogServerName.example.com GlobalCatalogServerName


The output from setspn should now be:


Registered ServicePrincipalNames for CN=,CN=Computers,DC=example,DC=com:
exchangeMDB/
exchangeMDB/.example.com
exchangeRFR/
exchangeRFR/.example.com
SMTPSVC/
SMTPSVC/.example.com
HOST/
HOST/.example.com


Note the ExchangeAB SPNs are gone as they are now pointing to the domain controller (GC)


Reference List:
http://support.microsoft.com/kb/927612/en-us

Using VMware View with Network cards as Removeable Devices

This is only going to be a quick on hopefully :)

For those that do not know vmware presents most of their nics as removeable/USB devices PCNET(Vlance),Intel e1000 and vmxnet,vmxnet2,vmxnet3 this is to allow the feature of "hot add" which is a great way off adding hardware to a VM without powering the machine off.

Today whilst playing around it was highlighted to me that some "adventurous" VM View users that had USB enabled used that oppurtunity to disable the network card. Forcing the intervention of the admin from the cloud to re-add the vnic

Heres a couple of ways around it:

1) Use the configuration options to add "devices.hotplug" = "false" like this:


*Also does not affect cpu/mem hotplug

2) Edit the *.vmx file and add:

devices.hotplug = "false"


3) Hide the "safelty remove hardware option" like this:



4) Use the "NoDisplayClass" to customize the driver *yuck!


Hope that helps someone out there!



Source:http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=1012225&sliceId=1&docTypeID=DT_KB_1_1&dialogID=64244650&stateId=0%200%2067543541
*NB:Using VMXnet3 does not disable hot plug as indicated in the KB

Using HSRP,CARP and VRRP within VMware

Hi all,

Just a quick note incase it helps anyone else out there.

I was recently in a lab moving from a vSS (Virtual Standard Switch) over to a vDS (Virtual distributed switch) when I came across and issue with a Pfsense box.

I had two VMs using CARP (which is like HSRP or VRRP) to push about a highly avalible IP address.
Now most vm admins out there will work out that for VRRP or CARP to work you need to enable "Promiscuous Mode" within the vSS or within the port group.


The issue I came across was with Promiscuous Mode and one uplink port (vDS or vSS) CARP was working perfectly however on adding the second uplink port to the vDS, pings to the CARP address were dropping.

Therefore - lesson learned was: When load balaning across multiple nics (or uplink ports in vDS terminology) you need to also be using the load balancing method of "Route Based on IP hash" (with accompanying switch config) if you plan to use CARP or VRRP else it will not work!