I have several igroups that seem to be connected via the Vtic interconnect.
10:00:00:00:c9:78:82:e1 (logged in on: vtic, 0a) 10:00:00:00:c9:78:82:e2 (logged in on: vtic, 0d) 10:00:00:00:c9:78:83:bf (logged in on: 0a, vtic) 10:00:00:00:c9:78:83:c0 (logged in on: vtic, 0d) 10:00:00:00:c9:7c:fc:77 (logged in on: vtic, 0d) 10:00:00:00:c9:7c:fe:2e (logged in on: vtic, 0a) 10:00:00:00:c9:7c:fe:2f (logged in on: vtic, 0d) 10:00:00:00:c9:7c:f9:de (logged in on: vtic, 0d)
From what I've read in the past, the order of devices listed after the "logged in on" information is random and doesn't have to do with the path the lun is using. And that it should use the interface on the filer the lun is hosted on as a default.
Can you reset the counters on the luns and watch to see if the partner OPS grow?
I haven't worked with the 2008 MPIO yet (The first 2008 server has just been setup with fibre so I'll have a crash course soon). But is there any sort of MPIO interface that you can look at any of the details? There is typically a way to specify the preferred path (you can do it in ESX and SnapDrive). And maybe Windows 2008 in its infinite wisdom has choosen the wrong path as the primary.
Windows 2008 MPIO is ALUA aware. ALUA is a way to advise of the cost of a particular paths, so local paths are chosen in preference to partner. I am assuming that you have system manager installed as your first choice admin console, to check ALUA is enabled:
1. Open Storage > LUNs > Initiator Groups
2. Right Click on the iGroup > Edit
3. You will see the "ALUA (Asymmetric logical unit Access) features enabled", check the box.
4. Then update the MPIO policy to Weighted Path
This should make Windows update the paths and prevent the non-optimal comms. But being windows it may require a reboot.
If the Exchange Server is a Virtual Machine then ESX handles all of the MPIO, meaning nothing needs to be done in the Windows OS. But in this case it appears that the Exchange box is physical or it would not be visible in iGroup show.
Do not set ALUA to one for ESX 3.5, as it can result in Kernal Panics on the ESX Server. ESX 3.5 never got full ALUA support as it was included in 4.0 and 4.1. For ESXi you need to install Virtual Storage Console (VSC) on the Virtual Centre instance, update the configuration for the ESX and reboot to enable ALUA. Once this is completed you can go to manage paths and see the ALUA callout is in use.