DSM MPIO 9 problems

[Fred Blum]

The DSM MPIO 9 installed by WindowsUpdate cannot be deinstalled. It is only visible in the Update History as being installed succesfully.
The details window for HP DSM MPIO accessed tru iSCSI initiator still showed 8.5 version.

I did a clean install, choose the HP DSM MPIO 9 from the Windows Solutions disk downloaded from the HP site. With all settings that worked and were tested with DSM MPIO 8.5 now with the new DSM MPIO 9 creates access problems. The SAN LUN cannot be accessed properly and will make the Management Console Windows become unresponsive.

Have not received a solution from HP. See no other solution than to uninstall and return to DSM MPIO 8.5. Should never have accepted that WindowsUpdate in the first place.

[Fred Blum]

I did a clean install of W2008 R2 Datacenter and installed DSM MPIO 9 on it. I connected iSCSI initiator to the former witness disk of the cluster that was destroyed after the DSM MPIO 9 WindowsUpdate problems and tried to format the disk. The window again becomes unresponsive and will end in an error.
I deinstalled HP DSM MPIO 9 and reinstalled DSM MPIO 8.5. Same issue.
I deinstalled HP DSM MPIO 8.5 and removed the MS MPIO feature and setup iSCSI initiator to connect tru teamed nics to the Witness disk. Now it comes with an NTFS event log error and a CHKDSK warning.

I removed all settings again from iSCSI initiator and this time also deleted the Witness volume on the SAN, restarted the W2008 server and created a new Witness volume on the SAN. This time it starts good with recognizing a new disk, assigning a drive letter and finishes in no time the format disk.

Could this former witness volume have become so corrupt due to the DSM MPIO 9 WindowsUpdate that it would not be mountable anymore? Or was there a stale connection on the san volume that interfered?

Will try to install DSM MPIO 9 again.

[kghammond]

Not sure what to say...

We are working with Microsoft and HP on an issue that feels similar to yours.

We have a Windows 2008 storage server cluster that *appears* to have failed after upgrading to the HP DSM MPIO 9.

It was previously running HP DSM MPIO 8.5 without problems. Our SAN is still running SanIQ 8.5.

After the MPIO upgrade to version 9, neither node of the SAN will bring the cluster disks online.

Some of the troubleshooting we have done:
- Removed the HP DSM MPIO.

- re-presented the SAN LUN to a separate Windows 2008 server. One to a server running DSM 9 and another running DSM 8.5. In both cases the LUN's came up as RAW disks instead of NTFS disks.

- Disconnected and logged off all iSCSI LUN's from both cluster nodes, rebooted both cluster nodes with the cluster disabled and the cluster driver disabled. Re-presented a LUN and it came back as RAW.

- Our next test is to remove the Microsoft Multipath I/O feature and see if that has any impact.

We are not confident that DSM 9 is the root cause, but it has not been ruled out yet.

I will post an update if/when we determine a root cause. At this point, our cluster has been offline for about 36 hours...

[Fred Blum]

"In both cases the LUN's came up as RAW disks instead of NTFS disks."

Exact same issue as in my case. But my case is a pre-production test configuration which is clean and allows volumes to be deleted and recreated again. As I am new to HP SAN I always have to take in account a possible misconfiguration on my part. For that reason I am looking for and asked HP a document for troubleshooting this MPIO 9 issue with all best practise settings for a DL380G7, two 382i nics to the SAN, MPIO, HP MPIO and iSCSI initiator. But I am pretty sure I got them right by now.
I have a three year 4h onsite response epack but sofar have not received any other support the last four days as two mails asking me if I fixed it.


36 hours storage offline is a horror scenario, and the SAN solution was bought by us to prevent it from ever occuring.

Have you tried creating a new volume and seeing if that can be added, formatted and used without a problem? Restoring the data from a backup to that volume?

[Fred Blum]

"It was previously running HP DSM MPIO 8.5 without problems. Our SAN is still running SanIQ 8.5"

Same situation in my case when the cluster failed. I have not found a way of bypassing the FTP site busy error yet for updating the SAN. Will try to do so first before retrying MPIO 9.

[Fred Blum]

@kghammond

I hope you found the root cause. If not this is the solution according to HP support:

Trouble bringing disks online
If you cannot access volumes or do not see the disks (in Disk Manager or My Computer), you may need to bring the disks online. You may also see that the device in the iSCSI Initiator is listed with a device number â 1 or with no device name. Use the following Windows utilities to solve the problem:
â ¢ The automount setting in the Windows 2008 and Windows 2008 R2 DiskPart Command-Line
affects whether disks will mount after changes in MPIO status, such as uninstalling generic MPIO or the P4000 DSM for MPIO.
To run DiskPart, open a Windows command line and run diskpart.exe.
For detailed information about the DiskPart Command-Line, see http://technet.microsoft.com/enus/
library/cc766465(WS.10).aspx.
â ¢ Log off all iSCSI sessions and use the command automount scrub to clean up volume mount point directories and registry settings for volumes that are no longer in the system. This can clean up conflicting disk information that prevents disks from coming online. Information about automount
is available by typing the command help automount from the diskpart command line.
â ¢ Check the SAN policy setting. The SAN policy should be set to Online All for SAN/iQ volumes to remount after uninstalling the P4000 DSM for MPIO. Information about the SAN policy is available by typing the command help SAN from the diskpart command line.

P4000 Windows Solution Pack user guide 21

http://bizsupport1.austin.hp.com/bc/docs/support/SupportManual/c01865547/c01865547.pdf

I can not check it as I made it work by deleting and recreating the volume.

[kghammond]

That did not seem to help in our case.

This is our closest guess at a root cause right now.

http://social.technet.microsoft.com/Forums/en/winserverfiles/thread/5fb7b833-7952-4c49-889a-6be01298e923

We had two disks assigned to the cluster as availble storage that were not assigned to the file server resource itself. Once we deleted these two disks, the cluster resumed normal operations.

We are not positive if they were the root cause and if so, how they got in a invalid state...