Last week I noticed that one of the articles that I wrote in 2008 is still very popular. This article explains the various possible combinations of the advanced settings “EnableResignature” and “DisallowSnapshotLUN”. For those who don’t know what these options do in a VI3 environment; they allow you to access a volume which is marked as “unresolved” due to the fact that the VMFS metadata doesn’t match the physical properties of the LUN. In other words, the LUN that you are trying to access could be a Snapshot of a LUN or a copy (think replication) and vSphere is denying you access.
These advanced options where often used in DR scenarios where a fail-over of a LUN needed to occur or when for instance when a virtual machine needed to be restored from a snapshot of a volume. Many of our users would simply change the setting for either EnableResignature to 1 or for DisallowSnapshotLUN to 0 and force the LUN to be available again. Those readers who paid attention noticed that I used “LUN” instead of “LUNs” and here lies one of the problems…. These settings were global settings. Which means that ANY given LUN that was marked as “unresolved” would be resignatured or mounted. This unfortunately more than often lead to problems where incorrect volumes were mounted or resignatured. These volumes should probably have not have been presented in the first place but that is not the point. The point is that a global setting increases the chances that issues like these occur. With vSphere this problem was solved as VMware introduced “esxcfg-volume -r”.
This command enables you to resignature on a per volume basis…. Well not only that, “esxcfg-volume -m” enables you to mount volumes and “-l” is used to list volumes. Of course you can also do this through the vSphere client as well:
- Click the Configuration tab and click Storage in the Hardware panel.
- Click Add Storage.
- Select the Disk/LUN storage type and click Next.
- From the list of LUNs, select the LUN that has a datastore name displayed in the VMFS Label column and click Next.
The name present in the VMFS Label column indicates that the LUN is a copy that contains a copy of an existing VMFS datastore. - Under Mount Options, select Assign a New Signature and click Next.
- In the Ready to Complete page, review the datastore configuration information and click Finish.
But what if I do want to resignature all these volumes at once? What if you have a corner case scenario where this is a requirement? Well in that case you could actually still use the advanced features as they haven’t exactly disappeared, they have been hidden in the UI (vSphere Client) but they are still around. From the commandline you can still query the status:
esxcfg-advcfg -g /LVM/EnableResignature
Or you can change the global configuration option:
esxcfg-advcfg -s 1 /LVM/EnableResignature
Please note that the first step was hiding them, but they will be deprecated at some future release. It is recommended to use “esxcfg-volume” and resignature on a per volume basis.
Manish Patel says
esxcfg-advcfg is not hidden and is available on ESX/i 4.1
# /usr/lib/vmware/bin/esxcfg-advcfg -s 1 /LVM/EnableResignature
Value of EnableResignature is 1
# vmware -v
VMware ESXi 4.1.0 build-260247
Duncan Epping says
With “hidden” I refer to the UI not to the command line as I obviously show in the article that it is still there.
Peter says
Does /LVM/EnableResignature exist in vSphere 5 (ESXi 5)? If it does not exist how SRM can set this value to “1” on ESXi 5?
Emer says
Peter, try this by SSH to your host:
(the current configuration)
~ # esxcfg-advcfg -g /LVM/EnableResignature
Value of EnableResignature is 0
(the new configuration)
~ # esxcfg-advcfg -s 1 /LVM/EnableResignature
Value of EnableResignature is 1
(Check your new configuration)
~ # esxcfg-advcfg -g /LVM/EnableResignature
Value of EnableResignature is 1
Regards!