Thanks for the reply and clarification on the FC path misconfiguration errors". I understand that the error is caused by the client using the secondary path that goes through the cluster partners head, but I just can't figure out why and how to stop it. Here is why:

The DMP (veritas vxdmp) is setup with two paths, one primary and another secondary and is vxdmp policy set to to use round-robin, so you would think that the partner path issue would be happening all the time on all luns, but it's not. It is only happening on a handful of them and only on some of the servers and all the Solaris servers have the same vxdmp configs.

The other really bizarre thing is that I tried changing the DMP to use single-active during a maintenance window and about half of the luns would not even mount. (diskgroups went offline and disabled). So I had to set the dmp policy back to round-robin to even get them to mount again.

So at this point I'm kinda thinking that the version of VXVM I'm running has some bugs in it that would hopefully be fixed by a newer version. I'm just running out of ideas and Netapp support has been of very little help at all.


Thanks for the link and tips on udev, lun serials too.

Romeo

On Thu, Jan 15, 2009 at 1:59 PM, <jemans@xs4all.nl> wrote:

Hi,

Regarding "FC path misconfigured errors":

Both your cluster filers present their own luns but also their partner
luns on each FC port, this means your clients will see double the amount
of paths for each LUN. To prevent the error from occurring you should make
sure all clients *ONLY* go through paths that are local to a filer.

Example:
filer1
LunA
LunB

filer2
LunC
LunD

Client X sees LunA and LunC through both filers. LunA should *ONLY* be
accessed through filer1 although it is also available through filer1. The
reverse is true for LunC. You should configure this on the client not on
the filer.

Changing your config to a supported one will not by itself do anything,
except that maybe NetApp will then help you fix it.

As to the other issue on linux and seeing serial numbers, investigate
"udev" and "udevinfo":
http://www.reactivated.net/writing_udev_rules.html

Also checkout the sysfs file system you can use this to figure out which
device has which serial.

You can write rules to create file devices like:
/dev/scsi/lun-serialX

That way the path is always unique for that LUN. You can then fdisk
/dev/scsi/lun-serialX or whatever.

Regards,

Johan



--
Romeo Theriault
System Administrator