Hello, We have seen issues like this before. Please open a case with NGS and upload the vsc.xml and vsc.log file.
If you want to investigate yourself, look for isMpioSet in the log file. At the end of the line, it should report true or false. It appears that one of the LUNs is not being set correctly. I need the logs to see why.
Another way to see what is misconfigured is to right click the host and select 'host details...' It's tedious, but for each path, review the settings for each LUN. If the SATP=ALUA, then the PSP should be set to RR. If the SATP=DEFAULT_AA, then the PSP should be set to fixed and a suitable non-proxy path should be set for the preferred path.
I am able to manually set a preferred path on our ESXi 4.1 host through our newly installed VMware vCenter instance . What I am not able to do, however, is to use the virtual storage console 2.0 plug-in for VMware vCenter to set the preferred paths. It looks like the vsc was installed and configured correctly, because I am able to add storage controllers and I can see through the manage plugins window that it is installed.
The problem behavior can be seen here:
As you can see, there is an alert in the MPIO settings, and whenever I try to “set recommended values,” it errors out on the MPIO settings portion. Also, when I go to the show details command here, it shows many details in green which seem to be correct settings, the only setting in red is the following:
Any ideas on what could be the issue? I have already opened a ticket with Netapp support but they haven't gotten back to me yet.
The 'mpiosetting' field in the Host Details is value of the icon you see, so I expect that to be false (since you are seeing an alert). In order to tell which LUNs does not have the correct MPIO settings, you will need to expand and look at each LUN, and all the associate paths. If you have access to the logs, grep for 'isMpioSet'. That will narrow down which LUN does not have the correct MPIO Path setting.
Yes, I have rebooted all the hosts and double checked the zoning is correct. Thanks for the suggestions on checking out the LUN settings, I'm going to go through the logs this afternoon and see if I can find something there.
Well it turns out that the igroup settings we had (VMware fixed path settings) for some reason do not retain path information on the host. We tested out enabling ALUA on a different igroup on one of our hosts that is independant from our production vsphere environment, and after doing that, we didn't see the problem anymore. We are currently in the midst of migrating our entire vSphere 3.5 environment to vSphere 4.1, after which we will enable ALUA for the entire production igroup and should not see this behavior anymore, but I can update you when that is done to confirm this is a fix. It wasn't explained to me by support why ALUA is necessary and/or why VMware fixed pathing isn't persistent, but at least it's working.