I solaris 10 as bad about this as ESX server?
I also see the same issue with Solaris server
We wrote our own script that will fix the optimal path across all 12 esx servers, but over time they seem to switch but aren't sure what is causing the path to switch. We know the paths aren't going down and we are not exceeding the capacity of the ports?
Thanks.
Jack
Linux Admin wrote:
Thank you all for your help!
<mailto:sysadmin.linux@gmail.com>> <mailto:toasters@mathworks.com>>On Wed, Mar 4, 2009 at 2:52 PM, Fouquet, Errol <Errol.Fouquet@netapp.com <mailto:Errol.Fouquet@netapp.com>> wrote:
Accessing a LUN across a partner path will function fine ... and
in some cases, there may be no problems perceived.
However, IOs across the the partner path do not perform as well
under load than access to the primary paths.
For ESX, proper path prioritization is very easy to accomplish
with the scripts provided in the Host Utilities Kit.
As for the original issue on this thread ... assuming you have
multipathing set up correctly, the warning may be associated with
normal path checking activity.
Check your lun stats data and divide the "partner kb" by "partner
ops", if the answer there is ~512b ... then these warnings could
simply be path checking done by multipathd.
If the average IO size seems significant, open a case with support
and get some assistance in determining why IO is going over the
partner path.
--
errol
------------------------------------------------------------------------
*From:* Fred Grieco [mailto:fredgrieco@yahoo.com
<mailto:fredgrieco@yahoo.com>]
*Sent:* Wednesday, March 04, 2009 2:21 PM
*To:* Linux Admin; NetApp Toasters List
*Subject:* Re: FCP Partner Path Misconfigured - Host I/O access
through a non-primary and non-optimal path was detected.
I'm a little foggy on the details... it's been a while since I
read them or thought about it. But, assuming you mean
single_image mode, host can see the luns on all four ports, and
data can be accessed through all four ports. Now N1 may own the
lun, but it can be accessed "through the interconnect" through N2.
Multipathing on the host determines which path will be used to
access data, and whether or not the an active/passive or round
robin (or whatever). If you are using Netapp multipathing, it
knows to use only the N1 path. But other multipathing doesn't
understand this, and will pick the primary path at random.
I have tons of VMWare hosts that have seemless esx multipathing,
but pick the wrong paths by themselves. Then you get the error. I get this error all the time and really haven't had a problem
with it... but it's the first thing support will bring up when you
call about anything. I have noticed that it seems to run the CPU
a little high (since it has to swap things in and out of memory
through the interconnect).
Fred
------------------------------------------------------------------------
*From:* Linux Admin <sysadmin.linux@gmail.com
*Sent:* Wednesday, March 4, 2009 2:38:19 PM
*Subject:* FCP Partner Path Misconfigured - Host I/O access
through a non-primary and non-optimal path was detected.
Hello Toasters.
I am receiving the following message from auto support: FCP
Partner Path Misconfigured - Host I/O access through a non-primary
and non-optimal path was detected.
I have a single cluster acting in single fabric mode and it is
wired up in the following way.
Each host has an i-group on each node of the cluster for. Each of
the netapp node is connected to sw1 and sw2 and hosts also has a
path to sw1 and sw2.
Why would the host access luns on N2 via partner node N1
--------------- ---------------
{ n1 } { n2 }
| \ / |
| \ / |
| \ / |
| \ / |
--------------- ---------------
{ s1 } { s2 }
\ /
\ /
---------------
{ host }