This article provides information on how snapshot LUN detection is handled by ESXi.
Symptoms:
# Example 1:
LVM: 8445: Device naa.xxxxxxxxxxxxxxxxxxxx:1 detected to be a snapshot:
LVM: 8445: Device eui.xxxxxxxxxxxxxxxxxxxx:1 detected to be a snapshot:
LVM: 8452: queried disk ID: <type 1, len 17, lun 36, devType 0, scsi 0, h(id) 7683208289187576905>
LVM: 8459: on-disk disk ID: <type 1, len 17, lun 17, devType 0, scsi 0, h(id) 7683208289187576905>
#Example 2:
LVM: 11764: Device naa.xxxxxxxxxxxxxxxxxxxx:1 detected to be a snapshot:
LVM: 11770: queried disk ID: <type 2, len 22, lun 0, devType 0, scsi 0, h(id) 15436777671286394200>
LVM: 11777: on-disk disk ID: <type 2, len 22, lun 0, devType 0, scsi 0, h(id) 16841058529903986994>
Important Notes :
vSphere Client
Command line
Please note the steps and warnings outlined in the Additional Information before executing this command.
Note: To view the datastores again in vCenter Server, you may have to perform a rescan of the storage adapters on all ESXi hosts that the datastore is presented to or a refresh of the storage view. If you are having trouble identifying the affected datastore, in the vSphere client, check the storage view of another ESXi host that still has the datastore mounted correctly. This will then allow you to correlate VMFS datastore name with NAA LUN identifier.
Note: Attempting to resignature an already mounted snapshot LUN fails: see fault.VmfsAlreadyMounted error when resignaturing a snapshot LUN (broadcom.com)
#Note: Do not resignature datastores that have running VMs/VMDKs, as In the process of the resignature the UUID/Path to the vms and disks will change will lead to an outage.
# This step must be carried out while vms are shutdown, unregistered and the datastore is unmounted from all ESXi hosts.
Identify if a datastore is force mounted on an ESXi host (broadcom.com)
Extending or increasing a datastore through vCenter Server fails (broadcom.com)