2011-04-15 07:00 AM
I have a question regarding hosts that have been dead for ~1 year showing they are still logged into the target adapters. Forgive me, long time EMC admin whose just spent ~7 weeks reading every NetApp doc I can get my hands on.
In the following discussion:
It is stated there is a bug where disconnecting the host does not issue a log-out. First, I've looked and I cannot figure out how to read info on the BugID
Second.. And I hate to do it, but on an EMC, there is a command "symmask list logins" which show's you that the symmetrix once saw the wwpn, and lists "no" if isn't logged in anymore. I find this to be a very valuable troubleshooting tool. Is this bug specific to Netapp? The discussion seems to state the issue is an fcp problem. So, I'm wondering how EMC is able to detect the host has gone away?
I'm hoping there is a non disruptive way to "kick" these connections so the dead ones go away.
Thanks for any insight.
2011-04-15 07:20 AM
Normally when host disappears from fabric, fabric sends so called State Change Notifications; those who receive them are supposed to re-query fabric and discover that host is not present there anymore. If host is not present it hardly can be considered still logged in …
Login mentioned in bug text (probably, meaning PLOGI) is just one of steps in establishing connection between two FC nodes. So it hardly can be called “an fcp problem” ☺
2011-04-15 08:06 AM
I'm new to the environment. I've got Situations like this:
OS Type: vmware
Member: 10:00:00:00:c9:57:45:f4 (not logged in)
Member: 10:00:00:00:c9:57:47:e7 (not logged in)
Member: 10:00:00:00:c9:58:42:70 (logged in on: 0a, 0c, vtic)
Member: 10:00:00:00:c9:58:44:8b (logged in on: 0d, vtic, 0b)
Member: 10:00:00:00:c9:57:44:59 (logged in on: 0d, vtic, 0b)
Member: 10:00:00:00:c9:57:45:34 (logged in on: 0a, 0c, vtic)
Member: 10:00:00:00:c9:57:48:e8 (logged in on: 0a, 0c, vtic)
Member: 10:00:00:00:c9:58:3f:bb (logged in on: 0d, vtic, 0b)
Member: 10:00:00:00:c9:43:ce:dc (not logged in)
Member: 10:00:00:00:c9:57:46:a0 (not logged in)
Member: 10:00:00:00:c9:58:44:60 (not logged in)
Member: 10:00:00:00:c9:58:45:2b (not logged in)
Member: 10:00:00:00:c9:58:42:34 (not logged in)
Member: 10:00:00:00:c9:58:43:e2 (not logged in)
Member: 10:00:00:00:c9:57:44:94 (logged in on: 0a, 0c, vtic)
Member: 10:00:00:00:c9:58:3f:4a (logged in on: 0d, vtic, 0b)
I'm 99% certain that the WWN's listed as logged in can't really be. Because I can't find the same WWN's on the switches. I would feel a whole lot better about wiping out this igroup if ALL of the initiators were listed as "not logged in".
Now's where you tell me there isn't a way to "kick" the targets into cleaning this table up without resetting the adapter. ie, detect that the wwn's are dead.
I will move on then , life is tough and we can't alway's get what we want.
2011-04-15 10:36 AM
all active wwpns can be seen with "fcp show initiator", there initiators log in and log out, even if they do not log out properly they disapear in a reasonably timeframe. If you to a "igroup show (-v)" you will see initiators you ever added to these igroups, they will never disapear unless you manualy remove them from the igroup.
2011-04-15 12:05 PM
Okay. Well, the WWN's listed as logged in under igroups show, do still show up under fcp show initiator -v.
I just completed a detailed look at the switches. They are not in "show flogi database". I'm certain they should be dead and gone. People tell me the alias names are an old Vmware cluster that has been gone for a year. Basically, the logged out initiators are not 'dissapearing in a reasonable' timeframe. This bothers me, because if I ever have a real connectivity issue, and I'm wondering whether the hba is "really" logged in or not, I won't be able to tell, or will have to rely solely on the switches.
2011-04-15 01:21 PM
igroup show, the logged in initiators are seen in fcp show initiator
igroup show, the not logged in initiators are not seen in fcp show initiator
that is expected behavior.
igroup show, fcp show initiator showing an initiator which actualy is NOT in the san anymore should disapear, latest in a few hours i guess. not sure if there is a proper way to clean this, netapp technical support might have an idea or two on that, i am usualy not bothered by them, never had issues of devices not properly logging in, usualy there was a zoning problem and they didnt arrive on netapp in the first place.