I’ve written previously about VMFS resignaturing, so rather than cover the same ground here, I’ll walk through an example of working with/troubleshooting a snapshot lun. To start with, you can check if the host is seeing any snapshot luns by running them following command from the ESXi shell:
~ # esxcli storage vmfs snapshot list
Running this on a host, to which I have presented a snapshot LUN, reveals the following:
~ # esxcli storage vmfs snapshot list 4ffa2c9d-a124e5c7-39c6-000c29e841f6 Volume Name: SANDS1 VMFS UUID: 4ffa2c9d-a124e5c7-39c6-000c29e841f6 Can mount: false Reason for un-mountability: the original volume is still online Can resignature: true Reason for non-resignaturability: Unresolved Extent Count: 1
Looking in the vmkernel.log file there is an entry showing that this lun has been detected as a snapshot:
2012-12-28T15:13:32.422Z cpu2:18137)LVM: 8445: Device t10.F405E46494C454000714543337B6D29543B603D2A6652613:1 detected to be a snapshot: 2012-12-28T15:13:32.422Z cpu2:18137)LVM: 8452: queried disk ID: 2012-12-28T15:13:32.422Z cpu2:18137)LVM: 8459: on-disk disk ID:
Looking at the output for the first command, we can see the exact reason why this lun hasn’t been mounted:
Can mount: false Reason for un-mountability: the original volume is still online
The original datastore from which the storage snapshot was taken is attached to this host. ESXi won’t mount the snapshot as it’s UUID is identical to the one that is already mounted. There are a couple of ways to proceed from here. I can either unmount the original lun then mount the snapshot, or I can re-signature the snapshot (changing it’s UUID), which will allow me to mount it along side the original LUN. The two options are summarized below:
- Keep the existing signature. You cannot mount two datastores with the same UUID on the same host. ESX uses the UUID to reference the device. As such, two with the same UUID would cause all kinds of issues. However, you may unmount the initial datastore and bring the duplicate datastore with the same UUID online. You can however mount a snapshot/replicated lun, whilst keeping the existing signature, on a host that does not have access to the original lun (this is most commonly seen when carrying out a DR plan).
- Assign a new signature. This will change the UUID and allow it to be mounted.
You choose how to mount the LUN when going through the ‘Add Storage’ wizard in the vSphere client (shown below), or using ESXCLI.
I want to keep my original datastore intact, so will re-signature the snapshot LUN using ESXCLI commands:
~ # esxcli storage vmfs snapshot resignature -u 4ffa2c9d-a124e5c7-39c6-000c29e841f6
The volume will be re-signatured and mounted. It will then be visible when listing the host’s datastores:
~ # esxcli storage filesystem list Mount Point Volume Name UUID Mounted Type Size Free ------------------------------------------------- -------------------- ----------------------------------- ------- ------ ----------- ---------- /vmfs/volumes/NFS1 NFS1 7186fc7f-332db554 true NFS 0 0 /vmfs/volumes/4ff9dae8-858c7e95-12f0-000c29e8410a TestVOL 4ff9dae8-858c7e95-12f0-000c29e8410a true VMFS-5 5100273664 2183135232 /vmfs/volumes/4f27b82e-3fc1540e-bf6b-000c295da2d9 datastore1 4f27b82e-3fc1540e-bf6b-000c295da2d9 true VMFS-5 37580963840 2551185408 /vmfs/volumes/504fbcbd-1d655805-636f-000c29e8410a SSD-Local 504fbcbd-1d655805-636f-000c29e8410a true VMFS-5 7247757312 1022361600 /vmfs/volumes/4ffa2c9d-a124e5c7-39c6-000c29e841f6 SANDS1 4ffa2c9d-a124e5c7-39c6-000c29e841f6 true VMFS-5 5100273664 4352638976 /vmfs/volumes/50ddca61-f6faa2a4-e005-000c29e841f6 snap-21483998-SANDS1 50ddca61-f6faa2a4-e005-000c29e841f6 true VMFS-5 5100273664 4352638976
It will be assigned a new volume name, in this case ‘snap-21483998-SANDS1’. It can also now be seen in the vSphere client:
