config_mpath: A tool that automatically figures out the paths and spreads the LUNs across preferred paths.
It doesn't prevent ESX from failing over to a non-pref path. It seems ESX grabs the first available path in canonical(?) order, which about half the time will be non-preferred. It looks something like this:
[root@jw-esx1 root]# esxcfg-mpath -l Disk vmhba1:0:0 /dev/sdc (81926MB) has 4 paths and policy of Fixed FC 28:0.0 210000e08b865d42<->500a09818697b5b1 vmhba1:0:0 On active preferred FC 28:0.0 210000e08b865d42<->500a09829697b5b1 vmhba1:1:0 On FC 28:0.1 210100e08ba65d42<->500a09828697b5b1 vmhba2:0:0 On FC 28:0.1 210100e08ba65d42<->500a09819697b5b1 vmhba2:1:0 On
Disk vmhba1:0:1 /dev/sdd (81926MB) has 4 paths and policy of Fixed FC 28:0.0 210000e08b865d42<->500a09818697b5b1 vmhba1:0:1 On FC 28:0.0 210000e08b865d42<->500a09829697b5b1 vmhba1:1:1 On FC 28:0.1 210100e08ba65d42<->500a09828697b5b1 vmhba2:0:1 On active preferred FC 28:0.1 210100e08ba65d42<->500a09819697b5b1 vmhba2:1:1 On ^ ^ If you look real close at the digit above the first ^ (assuming email doesn't mess up my alignment), you see it's either 8 or 9, which indicates which controller the port/WWPN is on. The second ^ points at the target portion of the vmhba designation, which matches. The NetApp ESX HU tool looks at the WWPN (that digit in particular), queries the controllers for their LUNs and WWPNs and figures out for each LUN which paths are direct and which are proxy, and simply alternates LUNs for each controller across the two paths. So some LUNs on homer(*) go via vmhba1:0:x and some via vmhba2:0:x. For bart's LUNs, they go through vmhba1:1:x or vmhba2:1:x.
The way ESX multipathing fails over, it grabs the first available path in the order listed. So if we start with vmhba1:0:0 and that fails, it will go to vmhba1:1:0, which is a proxy path, and not what you want. For those LUNs "balanced" on vmhba2:0:x (sdd in the example above), if that link fails, and the rest of the links are up, those LUNs get moved to vmhba1:0:x (first in the list), which is a non-proxy path which is what you want.
It all goes back the way it's supposed to when you plug the cable back in.
I hope this makes sense...
Enjoy!
Peter
*By the way, here's the target port info for bart and homer: homer> fcp show adapters Slot: 0c FC Portname: 50:0a:09:81:86:97:b5:b1 (500a09818697b5b1) Slot: 0d FC Portname: 50:0a:09:82:86:97:b5:b1 (500a09828697b5b1)
bart> fcp show adapters Slot: 0c FC Portname: 50:0a:09:81:96:97:b5:b1 (500a09819697b5b1) Slot: 0d FC Portname: 50:0a:09:82:96:97:b5:b1 (500a09829697b5b1) ^ ^ port | | node/controller
(Slightly snipped)
Peter
-----Original Message----- From: Jack Lyons [mailto:jack1729@gmail.com] Sent: Tuesday, April 17, 2007 5:43 PM To: Learmonth, Peter Cc: Mike Ball; toasters@mathworks.com Subject: Re: Information on how Netapp single_image mode works
I haven't played with DSM3.0 so I can't answer that part, but the NetApp ESX Host Utilities analyzes the target WWPNs and figures out preferred paths to avoid using proxy paths.
I haven't used the Netapp ESX Host utilities, but we are using a script that looks at the paths available for each lun and alternates it between the paths on the primary head. (nothing like testing the script to discover a logic error will generate a lot of ASUP's)
What is included in the NetApp ESX host utilities that you find useful?