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
Make sure you have the right DMP Array Support Library/Array Policy Modules (ASL/APM) libraries installed on your host. Else DMP and the device discovery engine will not properly claim and manage the array.
You can get these from the Symantec.com support website.
--Chris
Chris Naddeo Consulting Systems Engineer U.S. Eastern Area - Northeast Region
NetApp Moblie: 610-724-6244 cnaddeo@netapp.com mailto:Christopher.Naddeo@netapp.com www.netapp.com http://www.netapp.com/
________________________________
From: Romeo Theriault [mailto:romeotheriault@gmail.com] Sent: Thursday, January 15, 2009 3:14 PM To: jemans@xs4all.nl; toasters@mathworks.com Subject: Re: lun serial question
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
-
Naddeo, Christopher -
Romeo Theriault