I have a little issue with MPxIO and the way our sysadmins work with storage in our SAN, all input is appreciated.
Today we use VxFS on top of VXvM using VxDMP, I am evaluating if we can begin to use ZFS together with MPxIO. Here is the problem, is not really a technical one, but an administrative issue: Today we can have over hundred LUN:s used by a single host, when an administrator is going to create a new disk group or grow a volume the LUN is identified by the LUN id. Without any multipathing software Solaris sees this disk as in the format c<N><WWN><LUNid> e.g: c3t5006157452A6A768d387s2 With VxDMP I get the name in the same form, but hides two paths behind it, using one of the name of one of the pahs: c3t5006157452A6A768d387s2. In both those cases is i easy to identify which disk is a specific LUN, as long as our storage team has done everything right, the LUN id part of the name is unique on the host (d<nnn>). When I tried MPxIO instead all LUNs get new names that does not contain the LUN id : e.g. /dev/rdsk/ c4t6006157000028797091143454C304238d0s2. This is a bit confusing and harder to keep track of, what I want is that the disk part of the name to keeps the LUN id. I can map the MPxIO name to the LUN id, but that is something that must be done manually with luxadm or in scripts. Ether way it is harder to see that you are using the correct disk: zpool create ollespappa c4t6006157000028797091143454C304238d0s2 \ c4t6006157000028797091143454C305240d0s2 \ c4t6006157000028797091143454C309323d0s2 With the LUN id I only need to look at the disk part, which is quite a bit easier: zpool create ollespappa c3t5006157452A6A768d387s2 \ c3t5006157452A6A768d230s2 c3t5006157452A6A768d123s2 Do we have to live with this when if we switch to MPxIO? Regards Henrik _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
