pcomo
Enthusiast
Enthusiast

SCSI LUN reset

Jump to solution

Hi,

We are searching about multipathing functionnality on esx server.

When we want to unmapped volume from the stanby path only and deleted zone on FC switch, LUN still visible on esx while VM are running even if we scan FC HBA.

It seems that esx server use the canonical path to define path to the vmfs.

But where can we found information store by esx about multipathing and SCSI path which could explain to us why LUN still visible?

Thanks

0 Kudos
1 Solution

Accepted Solutions
troberts
VMware Employee
VMware Employee

I'd still like to see the esxcfg-mpath -l output as well as the output from the procnode of the hba (example below is for 2 qla2300).

cat /proc/scsi/qla2300/1

cat /proc/scsi/qla2300/2

View solution in original post

0 Kudos
8 Replies
christianZ
Champion
Champion

Maybe the command "esxcfg-mpath -l" can help here.

0 Kudos
pcomo
Enthusiast
Enthusiast

hi,

ok esxcfg-mpath show all path available for scsi LUN, but when you unmapp the lun from the second HBA ( on Storage array) and delete the zone to that HBA, the esxcfg-mpath still shows the path as dead as long as a VM is running on the VMFS which used that path. After all running VM´s on that VMFS have been stopped, and a rescan has been initiated,the path is not longer shown. Is this a normal behavior of VMWare or a BUG?

When we check we seen that the file /proc/vmware/scsi/vmhba#/0:1 is modified when VM has been stopped and a rescan has been initiated.

In this file we can see multipathing path and policy.

It seems that all path of scsi LUN are store into this file and esx memory and while VM is runing this file cannot be modified.

All available path are store in this file even if the path is dead and esx server still known all path if the dead path failback.

It is OK ?

0 Kudos
troberts
VMware Employee
VMware Employee

Try disabling the path in the VI3 client before you remove the path

0 Kudos
pcomo
Enthusiast
Enthusiast

Hi,

No disabling the path before remove it don't change the status.

If it's not a bug, it seems that esx server keep all path to a LUN in memory. And a unmapped of the LUN from the SP is currently seen as a dead path.

I think that is not a good way because if we have a problem on the path1 active, esx server try to use the standby path which is not available due to the unmapped LUN and if the path1 come back the active path still on the second path due to the MRU policy.

I hope that someone can check the same test.

Thanks.

0 Kudos
troberts
VMware Employee
VMware Employee

Maybe I'm not uderstanding what your doing. If you disable the path you can zone out your SP or unpresent the LUN to the ESX server, initiate a rescan and the path will go away. Are you trying to remove a path that running VM's are using?

0 Kudos
troberts
VMware Employee
VMware Employee

Perhaps you can provide your esxcfg-mpath -l output.

0 Kudos
pcomo
Enthusiast
Enthusiast

Hi,

Maybe I'm not uderstanding what your doing. If you disable the path you can zone out your SP or unpresent the LUN to the ESX server, initiate a rescan and the path will go away.

Exact but when a VM is running you the path don't go away.

Our customer ask us to this problem because he changed the second path of this LUN and when he does the unmapped and zone out the path still visible.

We have test this and imagine if in a wrong way you unmapped LUN from the 2nd path (SP), the path still exist on esx server in standby or on state and if we stopped VM which run on this LUN, the path go away. WHY only when VM is stopping?

if problem occured on 1st path at this time esx multipath do a failover on 2nd path which is not available and if the 1st path go back due to MRU the path still on the 2nd path.

it seems that the problem is more important when you only unmapp LUN from SP (unmapped only on one SP)

We understand that it's a abnormal state and we just want to know how esx server store multipath information.

Thanks.

0 Kudos
troberts
VMware Employee
VMware Employee

I'd still like to see the esxcfg-mpath -l output as well as the output from the procnode of the hba (example below is for 2 qla2300).

cat /proc/scsi/qla2300/1

cat /proc/scsi/qla2300/2

View solution in original post

0 Kudos