We've been wrestling with this for ... rather longer than I'd care to admit.<br><br>Host / initiator systems are a number of real and virtualized CentOS 5.5 boxes.  Storage arrays / targets are Dell MD3220i storage arrays.<br>
<br>CentOS is not a Dell-supported configuration, and we've had little helpful advice from Dell.  There's been some amount of FUD in that Dell don't seem to know what Dell's own software installation (the md3<br>
<br>Dell doesn't seem to have much OS experience generally.<br><br>Their docs are pretty inconsistent.  I've noted omissions, terminology differences, and procedural differences among the "Owner's Manual", "Deployment Guide", a professional services "Remote Services Installation Agreement" service description.  Some of the multipathing guidance we've had comes from their EqualLogic line of storage servers.<br>
<br>Questions:<br><br>1: Is there anyone out there running this configuration and are you satisfied with it?<br><br>2: We get a set of error messages on the initator at target login.  These appear to be benign, and web research suggests it's the result of a driver configuration issue in trying to send instructions to a <br>
<br>         <a href="http://comments.gmane.org/gmane.linux.iscsi.open-iscsi/5970">http://comments.gmane.org/gmane.linux.iscsi.open-iscsi/5970</a><br>         <a href="http://bit.ly/gguLl7">http://bit.ly/gguLl7</a> <br><br clear="all">
        MD3000i boxes have 1 controller that can execute IO and one that<br>        cannot execute READ/WRITE IO until a special command is sent. In<br>        older kernels, layers like the partition scanning and udev and<br>
        hal would send down IO to those disabled paths and we would see<br>        IO errors like in your link.<br><br>        In newer kernels we have device handler modules (for MD3000i you<br>        would want scsi_dh_rdac (so do "modprobe scsi_dh_rdac" and then<br>
        lsmod to see if it is there)) that will detect if the path is<br>        not active and if so it will either not send the IO or it will<br>        not print a error message since we expect the IO to fail.<br><br>We'd prefer *not* seeing spurious I/O errors that we don't have to sift through looking for real storage issues.<br>
<br>3: The MD32xxi series is a dual-controller array with multiple ports on each controller.  Multiple targets can be logged into from an initiator, with the pathways aggregated by the Linux multipath (device-mapper-multipath) system.  There's very little clear documentation on multipath.  In particular, any way to trigger alerting from multipath events / failures, or iscsi session actions, would be helpful.  The MD32xxi series only supports reporting from a GUI management utility (MDSM) which would be at best problematic to run in a server environment.  The other question is: is multipathing typical of iSCSI configuation?  Little of the iSCSI docs I've found discusses multipath configurations at all:<br>
<br><a href="http://www.open-iscsi.org/">http://www.open-iscsi.org/</a> <br><a href="http://www.cuddletech.com/articles/iscsi/index.html">http://www.cuddletech.com/articles/iscsi/index.html</a> (good but very dated)<br><a href="http://www.cyberciti.biz/tips/rhel-centos-fedora-linux-iscsi-howto.html">http://www.cyberciti.biz/tips/rhel-centos-fedora-linux-iscsi-howto.html</a> (no mention of multipathing)<br>
<br>4: Dell suggests a shutdown procedure including a flush of multipathing paths ("multipath -F" -- in the "Owner's Manual"):<br><br><div style="margin-left: 40px;">3 Flush the Device Mapper multipath maps list to remove any old or<br>
  modified mappings<br>  # multipath ­F<br></div><br>Presumably this would go into one of the init scripts -- perhaps the /etc/init.d/multipath script, as part of the "stop" sequence (after the multipath daemon is killed).  Anyone done this or know why the practice is recommended?<br>
<br>Based on our experience with Dell I would NOT recommend this configuration for others.  But we're stuck with it, and any help in getting things configured would be very helpful and gratefully received.<br><br>I'm also hoping to get clearance to release docs we've generated, though that's the subject of some internal negotiation.<br>
<br>-- <br>Dr. Ed Morbius<br>Chief Scientist<br>Krell Power Systems Unlimited<br><br>