LVM: 4476: vmhba0:0:0:1 may be snapshot: disabling access. See resignaturing section in SAN config guide

[chukarma]

Hi all,

I have a cluster of 8 ESX 3.5 Update 1 with over 100 VM running currently. I just installed Update Manager on my VC and ran remediated on of my host calls HOST15. After the remediation was completed, I saw the following error code below on my console.

2008-09-03 15:35:31.399 'ha-eventmgr' 22547376 info Event 16 : Issue detected on vmhost15 in ha-datacenter: LVM: 4476: vml.020013000060060e8004296200000029620000130b4f50454e2d56:1 may be snapshot: disabling access. See resignaturing section i

2008-09-03 15:35:34.335 'ha-eventmgr' 22813616 info Event 17 : Issue detected on vmhost15 in ha-datacenter: LVM: 4476: vml.020013000060060e8004296200000029620000130b4f50454e2d56:1 may be snapshot: disabling access. See resignaturing section i

2008-09-03 15:35:44.700 'ha-eventmgr' 22813616 info Event 18 : Issue detected on vmhost15 in ha-datacenter: LVM: 4476: vml.020013000060060e8004296200000029620000130b4f50454e2d56:1 may be snapshot: disabling access. See resignaturing section i

After logging in to check out my storage configuration, I found that one of the LUN was missing on this host storage configuration along with vmhba 1:0:19 ID. All the other 7 hosts are still seeing this LUN on vmhba 1:0::19 ID. Fortunately, there's only one VM being hosted on this LUN and it is not a critical VM. The VM on this LUN is being hosted by another host and is still running effectively. I googled around and found these threads:

I spoke to my SAN admins and they confirmed no changes were made so I am trying to figure out what changes were made to cause this error message. Was it the patches update that caused this or something on the SAN side changed? On another note, I can go to HOST15, choose add storage and the missing LUN is there for me to add at vmhba 1:0:19 ID. Is it safe to add it back to this host?

Thanks,

Daniel

[Kfiat]

Had the same problem after Update. To fix the problem:

1. Log into the host through VIClient

2. Goto Advanced Configuration

3. LVM

4. Change "LVM.DisallowSnapshotLun" value to 0

I also rebooted my host, but only because it occured on fresh installation and there were no VMs running.

[Obel1sk]

This works... VMWare support was unable to help me with this. They were stuck on "we don't support Openfiler." It is upsetting when companies pass the buck instead of helping out customers.

[admin]

You must double check you SAN configuration because work change "LVM.DisallowSnapshotLun" can affet your environment. If you LUN is presented with a different ID to different host within the datacenter, you should see this error.

State 1: EnableResignature=0, DisallowSnapshotLUN=1 (the ESX Server 3.x default)

You cannot bring snapshots or replicas of VMFS volumes by the array into the ESX Server host regardless of whether or not the ESX Server has access to the original LUN. LUNs formatted with VMFS must have the same ID for each ESX Server host.

+ State 2: EnableResignature=1 (DisallowSnapshotLUN is not relevant)+

In this state, you can safely bring snapshots or replicas of VMFS volumes into the same servers as the original and they are automatically resignatured.

+ State 3: EnableResignature=0, DisallowSnapshotLUN=0 (ESX Server 2.x behavior)+

This is similar to ESX Server 2.x behavior. In this state, the ESX Server assumes that it sees only one replica or snapshot of a given LUN and never tries to resignature. This is ideal in a DR scenario where you are bringing a replica of a LUN to a new cluster of ESX Servers, possibly on another site that does not have access to the source LUN. In such a case, the ESX Server uses the replica as if it is the original. Do not use this setting if you are bringing snapshots or replicas of a LUN into a serverwith access to the original LUN. This can have destructive results including:

+ If you create snapshots of a VMFS volume one or more times and dynamically bring one or more of those snapshots into an ESX Server, only the first copy is usable. The usable copy is most likely the primary copy. After reboot, it is impossible to determine which volume (the source or one of the snapshots) is usable. This nondeterministic behavior is dangerous.+
+ If you create a snapshot of a spanned VMFS volume, an ESX Server host might reassemble the volume from fragments that belong to different snapshots. This can corrupt your file system.+

[CHJJ]

Many thanks KFIAT, your indicantions works fine for me.

The error in the VMWare ESX 3.5.0 is shown in the image