VMware Communities: may be snapshot: disabling access. See resignaturing section in SAN

Up to Discussions in VI: ESX 3.5

This Question is Possibly Answered

1 "correct" answer available (10 pts) 2 "helpful" answers available (6 pts)

1 2 Previous Next

19 Replies Last post: May 15, 2009 6:28 AM by AdrianWells

may be snapshot: disabling access. See resignaturing section in SAN config

Feb 19, 2007 1:28 AM

casy 4 posts since
Mar 25, 2005

After bios upgrade of the Perc 4 e/DI controller of a Dell 2850 I got the next message on the VMware console:

cpu2:1034)LVM: ProbeDeviceInt:4903: vmhab0:0:0:3 may be snapshot: disabling access. See resignaturing section in SAN config guide

Now this is a local disk, not a SAN disk. I lost the local VM data store which was VMFS3. Rescan didn't work and under /vmfs/volumes is was gone, so I finally did end with the SAN configuration guide and used the resignaturing option under the advanced settings in the VC 2.0. I did see the datastore now and gave it an snapshot datastore 2 name. I renamed it and all the data was there. Registered the VM again and all is running now.

Does this happens ofter? I couldn't find this problem with local disks on this group.

Reply Re: may be snapshot: disabling access. See resignaturing section in SAN config Feb 19, 2007 1:56 AM

christianZ 2,212 posts since
Apr 21, 2006

I had it too (2 hosts, pe6850 with perc4/i) - that was a bug and the upgrade of fw wasn't preferred - but I saw problems before upgrade too -
warnings about creating disk id - now the warnings go away.

Reply Re: may be snapshot: disabling access. See resignaturing section in SAN config Feb 19, 2007 2:01 AM

conyards 473 posts since
Sep 22, 2006

I've not heard of this before.

