When using Microsoft Fail-Over Clustering with Cluster Shared Volumes or Clustered disks which are on a HP EVA storage box, you may run into a problem about the disk/volume only being accessible from one of the nodes of the failover cluster, usually the node on which the disk/volume was added. When trying to access the volume from another node (e.g. by moving the role using that volume to another node), the role will fail and complain that the disk/volume is not accessible. Moreover, in Disk Management, the disk is not accessible and does not show the size of the disk. This makes the use of a fail-over cluster rather useless as the role can only run on the one node that does have access to the disk/volume.
Installation of the HP EVA DSM does not resolve the issue, nor using the generic drivers included in Windows (when running 2012/R2).
The problem in fact is not on the Windows, but in a configuration setting of the host - not the volume - on the HP EVA, and more specifically, with the OS type that was configured for the host.
HP EVA has two entries for Windows: a more generic "Microsoft Windows" and a newer, more specific "Microsoft Windows 2008". While the two are roughly the same, they have a significant difference in how the LUNs are presented to the host. When selecting "Microsoft Windows 2008", the LUN is exported without exclusively locking it to a single host, allowing for a fail-over cluster to connect all their nodes to the volume, something that is not possible when the OS type is set to "Microsoft Windows", in which case the volume is exclusively assigned to the first one that actively connects to it, even if the volume is presented to more than one host.
You can change the OS type from "Microsoft Windows" to "Microsoft Windows 2008" on-the-fly. It does not create downtime nor does it perform any kind of reset. However, the change is immediately active: nodes that could not connect before, will immediately be able to connect to the volume, and the disk will appear as offline but with its size visible in Disk Management.
And when moving a role to another node, this now works properly.
I had this problem on a SQL Server cluster on Server 2012, where some of the volumes were stored on an old HP EVA P6000 SAN. Only those volumes had the issue. When adding them, they were only available on the first node that got the volumes presented to them. The other nodes failed to access the volumes unless I explicitly unpresented it from the node that could access the volume. Attempting to install DSM or fiddling with all sorts of parameters did not resolve the issue.
I started googling around and found another article which had a similar issue but with clustered shared volumes. The article mentioned they fixed it by changing the OS type from the host on the EVA. As it turned out, the fix was exactly the same for our problem, using traditional clustered disks.