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?

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?

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

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

Thanks, C

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

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.

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