Alert ! "This HBA is not able to access LUNS that belong to its server."

is it actually connected ? Can you look in Connectivity status to make sure that HBA is logged-in and registered (color should be green)

Dynamox,

Yes all connections are there.  I think I know what it is.  Its not connected to any storage group, within Navipshere.  I'm not sure I need to really worry about this..

if it's supposed to be connected to a storage group then you have a server that's missing a path. If that's the case follow this instructions (from kelleg)

"

When you expand the tree for the Storage Group, you should see at least  two icons - Hosts and LUNs - expand the Hosts icon and you'll see the  host that is in this storage group - right-click on the host icon and  select connectivity status - this will show (or should show) the two  HBAs and the four paths and all should be listed as logged in - if not,  click reconnect"

Does clicking on 'reconnect' affect the VM host that may be happy and accessing luns down one of its HBA paths? I don't have powerpath on my VM server yet and I don't want pause connection to HBA that is not having connection issue.

Thanks, Mickels

it depends on the failover policy set on ESX side, if it's set to MRU then nothing will happen, if it's set to Fixed then LUN access will go back to default LUN owner (there will be a trespass).  As long as all nodes in the cluster are set to the same policy, this trespass will be transparent to your VMs.

Once again Dynamox, you have solved the mystery. Thanks so much for your brilliant answers!

Thank you! Wow. If I could just hang out with you two instead of cleaning up all of these storage groups someone messed up, life would be grand :).

Thanks again - Mickels

When I first registered my account on this forum, I mistakenly thought that dynamox was an EMC employee.  I'm sure he recalls my reply to one of the posts suggesting that.

Anyways... even though you have resolved your issue, I had just replied to another recent post and made reference to updating the host registration.  As I was catching up for the night, I thought I'd repeat here the three options, as there is one that method that assures you that you are only affecting specific paths.  My response in a separate post was as follows; I realized now it could be cleaned up a bit:

[...]

Please note that when a registered host is in a storage group and later new paths are registered, they are not automatically associated with the host in the storage group.  To update it, there are three options:

a) Remove host from storage group and promptly add it back

Of course, the host temporarily loses access to the LUN and that outage is as fast as you can remove/add the host.  This therefore probably should not be considered, but mentioned here for sake of completeness.

b) Select "Reconnect" from "Connectivity Status" when navigated to as already mentioned by dynamox

We do advertise this as non-disruptive from the CLARiiON's perspective, but to verify that you only touch the new paths...

c) While in "Engineering Mode" (an exercise for the reader to research how to access)

- Right-click on the Storage Group Name and select "Connect Hosts"

- From the "Hosts" tab you will now see an "Advanced" button (as a consequence of enabling Engineering Mode)

- Click the "Advanced button, and you will see for each host (if there are more than one in the storage group they are separated by tabs) there are checkboxes next to each registered path; simply check any unassociated paths to update the host registration

Finally, take appropriate measures on the host to update the paths to LUN(s).

[...]

Hi

I've got a similar issue however my host should not be connected to a Storage Group at least not yet, it's zoned to three arrays but it's only using I/O from one of them at the moment.

Is there a way to solve this issue (apart from deleting these alerts i suppose)?

Thanks