VMware Cloud Community
markw3
Contributor
Contributor

Does your FC attached storage have missing target info?

We have run into an interesting problem and I wanted to see if anyone else out there is seeing this behavior.

On our ESXi (or ESX) 4.0 & 4.1 hosts that are connected to a 4-node 3par array, if you go to the "Configuration" tab for the host. Then click on "Storage" and select one of your datastores and click on "Properties" and then "Manage Paths" 1 or more paths will have no information in the "Target" column. On this particular 3par array, it has 4 nodes, so each datastore will show 4 paths. On our older 2 node 3par arrays, I don't see this behavior.

Does anyone else see this?

If so, what type of array is it and how many paths total do you have to the datastore?

VMware has a KB article that explains a similar issue with iSCSI:

I also found a older thread where someone else had this issue: http://communities.vmware.com/message/1535646#1535646

For most people this would probably just be a reporting issue in vCenter as the paths are fully functional and do show correctly with esxcfg-mpath -b. But in our case, we are doing an SRM rollout and when SRM gathers datastore information when creating SRM datastore groups, it polls the pathing information from vCenter and fails.

Not looking for a solution, currently working with VMware, but wanted to see if others were seeing this symptom when viewing pathing information for a datastore.

0 Kudos
4 Replies
sprice23
Contributor
Contributor

I have experienced exactly the same issue.  Did you come to any conclusion with VMWare support, to explain this.

0 Kudos
markw3
Contributor
Contributor

Have been working with VMware support since I posted this message.  The have confirmed it is a bug in the management layer of hostd on the ESX host.  For us, this is more than just a reporting issue as it prevents SRM from functioning.  They are in the process of creating a customer specific hotfix for this issue which will in turn be rolled into a future update for ESX.

If it's just a reporting issue for you, I would just wait until its fixed in a future version.  If you are trying to use SRM and have run into this, let me know and maybe I can pass your information along to engineering.

0 Kudos
dbw
Contributor
Contributor

We also seen this, however we've resolved this by changing the host persona on the 3par array from Generic to Generic-Legacy.

The difference between the personas is that the generic persona includes a SES device on LUN ID 254 (Used by HostExplorer on Windows systems).  ESX was seeing this as a dead LUN.

We don't know if it was the fact that ESX was seeing a dead LUN, the SES device, a high LUN ID, or the fact that the several LUN IDs had been skipped.

0 Kudos
stevenbright1
Enthusiast
Enthusiast

During our setup of a new 3Par array we saw the same two behaviors. In regards to the LUN 254, it is correct that the host persona should be Generic-Legacy. We didn't notice that the 3Par VMware Implementation guide also states this.

As for the target information not showing up, we found that the target information was reaching certain parts of the GUI (the target information is included in the path's "Name" when you select the path in the Multipathing configuration screen). Per VMware, a host patch will be released towards the end of August that will address this issue.

Update: After we changed the host persona on the 3Par, both issues were corrected. All target information was visible and LUN 254 no longer was listed.

0 Kudos