Somewhere along the line the ESX hosts has lost this VMFS3 volume and picked it up on a different path, vmhba0:0:0:3 (I'd bet it had been running on a path other then this before it was lost). When you've rescanned the host has picked up the VMFS3 on the different path, but importantly kept information about this partition at it's previous path. This is why it's decided it's looking at a Snapshot, and responded in this manner.

Alothough you've got around this now, another method of picking up the VMFS3 would have been to changed the advanced setting LVM/ LVM.DisallowSnapshotLun to 0.

Under what cicumstances did the Local VMFS3 become lost?

Reply Re: may be snapshot: disabling access. See resignaturing section in SAN config Feb 19, 2007 2:06 AM

in response to: conyards

christianZ 2,212 posts since
Apr 21, 2006

... by me after fw upgrade on raid controller perc4e/i (on board scsi) - on 2 servers.

And saw this:
http://www.vmware.com/community/thread.jspa?threadID=70640

Reply Re: may be snapshot: disabling access. See resignaturing section in SAN config Feb 19, 2007 4:25 AM

in response to: christianZ

hegars 24 posts since
Jan 17, 2006

I have had this problem with SAN attached vmfs3 vols previously when running esx v3.0.0. We had 3 esx servers attached. The problem did not manifest until each server was rebooted. Up until the poijt of reboot, access was fine. Each ESX needed to be upgraded to ESX v3.0.1 and also we had to set the "DisallowSnapshotLUN" setting to "0".

This resolved the problem at the time .....

Now we have the same issue on another set of clustered ESX v3.0.0 servers. The other servers are accessing the SAN vmfs vol fine, but the one server that we rebooted cannot access it, even after upgrading and setting the DisallowSnapshotLUN in LVM to 0.

We can work around it by deploying new VM's on the other ESX servers and pointing at the shared vmdk files ... but my question now is .... "Does each ESX server need to be upgraded to v3.0.1 and set the DisallowSnapShotLUN setting before that SAN VMFS volume becomes available again?

Has something been set on that device itself that cannot be cleared until all of the ESX servers are set the same?

Reply Re: may be snapshot: disabling access. See resignaturing section in SAN config Feb 20, 2007 4:04 AM

in response to: conyards

casy 4 posts since
Mar 25, 2005

Sorry, I didn't look at it yesterday. The VM data storage was lost after the upgrade of Perc 4 e/DI to 522A. After the startup the datastore was lost.
The paths where wrong so I changed them back. That didn't help so the resignaturing settings did the trick. He gave it a name which is starting with snapshot..... He gave it a (3) at the end so he did know there was originally an storage2 (2) what wasn't there anymore. After a rename the datastore was back online.

One problem left however. The VM on the datastore was a test from the vmwareconverter what was an XP desktop. Is wasn't registered anymore so I create a new VM with existing disk. The SCSI controller was LSI so I did define that, however VMware thinks is is an BUS logic and want to change it every time you start it up. How can I avoid this once and for all because it really should be a LSI. The buslogic ends with a blue screen.

Reply Re: may be snapshot: disabling access. See resignaturing section in SAN config Mar 6, 2007 3:50 AM

in response to: hegars

hegars 24 posts since
Jan 17, 2006

We had our problem fixed by support eventually ... the problem was with the partition information being wiped on the SAN based vmfs3 volume.

Once we had agreed that the problem was NOT the snapshot issue, the fix was quick and easy. Although we do not know HOW this information was wiped from the volume, as nothing had been done/touched on the servers, support fixed it immediately.

The problem bore all the hallmarks of the snapshot issue, but turned out to be the partition info being wiped

Just thought I'd update y'all

Reply Re: may be snapshot: disabling access. See resignaturing section in SAN config Mar 11, 2007 12:25 PM

in response to: casy

RParker 4,828 posts since
Dec 6, 2006

Guys, could you please post the steps of how you "resignature". I have the same exact problem.

Please let me know. Thank you.

Reply Re: may be snapshot: disabling access. See resignaturing section in SAN config Mar 13, 2007 11:44 AM

in response to: RParker

caro 66 posts since
Oct 16, 2003

I've got a similar problem and would love to know the steps you took to fix.

Thanks, C

Reply Re: may be snapshot: disabling access. See resignaturing section in SAN config Mar 13, 2007 11:57 AM

in response to: caro

RParker 4,828 posts since
Dec 6, 2006

Well, basically I went into the console, click on Configuration / Advanced Settings.

Click on LVM -> LVM.DissallowLVMSnapshot 0 -> LVM.EnableResignature 1

Then click OK to apply settings.

Click on "storage adapters" and click the "rescan" button (upper right). That should let you see the volume again.

Right click the vmhba (under the controller adapter for your machine) and click "rescan".

Then the volume should be visible.

Then when you go to the summary tab, you right click and click "refresh" and you should see your storage1 volume (or whatever you changed it to).

NOTE: I had 2 servers in this state. 1 worked the other did not. I spent 22 hours desperately trying to get this server backup. Thank the byte lord that the first server was more critical and that worked. The other server, I didn't have much luck, a little work for me.. but at least I got the more important server to work.

Reply Re: may be snapshot: disabling access. See resignaturing section in SAN config Aug 13, 2007 5:51 AM

in response to: RParker

IB_IT 420 posts since
May 31, 2007

Hey all,
sorry to revive this dead post, but I have this exact problem with my Dell PE 2950's after I upgraded the Perc/4i firmware from version 521X to 522A. Dell has put out an "urgent" firmware update that fixes this issue...version 522D, so I will be applying this to my environment. Note the release notes as you still my need to resignature your drives in VMWare...
http://support.dell.com/support/downloads/download.aspx?c=us&l=en&s=gen&releaseid=R151922&SystemID=PWE_2950&servicetag=&os=WNET&osl=en&deviceid=6315&devlib=0&typecnt=0&vercnt=2&catid=-1&impid=-1&formatcnt=5&libid=35&fileid=202404

Reply Re: may be snapshot: disabling access. See resignaturing section in SAN config Aug 13, 2007 12:18 PM

in response to: IB_IT

doctormiru 112 posts since
Mar 30, 2006

Hi
this behavior can also be called as a "feature". We're using mirroring for all our VMFS LUNs on SAN side. If the esx server regognizes a LUN that does appear to be on a different storage unit (in your case the same controller with another FW) ESX protects from data overwriting marking this LUN as a snapshot. In mirrored SAN environments it's quiet a must to enable resignaturing, because access to the mirror will be denied otherwise.

If you're pretty sure

that it's the same LUN you can enabling the LVM resignaturing option to access the "new" LUN. Just be aware that if you have VMs with vmdk files split across different LUNS ther is a hardcoded reference in the config files of the VMs to those disks. You have then to edit the config files and point to the "new" datastore.

regards

Michael

Reply Re: may be snapshot: disabling access. See resignaturing section in SAN config Aug 29, 2007 2:39 PM

in response to: RParker

IB_IT 420 posts since
May 31, 2007

FYI to anyone interested,
I have upgraded my Dell servers Perc 4 fw to 522D with no issues. I did not even have to resignature my local SCSI drives...just a quick refresh in VC client and I was good to go. To anyone else having this issue, the VMWare tech note #1001577 is a little unclear in its chart. If your server shipped with 522A firmware and you then installed ESX server and experienced this issue, then you will need to resignature your local drives. If you started out at fw version 521X or lower like I did and then upgraded to 522A...and THEN finally upgraded to the new 522D firmware you should not have to do any resignaturing.

Reply Re: may be snapshot: disabling access. See resignaturing section in SAN config Mar 17, 2008 2:33 PM

in response to: RParker

jasonboche 5,846 posts since
Jan 7, 2004 Moderator

RParker wrote:
Well, basically I went into the console, click on Configuration / Advanced Settings.

Click on LVM -> LVM.DissallowLVMSnapshot 0 -> LVM.EnableResignature 1

Then click OK to apply settings.

Click on "storage adapters" and click the "rescan" button (upper right). That should let you see the volume again.

Right click the vmhba (under the controller adapter for your machine) and click "rescan".

Then the volume should be visible.

Then when you go to the summary tab, you right click and click "refresh" and you should see your storage1 volume (or whatever you changed it to).

NOTE: I had 2 servers in this state. 1 worked the other did not. I spent 22 hours desperately trying to get this server backup. Thank the byte lord that the first server was more critical and that worked. The other server, I didn't have much luck, a little work for me.. but at least I got the more important server to work.

I ran into this upgrading from ESX 3.0.x to ESX 3.5.0. The hosts had been and continue to use an MSA1500 Active/Active SAN.

So then do you you leave the host settings at Click on LVM -> LVM.DissallowLVMSnapshot 0 -> LVM.EnableResignature 1 ?

Or do they get changed back at some point?

The problem I have now is that different ESX hosts see the data stores as different names. The datastore names can not be made identical in virtualcenter because that causes a unique name conflict.

I've got a mess on my hands right now. Good thing it's in the lab and not production. I want to be prepared though if this happens during my DEV/PROD upgrade.

Jason Boche
VMware Communities User Moderator

Reply Re: may be snapshot: disabling access. See resignaturing section in SAN config Apr 15, 2008 3:46 AM

in response to: jasonboche

BrianRTS 136 posts since
Jan 8, 2005

Do I need to reboot the host after making the LVM/resignaturing change in VIC?

1 2 Previous Next

Actions

View as PDF

Up to Discussions in VI: ESX 3.5

This Question is Possibly Answered

may be snapshot: disabling access. See resignaturing section in SAN config

Feb 19, 2007 1:28 AM

Actions

Incoming Links