In some situations, ESX will detect a LUN as a snapshot, this is not related to the VM snapshot functionality, this is something on the external or internal storage system.
What happens here is the following:
Several things can cause this condition, including:
The one thing I noticed, is that a LUN could be in snapshot condition for a very long time, and we never notice it until something causes us to reboot and then the fun begins, so even if you need to know when, it might not be possible to do so.
Regardless of what caused it, this is intended to help you get out of this situation.
Up until ESX 3.5, the only method we had was to resignature the LUN, meaning, modifying the metadata and putting the new NAA in there, this causes interesting side effects, since resignaturing causes the UUID of the filesystem to change, so you end up with a whole bunch of VMs in inaccessible state, easily solved by unregistering and re-registering the VM.
Starting with 4.x however, VMware introduced a new mechanism where we can force-mount the LUNs using the
The procedure is as follows:
esxcfg-volume -m VMFS_NAME, or permanently:
esxcfg-volume -M VMFS_NAME
esxcfg-volume -r VMFS_NAME
esxcfg-volumeoperates on a single ESX host level.
In case you want to do it from the command line, for example you have a large number of LUNs in that condition, I wrote a small one-liner that will do this for you, if you are doing a force mount, you will need to do it on each ESX host in the cluster, but it will save you a lot of time.
for i in `esxcfg-volume -l | grep VMFS | cut -d ' ' -f 3 | cut -d '/' -f 2 `; do esxcfg-volume -M $i ; done
With the introduction of
localcli that replace multiple
esxcfg-* commands, the same operations can be done using the following instead:
localcli storage vmfs snapshot list
localcli storage vmfs mount –no-persist –volume-label
localcli storage vmfs mount –volume-uuid
localcli storage vmfs resignature –volume-label