Start a Conversation

This post is more than 5 years old

Solved!

Go to Solution

3424

March 24th, 2014 15:00

Strange cx3-10 and cx3-80 problem with windows 2008r2 MPIO

Hi All,

I have a strange problem with windows server 2008 R2 with several luns attached over FC: one from IBM Storwize v7000, one from cx3-10 and a new one from cx3-80 which caused an unusual problem (I'm using native windows MPIO without Powerpath) After zoning the server with the LUN from cx3-80 it appeared in windows disk manager as several disk because of multipath. Next thing I did was to discover multipath devices in "MPIO" windows applet (the detected device type was "DGC  LUNZ"). I added the device, popup with a need of reboot appeared. I noticed the new LUN merged into one in disk manager. All happy I rebooted the server but after the reeboot the old LUN from cx3-10 hasn't initialized during startup. I tried to initialize it manually but it said "device is busy". The cx3-10 lun was set to failover path policy. I changed the active path to a different one, and the disk initialized but the disk manager didn't find any partitions on it - it just shows unallocated space, when there used to be an NTFS partition with data on it. I changed the active path to different one and the device initialized as readonly. The new LUN from cx3-80 isn't much better: it says "device is busy" no matter which multipath policy I choose. During the initial configuration the cx3-10 lun didn't work with round robin saying "device is busy" when trying to initialize the disk - this is the reason why I used failover policy.

Any suggestions what might be the problem?

86 Posts

March 25th, 2014 04:00

Just to clarify, when using Microsoft Native MPIO feature the Failover Mode must be 4.

When using PowerPath it can be 1 or 4.

Regards, Michel.

86 Posts

March 24th, 2014 16:00

If you are seeing LUNZs in Windows then you have a configuration issue, and you should not multipath the LUNZ device.

There is a good explanation of this in  KB https://support.emc.com/kb/75043

Also check the EMC Host connectivity Guide for Windows on correct configuration setup for Microsoft Native MPIO. https://support.emc.com/docu5134_Host_Connectivity_Guide_for_Windows.pdf?language=en_US

The document is under review, and some parts that were removed recently will be re-added next week.

Try this version A54 of the guide, as it has more instructions for MPIO and W2K8. Use method 2 on page 326.

https://ftp.emc.com/action/login?domain=ftp.emc.com&username=aGNccbzyX&password=138384B3gA

Alternatively, open a case with EMC Support and we should be able to assist. Don't forget to upload an EMCReports.

ftp://ftp.emc.com/pub/emcgrab/Windows

3 Posts

March 24th, 2014 16:00

Thank you for your prompt response!

One thing I forgot to mention is that after the configuration changes I notice that the cx3-10 lun has a different Disk ID aka UUID observed in windows "diskpart tool". Judging by the size I'm pretty sure it is the same device as before but with different UUID.

86 Posts

March 24th, 2014 19:00

ok, I think it would be best to open a case and have someone look over the EMCReports.

Regards, Michel.

213 Posts

March 25th, 2014 02:00

eth111, Playing with MPIO settings is not recommended at all especially for production hosts. What i recommend you to do now is to remove the multipathing (MPIO) feature and down all paths to all a single path. Ensure that Failover mode is set to 1 or 4 from the CX3s side. (Mode 4 will not be available unless you are running Flare 26).

After doing so, Kindly update us how the LUNs look like. I have seen a similar situation before but it was due to using Failover mode 3 which I assume it is not your case.

Like Mich said, EMCReports is needed as in such cases, we need to check the secinspect.exe output. This is really helpful to get the File System type on the disks and then give the straight answer whether there is a corruption on the file system or not.

Hope it helps..

Mohammed Salem  @yankoora

3 Posts

March 28th, 2014 14:00

Hi, the problem has been solved by changing "failover mode" on both arrays to 4. The cx3-80 LUN is now correctly discovered as "DGC RAID5" instead of LUNZ. Unfortunately, the filesystem on cx3-10 lun seems to be gone, but fortunately I can live with that. Thanks for the support.

No Events found!

Top