... may be snapshot: disabling access. See resignaturing ...URGENT!

[ascari]

Hi to all,

today i had a problem with my storage (MSA1500). I have two DL385G5 with esx 3.0.1 installed.

My storage configuration is with a LUN inside a few SATA disk and 5 LUN inside a few SCSI disk array. I had a failure on une SCSI I/O Module, and after replacement, all my drives were on line (from Array Configuration Utility) (SATA and SCSI)

After reboot of my two esx system i can see on SC this error:

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

From Storage Adapters i can see my LUN but i can't see it in Storage (SCSI SAN, NFS).

If i try to Add Storage i can see my LUN such was unformatted.

I have read some articles but i not understant what i need to do to fix this problem.

HELP!

Thank's Alberto

[joergriether]

wow, looks like your san just changed the identifier with the new controller module. that should never occur.

one possibility could be to temporaily enable resignaturing (advanced options/lvm) and see if the volume

is back there. But i hardly suggest to first open a support call with vmware as you may make it worse on your own.

best regards

joerg

[ascari]

my LUN identifier is always the same. I have replaced I/O module and i had put it in the same position. I think that i need to use enable resignaturing but i don't know the impact on my other LUN on SCSI drive. In this moment i have a critical VM running on it, and i can't stop MSA1500 controller again.

My question is: if i set to one, the enabiling resignature, and to zero the disallow snap, what's happen on other LUN?

Thank's again

Alberto

[joergriether]

IMO there shouldn´t be an impact on the other lun if setting enable resignaturing to one (that one setting should do the trick) and after that i would recommend a clone immediately but, again, i hardly suggest to first open a support call with vmware.

best regards

Joerg

[ctfoster]

A resignature will have an effect on VM's on on your lost volume in so far that they will unregistered will become "unknown" to ESX. As suggested its best to have support on the other end of the line while you go through this procedure.

[Nautilus]

Hi Alberto,

please read this one http://www.vmware-tsx.com/download.php?asset_id=49

AND

I dondt know why your ESX hosts is the opinion that this LUN is a snaphot (maybe different Host LUN IDs?) but for your Hosts is this LUN a Snapshot (is this correct or not ? it doesnt matter, your ESX hosts says this a snapshot). In the default parameter on an ESx host, when you connect a snapshot LUN to the host you can NOT see this LUN.

The are 2 reason why you connect a Snapshot lun to a host.

1. your original LUN is corrupt and you want to take the snapshot online

--> EnableResignature = 0

--> Disallowsnapshot = 0

2. one of the VMs on your VMFs is corrupt and you want connect the snapshot to the host ANS you want the original LUN still connected

--> EnableResignature = 0

Now you will see the LUN as snap0001_LUNName

Have a Nice Day

Mehmet

________________________________________________________________________________________________________________________________________________

If you found this or any other post helpful please consider the use of the Helpfull/Correct buttons to award points

[mike_laspina · Accepted solution]

Hi,

This sounds more like a SAN issue that a VMware issue. When an ESX server sees the UUID of a VMFS partition showing up on a different LUN ID the ESX server will disable access to the LUN in and effort to protect it.

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

This error reflects that same event.

You have not changed your ESX configuration so the issue must lie in the MSA and I would not mess with resignature until you are certain that the SAN LUN ID's are the same as before. Use the /etc/vmware/esx.conf file to find out where it expects the LUN ID's to be on.

If a Service Processor (SP) went down on the SAN check the SCSI ID of all mappings on the SAN to be sure they have not changed.

Your are well advised to seek the help of the VMware support team, they fix these issues all the time.