ESX server does not see formatted storage

[fercho74]

Hello all,

I have a newly built ESX 3 server. The server does not see the formatted disks under storage. The server can see the storage when I go to "Storage (SCSI, SAN, and NFS)" and choose "Add Storage". But doing this wants to format the disks. These disks were already formatted by another ESX3 server and have data on them. Any ideas?

[nkrick]

Be sure all of the ESX servers are in the same

Storage Group in Navisphere.

If you look in my post, I state:

>> Currently, all 12 hosts and 9 LUNs are in the

>> same storage group

[chef95]

I am having a very similar problem. I have 4 3.x ESX, and 2 different storage arrays, a CX3-20 and a S400 from 3Par. I have created a LUN on EMC and successfully shared it out to all ESX servers. When I try the same thing on the 3Par, I have a problem. One ESX server can see it and mount it. All the others can see it, but don’t recognize it as a VMFS file system and want to format it. To get around the issue, I had to set LVM.DisallowSnapshotLun to 0 (at the advice of VMware tech support call). I still have an open case with them on this issue. The VMware guy said that lots of people where having this issue. As far as I am concerned, this is a workaround, not a solution and a problem with VMware.

On the 3Par LUN I have shared out LUN 40 to all the ESX servers. This is verified in the Virtual Infrastructure Client by looking at configuration, storage adapters, the LUN ID shows up as 40. As stated before, this can be confusing because on the array side the LUN ID unique, and the LUN is shared to multiple hosts, where on the VMware the LUN ID is what should be consistent.

[nkrick]

My problem was finally solved after working with VMware technical support. For some reason, the ESX servers that could not see the LUNs saw those LUNs as snapshot LUNs. This was due to a bad header in the lvminfo on the VMFS file systems. The fix was to extract the header (using dd), use a Hex editor to place the proper value in the header, and then place the new header on the file system (again using dd). VMware support took care of the Hex editing, I just had to send them the header and put the new header in place (they also sent me the commands to do it) .

VMware tried telling me that the only solution was to disable snapshot LUNs, but I refused to accept that as a solution. I told them exactly what you said, it is a workaround, not a fix.

The VMware Tech that solved the problem for me was Nathan Small, so if you are able to ask for him, he is familiar with the problem. He also put in a feature request for version 3.0.2 to add a maintenance utility to automate the process.

[peter_dgreat200]

I have exactly the same problem, would appreciate if you will post the commands you use to resolve this.

My SR has been for a month now but still not resolve.

[GBromage]

Actually, I'd suggest you shouldn't post the commands to do this.

Hex-editing the header on VMFS volumes that contain (potentially critical) data is not something that should be done lightly, and probably not without a VMWare support person talking you through it.

[kryichek]

Is HEX editing really the only fix? I have this problem now and have a open case.

[dach]

Hello all,

At RCJU we also have the same problem. We are trying to switch our virtual machines from a primary site to a backup site, our ESX servers are sharing a LUN and the same issue arises.

Disabling the shapshot capabilities seems to be a workaround that enables us to see and remount the LUNs on the backup site, but since it is critical for us to continue performing backups on our secondary site, the shapshot function is mandatory.

We'll open a ticket as everyone did here and tell you the status.

Regards,

Bruno Kerouanton

[Phil_White]

I just had this problem too. I set the LVM.DisallowSnapshotLun to 0, refreshed my storage and saw the storage. Then I set it back to 1 and I can still see the storage.