SAN snapshots of VMFS Datastore(s) appear in Add Storage Window without option to "Add with resignaturing" or "Use existing signature"
search cancel

SAN snapshots of VMFS Datastore(s) appear in Add Storage Window without option to "Add with resignaturing" or "Use existing signature"

book

Article ID: 401974

calendar_today

Updated On:

Products

VMware vSphere ESXi VMware vSphere ESX 7.x VMware vSphere ESX 6.x VMware vSphere ESX 8.x

Issue/Introduction

Symptoms:

  • A SAN snapshot of VMFS Datastore may appear in the Add Storage Window without the option to Add with resignaturing or Use existing signature.
  • You might encounter this when you enable read/write mode on the replicated LUNs at a recovery site during a manual or custom scripted disaster recovery-- especially if you are not using  dedicated disaster recovery software, such as VMware Live Site Recovery.

Environment

  • VMware vSphere ESXi (All Versions)

Cause

  • This is due to incorrect presentation of the LUN from the SAN to the hosts. 

 

Verification: 

  • You can identify the incorrect presentation from the LUN ID of the LUN. The LUN ID for the same LUN should be identical across all hosts in the cluster.
    • NOTE: ESXi does not assign the LUN ID.  The ID is obtained from the SAN during the inquiry on the LUN during discovery.

  • You can see the LUN ID by running the following command from an ssh session on the ESXi hosts as follows:

 

esxcfg-mpath -b 

 

Example output:

naa.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx : EMC Fibre Channel Disk (naa.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx )
   vmhba1:C0:T1:L1 LUN:1 state:active fc Adapter: WWNN: XX:XX:XX:XX:XX:XX:XX:XX WWPN: XX:XX:XX:XX:XX:XX:XX:XX Target: WWNN: XX:XX:XX:XX:XX:XX:XX:XX WWPN: XX:XX:XX:XX:XX:XX:XX:XX
   vmhba3:C0:T3:L1 LUN:1 state:active fc Adapter: WWNN: XX:XX:XX:XX:XX:XX:XX:XX WWPN: XX:XX:XX:XX:XX:XX:XX:XX Target: WWNN: XX:XX:XX:XX:XX:XX:XX:XX WWPN: XX:XX:XX:XX:XX:XX:XX:XX
   vmhba4:C0:T4:L1 LUN:1 state:active fc Adapter: WWNN: XX:XX:XX:XX:XX:XX:XX:XX WWPN: XX:XX:XX:XX:XX:XX:XX:XX Target: WWNN: XX:XX:XX:XX:XX:XX:XX:XX WWPN: XX:XX:XX:XX:XX:XX:XX:XX
   vmhba2:C0:T2:L1 LUN:1 state:active fc Adapter: WWNN: XX:XX:XX:XX:XX:XX:XX:XX WWPN: XX:XX:XX:XX:XX:XX:XX:XX Target: WWNN: XX:XX:XX:XX:XX:XX:XX:XX WWPN: XX:XX:XX:XX:XX:XX:XX:XX

...


In the above example, the highlighted text confirms that the LUN ID is 1 for the specified device (naa) ID.  

 

Resolution

  • CAUTION:  DO NOT proceed with adding a datastore that has data that you need to preserve if the there is no Add with resignaturing or Use existing signature mount options in the Add storage or New Datastore dialog. Proceeding will reformat the VMFS and result in data loss. 

  • This is similar to KB: Storage LUNs that are already in use as an RDM appear available in the Add Storage Window
  • However, in this case, the LUN's are not used as RDM's, but are used for VMFS datastores, so the remediation steps are slightly different due to VM's being located on the datastore(s).
  • The steps to correct the presentation are as follows: 

    1. Storage Migrate (sVmotion or Cold migration)  -or-  shutdown and unregister any registered virtual machines on the affected datastore, if any. 
    2. Unmount/Detach the LUN(s) from the affected ESXi/ESX host(s). For instructions, see How to detach a LUN device from ESXi hosts (2004605)
    3. Perform a rescan of the storage on an ESXi/ESX host. For more information, see Performing a rescan of the storage on an ESX/ESXi host (1003988).
    4. Work with your SAN team, as needed, to correct the LUN's ID's and re-present the LUN(s) back to the ESXi host(s)
    5. Perform a rescan of the storage on the ESXi host(s).  NOTE:  In some cases, the LUN may be detected as a snapshot at this point.  If so, see KB on resignaturing the LUN: Unable to mount a VMFS volume to an ESXi Host
    6. Migrate the VM's back to the datastore or re-register any VM's the were unregistered in Step #1, as needed.