Yesterday I saw a strange situation on one of our customers systems. They use DataCore quite from the beginning (SANsymphony 4 was the first release they used in production) and upgraded the environment one version after the other ending with the latest release SANsymphony-V 10.1.
With the availability of WIK 3.0, the latest version of DataCores MPIO software for Windows servers, they decided to upgrade their 3-node filecluster based on Windows Server 2012R2. So far not a problem at all.
After upgrading all hosts the cluster was working fine. Yesterday they attached a fourth node and requested to present all vDisks from the other cluster member to the new host. After a rescan the DataCore GUI showed only about 1/4th of the vdisks (in sum the system has 60 disks attached) actually presented to the system. Furthermore, the Windows disk manager won't start at all, it crashed during collecting information about the disks presented. So a reboot was done but after the reboot, the situation remained the same.
Checking the other three hosts that were also upgraded to WIK3.0 the DC GUI showed the same amount of vdisks handled by MPIO as the fourth node but the disk manager showed a lot more, to be exactly it showed 222 disks. So for the moment it seemed that the DataCore MPIO only handled a few of the disks presented to the system, the other disks were ignored. The cluster itself worked like a charm.
Because DataCore MPIO is based on Windows native MPIO I checked the Windows MPIO subsystem and found under "MPIO devices" beside the well known "DataCoreVirtualDisk" entry another "DataCore SANsymphony" entry. Now the clouds disappeared.... vDisks created with DataCore SANsymphony versions below v8 (SANsymphony-V) included the "SANsymphony" string in the SCSI information, whereas the versions higher than v8 changed that field to "VirtualDisk". During upgrades of SANsymphony(-V) this field isn't changed to the new nomination so old disks still have the old string in the SCSI information. The newer MPIO versions from DataCore ignore the old SCSI information and only search for "VirtualDisk" so the DataCore MPIO won't take care about the "old" disk type.
To prove this assumption I created a little test lab containing a fully redundant DataCore SSY-V 10.1 installation and a physical Windows 2012 R2 server attached via FC to the DCS. Then I created two virtual disks, one 1TB and one 10GB disk (the size doesn't matter at all). I changed the 1TB disk settings to match the "old" SCSI information:
Next I installed WIK3.0 on the Windows Server and presented both disks to the server. The Windows MPIO showed default settings after the reboot.
Starting the disk management on the Windows server one can see that both disks were detected but only the 10GB is handled by MPIO.
The 1024GB disk is displayed 4 times here. Don't care about the 2048GB disk (VMFS001), this is a VMFS volume from a ESX-Cluster where the system is acting as backup proxy.
The DataCore MPIO GUI displayed only one disk, too.
Rebooting, rescanning, whatever, won't change this behavior. Next let's check the Windows MPIO settings again but this time we change to "Discover Multi-Paths"
Here you can see the additional DataCore disk type. Mark this entry and click on "Add" to tell Windows MPIO to take care about this type of disk. A reboot is required to complete the action.
After the reboot, reopen the Windows MPIO settings and check the entries on the first page
Now Windows MPIO takes care about all DataCore disk types (and additional a 3PAR volume but you can ignore this for now).
Let's switch to the disk properties. Goto disk management, right-click one of the two DataCore disks and choose "Properties".
On the disk with SCSI label "VirtualDisk" you will see "DataCore DSM" as responsible MPIO DSM.
Whereas on the other disk you will see the "Microsoft DSM" as active DSM
The funny thing is, if you now open the DataCore MPIO GUI you will see both disks with all information although the DataCore DSM will only care for one of the disks.
Using Windows native MPIO without the DataCore extension is a fully supported configuration as long as you set "ALUA enabled" as host property in the SSY-V GUI. You still have some minor impacts if you only use Windows native MPIO as you have to rescan manually your devices after a path failover but the failover itself will work as expected.
Using DataCore MPIO is also fully supported and recommended.
Using both methods on the same system the same time is nothing I was able to find in the DataCore ocumentation so I will open a case to clearify this. But for the moment I'd rather use a "not officially recommended" setup than having no MPIO at all.