MSA-1000 odd behavior with dual pathing

[Derek_31]

On two different SANs using MSA-1000s with firmware 4.32 and now 4.48, we have a strange problem. In ACU the SPP window only lists half of the HBAs in the servers (dual fabric configuration, no zoning, A73AAs HBAs, two HBAs per host, 2/32 switches with 4.4.0c, WS2003E). After fiddling around with things, we found a workaround. Launch ACU (PSP 7.20 and 7.30) on each server, and magically the other HBA will appear. After doing this on ALL servers, the SSP table is fully populated with all HBAs.

Any idea why this is happening? This hasn't happened the last two years we've been using MSAs, but seems like the last six months something in the PSP, HBA, MSA or fabric is acting weird. And yes, zoning was disabled when troubleshooting.

[Uwe Zessin]

I've seen similar problems - adapters do not get (fully) registered in the connection table - with other adapters and on other arrays (e.g. HSG), too. These effects have been there for many years.

In the end I am trying to cause an 'event' to the configuration: scanning in the adapter's BIOS, the server's console subsystem, something like IOSCAN on the operating system or disabling/enabling the adapter port.

Before going live, I make sure that all paths are working.

[SAKET_5]

Yup, experienced this myself on a number of occassions on HSG80s, MSAs & EVAs. And generally a "portdisable" followed by a "portenable" of the switch port to which the FCA is connected to does the trick, as it forces the "node" (FCA - N port) to perform a FLOGIN followed by a PLOGIN.

What Uwe suggests has also worked on numerous occassions - such as on Tru64 - emxmgr and scanning the devices, Linux - if you can afford to - !!warning!! rmmod "fca driver module" followed by modprobe "fca driver module", or the HBA BIOS Scans, etc.

Hope, it helps.

[Derek_31]

So why can't HP fix it?

[Uwe Zessin]

So why don't you ask HP?

[Glenn N Wuenstel · Accepted solution]

It's a basic "feature" of how multipathing works at this time. I'll address the issues from an MSA perspective.
First, when ACU is run on a machine then ACU will make sure that all HBAs get registered with the MSA this is a "fix" that HP has put in place -- I'd say more of a workaround or feature not fix.
Secondly, since the MSA architecture is active-passive only one HBA is going to be active to one controller. Until all the HBAs actually log into the controller then the controller has no way to know about the HBA. ACU forces the registeration but only when it is run on the server. You can also force the registration as stated by others. What you are in effect doing is getting the HBA to contact the controller. You could also cause a failover and that will also register the paths. Think of it this way, two paths exist to the target (controller) but the controller has no way to know that the two paths are there unless the paths make an active connection. Being passive the target can't just go out and scan to see who has access. When I look at it in this light it kind of makes sense but is still annoying.
If anything I'd say the multipathing software seems like the place to make some sort of change to allow say an "initial" registration kind of option to get all paths to go active one after the other and then go back to the setting before the round robin.
What do you think?

Glenn

[Uwe Zessin]

Hi Glenn,

having the multipath software do the registering would be much too late for me. I routinely work with non-x86 servers and on AlphaServers, for example, it is daily business to boot from a storage array. It is absolutely essential that all 'connections' are preregistered and have the correct OS type/ profile assigned before the OS installed on a SAN-attached disk.

[SAKET_5]

I concur with Uwe's points being in a similar position myself. We have a large number of Tru64 on Alphas - and majority boot off the SAN ....even at the SRM layer on alphas - "wwidmgr - show wwid" provides sufficient multipathing intelligence - and during the OS install - for host operating system with inbuilt multipathing software - the redundant paths are transparent to the OS install.

Its a pity that to boot off Linux and Windows off the SAN Disk - you still need to configure single path zoning for the boot disk for the inital OS install - or just watch how Windows install behaves with 4 paths visible to its boot disk during the initial OS install!

So, FLOGINs & PLOGINs of all HBAs must not wait till an OS level multipathing deamon kicks in - NO absolutely NOT!

Regards,
Saket.