VMware Cloud Community
casy
Contributor
Contributor

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

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.

0 Kudos
19 Replies
christianZ
Champion
Champion

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.

0 Kudos
conyards
Expert
Expert

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?

https://virtual-simon.co.uk/
0 Kudos
christianZ
Champion
Champion

... 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

0 Kudos
hegars
Contributor
Contributor

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?

0 Kudos
casy
Contributor
Contributor

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.

0 Kudos
hegars
Contributor
Contributor

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 Smiley Happy

0 Kudos
RParker
Immortal
Immortal

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

Please let me know. Thank you.

0 Kudos
caro
Contributor
Contributor

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

Thanks, C

0 Kudos
RParker
Immortal
Immortal

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.

0 Kudos
IB_IT
Expert
Expert

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=P...

0 Kudos
doctormiru
Enthusiast
Enthusiast

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 Smiley Happy 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

0 Kudos
IB_IT
Expert
Expert

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.

0 Kudos
jasonboche
Immortal
Immortal

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.






[i]Jason Boche[/i]

[VMware Communities User Moderator|http://communities.vmware.com/docs/DOC-2444][/i]

VCDX3 #34, VCDX4, VCDX5, VCAP4-DCA #14, VCAP4-DCD #35, VCAP5-DCD, VCPx4, vEXPERTx4, MCSEx3, MCSAx2, MCP, CCAx2, A+
0 Kudos
BrianRTS
Enthusiast
Enthusiast

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

0 Kudos
larstr
Champion
Champion

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.

I just ran into this while updating from 3.5 to 3.5 Update 1. Quite scaring experience, but luckily, by doing the steps I found here I managed to access the LUN again. Smiley Happy

Lars

0 Kudos
chort
Contributor
Contributor

I've run into this same problem on a Dell PE 840 when installing the latest patches for ESXi 3.5 through the VIU. I did the resigning trick and got my datastore back, then I renamed the datastore, but it still can't find the VMs that were previously in the inventory--they all show up as unknown. As a test, I browsed the datastore and Imported one of the .vmx files to the inventory. It does appear, but it prompts me whether I moved or copied the VM (I said moved, it seemed to work OK).

Is there a way I can edit some config file so that it can find all the VMs again? It knows how many VMs I have, it just doesn't know where to find them. I've been poking around on the console (I enabled ssh access), but I can't seem to locate the config file that holds the inventory.

Thanks!

0 Kudos
Guest154
Contributor
Contributor

Glad I found this post I was seeing this error.

See resignaturing section in SAN config guide.

0:00:00:03.476 cup0:1032)LVM 4469: vmhba0:0:0:6 may be snapshot: disabling access. See resignaturing section in SAN config guide.

After following the directions things seem to be back on track for the most part. VM = The Big Adventure Smiley Happy Yippie-Ki-Yay.

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).

0 Kudos
bleedingedge
Contributor
Contributor

ive got a dellsc430 with local storage only, worked fine before my upgrade to update3 last night. now that i've upgrade cant get esx to see my local storage. read the post and tried flipping disallowsnapshot to 0 and lvm resig to 1 but after rescan still nothing shows - any other tricks or procedures to save my pre-update3 local vmfs partition?

0 Kudos
AdrianWells
Contributor
Contributor

Thank you to those that posted the helpful steps here. The steps outlined help to resolve an issue with local VMFS storage (on a ESX 3.5.0 server) not being visible after upgrading the firmware on Dell PowerEdge 2950 with a PERC 5/i RAID controller (the BIOS, BMC, and PERC were all upgraded at once).

It appears that after the re-signature process the local VMFS storage was re-named. In this case, this was not a big deal because there is no data stored here, however, it is neat to have everything back in its place after performing the firmware upgrade.

I realize this post is old, but I wonder the same question as jasonboche (quoted below). In my case, I manually returned the settings after following the steps outlined in this thread.

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?

0 Kudos