After replacing the battery backup units the array went back to optimal until I realized that I had lost all the iSCSI volumes in disk manager. I know that couldn't be right so after further inspection I realized that it looks like the iSCSI network configuration was messed up.

From Dell Modular Disk Storage Manager under the iSCSI tab i select to 'Configure iSCSI Host Ports" and get this error.

Since everything was working fine, with the exception of "Failed battery" error in MDSM.

Anyone point me in a direction, will gladly postmore info if I knew what would help. Event logs show "Initiator failed to connect to the target. Target IP address and TCP Port number are given in dump data." This is what leads me to believe it perhaps just a setting lost in replacing the battery unit.

- open Modular Disk Storage Manager (MDSM)
- click on the Support tab
- select Manage Raid Controller Modules
- click on Redistribute Virtual Disks
- move preferred paths for all on "0" over to "1"
- place the RAID controller module offline
- remove the RAID controller module
- remove the screws holding the battery cover
- unscrew the thumbscrew holding the battery unit to the controller module.
- disconnect the battery unit from the connector by sliding it towards the back of the controller, then remove it from the controller module.
- place the replacement battery unit into the controller module tray and push the battery unit into the connector on the RAID controller circuit board.
- tighten the thumbscrew to secure the battery unit to the controller.
- reinstall the battery cover.
- reinstall the RAID controller module- move preferred paths back

Result showed it was back to optimal until I took a look at the drives in Disk Management.

I have without them. In the iSCSI Initiator the Discovery target had a status of "Connecting..." but never would. I disconnected the reconnected and after about a minute it did reconnect.

Going to Computer Management | Disk Management new shows ann of my iSCSI volumes for DPM but now new issue.

Array shows as Optimal for about :20min then bumps VDs off preferred paths. I'm beginning to think I have a a controller going bad. Every time I either put them back on their path either through Modify | ChangeVirtualDiskOwnership/PreferredPath or go to Support | Manage RAID Controller Modules | Redistribute Virtual Disks, I get the same results. Good for about 20:min then off path for a few.

Now I'n tracking which VD go off path to look for a common factor and in the System EventViewer.

"From what I am seeing it looks like both of the raid controller modules are stuck in a looping pattern. What I would recommend is to get the Password reset cable that came with this unit and plug it into one of the controllers. Once you have that you will need to get a support engineer on the phone as we will need to serial into the controller to see what is going on that is causing the controllers to loop like they are."

Well, right now I'm dead in the water. With the MD3000i being "end of life" for support AND we were out warranty, there was only so much I could get from Dell Support although they were helpful in determining both controllers were stuck looping. I've been referred to Sales

Okay, after doing a bunch of digging and looking at the Service Tag and you still get lifetime phone support since it was purchased before 10/29/2008. I would recommend using the number 1-800-945-3355 option 1. They will ask for your service tag of the MD3000i and if they give you any push back you can mention to them what I stated above that this system still falls into the lifetime support. If they still give you any pushback please let me know the tech that you spoke with. The phone support tech will be able to provide best effort support in ensuring that the issue is with one of the controllers. That way you know what needs to be replaced or if a new SAN will be the best option. I will be emailing you this same info as well.

This sounds like one of SAM's classic examples of why redundant controllers are not necessarily all they're cracked up to be.

It is indeed. Dual controllers seem to cause more observed failures than single ones (failing far more often.) Might be an additional example of where the SAN itself would have been better not existing as well, but not sure there from the example.

It appears that some testing I had done has resolved the constant dropped paths and lost iSCSI connections.

Since Wednesday Oct. 9 I had brought controller “0” offline and was running with only controller “1”. Everything seems to be running ok for 3+ days so 8am Saturday, Oct 12 I wanted to test the other controller the same way. This time I brought “0” online and moved all preferred paths over from “1” to “0”. After moving all to “0” I brought “1” offline to see if a controller was failing, this time testing “0”.

It stayed up running all day.

Saturday night 6:45pm I decided to bring online “1” and leave them both up. This time I’ve been running for for 4 days without going off preferred path and the iSCSI Initiator has remained connected.

Normally with both up I would start getting preferred paths dropped and the iSCSI Initiator losing connection and not re-establishing it. This would have failed within :20min and I would have to manually move it back to the preferred path. The :20-:30 min later it would happen again.