Some heads up if you are using an Active/Active Array (XtremIO, VMAX, HDS and maybe more..)
Lately, I have worked with VMware about a strange support case, basically if you are using any A/A array and failing a path, the failover to the remaining paths will not always happen, this can effect not only path failover/failback but also NDU procedures etc’ where you are purposely failing paths during the storage controllers upgrades etc’
The VMware KB for this is:
and if you look under the notes section:
- Path Failover is triggered only if other paths to the LUN do not return this sense code. The device is marked as PDL after all paths to the LUN return this sense code.
A problem with this process has been identified in ESXi 6.0 where failover is not triggered when other paths to the LUN are available.
The root cause of this issue has been identified and the fix will be available in the next major release of ESXi 6.0.
If you are running ESXi 6.0 U1.x and you are affected by this issue, a hot patch is available. To obtain the patch, raise a Support Request and reference this KB article ID. For more information, see How to file a Support Request in My VMware (2006985).
2/0 0x5 0x25 0x0 – ILLEGAL REQUEST – LOGICAL UNIT NOT SUPPORTED
It’s important to understand that this is not an XtremIO issue, it’s an issue that started with vSphere 6.0 as in the 6.0 code that Is a change in the way that the ESXi sense a PDL scenario. If you are using vSphere 5.5 (and all of it’s updates) it’s all good for you.
As of today, if you are
Using vSphere 6 Update 1, you can ask VMware for a specific hotfix, you can reference the kb I mentioned above, this hotfix will not go public so you have to be specific when asking about it, why won’t it go public?
Because hotfixes are limited in their QA testing and we want to make sure that you, the customer is installing this hotfix only if you really need to, also in the upcoming version of vSphere 6, VMware will include this “fix” as part of the ESXi kernel and because of that a very rigid QA effort will be done around it.
So, if you are anxious to solve it now and using vSphere 6, just call VMware support, if you can wait a little bit more and prefer to have a fix that has gone through a more rigid QA, please wait for the upcoming vSphere 6 release.
lastly, if you are using EMC PowerPath/VE, you are not impact by this as PP/VE take ownership of the the NMP.