VMFS LUN UUID
Every VMFS based LUN is assigned a Universally Unique Identifier (UUID). The UUID is stored in the metadata of your file system called a superblock and is a unique hexadecimal number generated by VMware.
When a LUN is copied or a replication made of an original LUN, the copied LUN ends up being absolutely identical to the original LUN including having the same UUID. This means the newly copied LUN must be resignatured before it is mounted. ESXi can determine whether a LUN contains a VMFS copy and does not mount it automatically
VMFS resignaturing does not apply to NFS Datastores
VMFS Resignaturing
- Creating a new signature for a drive is irreversible
- A datastore with extents (Spanned Datastore) may only be resignatured if all extents are online
- The VMs that use a datastore that was resignatured must be reassociated with the disk in their respective configuration files. The VMs must also be re-registered within vCenter
- The procedure is fault tolerant. If interrupted, it will continue later
Resignature a datastore using vSphere Client
- Log into vCenter using vClient
- Click Configuration > Storage
- Click Add Storage in the right window frame
- Select Disk/LUN and click Next
- Select the device to add and click Next
- You then have 3 options
- Keep the existing signature: This option will leave the VMFS partition unchanged
- Assign a new signature: This option will delete the existing disk signature and replace it with a new one. This option must be selected if the original VMFS volume is still mounted (It isn’t possible to have two separate volumes with the same UUID mounted simultaneously)
- Format the disk: This option is the same as creating a new VMFS volume on an empty LUN
- Select Assign new signature and click Next
- Review your changes and then click Finish
Applying resignaturing using ESXCLI
- SSH into a host using Putty or login into vMA
- Type esxcli storage vmfs snapshot list. This will list the copies
- esxcli storage vmfs snapshot mount -l (VolumeName)
- esxcli storage vmfs snapshot resignature -l (VolumeName)
Troubleshooting
As of ESXi/ESX 4.0, it is no longer necessary to handle snapshot LUNs via the CLI. Resignature and Force-Mount operations have full GUI support and vCenter Server does VMFS rescans on all hosts after a resignature operation.
Snapshot LUNs issue is caused when the ESXi/ESX host cannot confirm the identity of the LUN with what it expects to see in the VMFS metadata. This can be caused by replaced SAN hardware, firmware upgrades, SAN replication, DR tests, and some HBA firmware upgrades. Some ESXi/ESX host upgrades from 3.5 to 4.x (due to the change in naming convention from mpx to naa) have also been known to cause this, but this is a rare occurrence. For more/related information, see Managing Duplicate VMFS Datastores in the vSphere Storage Guide for ESXi 5.x.
Force mounting a VMFS datastore may fail if:
- Multiple ESXi/ESX 4.x and 5.0 hosts are managed by the same vCenter Server and these hosts are in the same datacenter.
- A snapshot LUN containing a VMFS datastore is presented to all these ESXi/ESX hosts.
- One of these ESXi/ESX hosts has force mounted the VMFS datastore that resides on this snapshot LUN.
- A second ESXi/ESX host is attempting to do an operation at the same time.
When one ESXi/ESX host force mounts a VMFS datastore residing on a LUN which has been detected as a snapshot, an object is added to the datacenter grouping in the vCenter Server database to represent that datastore.
When a second ESXi/ESX host attempts to do the same operation on the same VMFS datastore, the operation fails because an object already exists within the same datacenter grouping in the vCenter Server database.
Since an object already exists, vCenter Server does not allow mounting the datastore on any other ESXi/ESX host residing in that same datacenter.
ESXCLI Commands for troubleshooting
http://www.youtube.com/watch?feature=player_embedded&v=CFJTjbPGlY4
VMware Article Link
