ESXi 4.1 is not recognizing LUN from SAN..after upgrade from ESX 4.0

[Shakeeb20111014]

I'm having problem in accessing SAN Storage on my ESXi host after upgrading. I can see the storage on server in Storage Adapter and also its showing it when using [fdisk -l]. and it is also available when i m using Add Storage.

But i cannt access the old vm's already residing on that storage. since its not mounting the old volumes.

need help to access previous volumes.

[a_p_]

Does the VMFS partition show up with the correct partition type "FB" when running fdisk -lu?

It might be possible that the LUN has been detected as a snapshot LUN. In this case take a look at http://kb.vmware.com/kb/1011387 for how to force-mount and/or resignature the datastore. Make sure you fully understand this part before trying to do this, to prevent from possible data loss!

André

[Shakeeb20111014]

The storage is not showing any partitions on SAN Storage. snapshot is attach for reference.

Secondly the command esxcfg-volume -l is not giving me anything on CLI. I assume that it means there are no snapshot volumes exists.

[a_p_]

This doesn't look very good.

Depending on the importance of the data on this datastore, it's up to you to decide whether to call VMware support or try to recover the partition table by yourself as documented in http://kb.vmware.com/kb/1002281.

André

[Shakeeb20111014]

thanks for the help André.

following the documentation to recover partition is risky.

just hoping to get any help that can give me some info how to tackle this issue.

I'm getting these messages on /var/log/messages

Aug 21 12:34:01 vmkernel: 0:01:03:30.562 cpu13:14559)usb-storage: detected SCSI revision number 0 on vmhba32
Aug 21 12:34:01 vmkernel: 0:01:03:30.562 cpu13:14559)usb-storage: patching inquiry data to change SCSI revision number from 0 to 2 on vmhba32
Aug 21 12:34:01 vmkernel: 0:01:03:30.562 cpu3:5950)ScsiScan: 1059: Path 'vmhba32:C0:T0:L0': Vendor: 'HL-DT-ST'  Model: 'DVDRAM GSA-T50N '  Rev: 'RY05'
Aug 21 12:34:01 vmkernel: 0:01:03:30.562 cpu3:5950)ScsiScan: 1062: Path 'vmhba32:C0:T0:L0': Type: 0x5, ANSI rev: 2, TPGS: 0 (none)
Aug 21 12:34:01 vmkernel: 0:01:03:30.562 cpu3:5950)ScsiUid: 273: Path 'vmhba32:C0:T0:L0' does not support VPD Device Id page.
Aug 21 12:34:01 vmkernel: 0:01:03:30.562 cpu3:5950)VMWARE SCSI Id: Could not get disk id for vmhba32:C0:T0:L0
Aug 21 12:34:01 Hostd: [2011-08-21 12:34:01.156 27E40B90 verbose 'StorageSystem' opID=19042780-00001836-9a] SendStorageInfoEvent() called
Aug 21 12:34:01 Hostd: [2011-08-21 12:34:01.156 27E40B90 verbose 'Hostsvc::DatastoreSystem' opID=19042780-00001836-9a] ReconcileVMFSDatastores called: refresh = true, rescan = false
Aug 21 12:34:01 Hostd: [2011-08-21 12:34:01.156 27E40B90 verbose 'FSVolumeProvider' opID=19042780-00001836-9a] RefreshVMFSVolumes called
Aug 21 12:34:01 vmkernel: 0:01:03:30.593 cpu13:14559)NMP: nmp_CompleteCommandForPath: Command 0x12 (0x4102bfa28240) to NMP device "mpx.vmhba32:C0:T0:L0" failed on physical path "vmhba32:C0:T0:L0" H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x24 0x0.
Aug 21 12:34:01 vmkernel: 0:01:03:30.593 cpu13:14559)ScsiDeviceIO: 1672: Command 0x12 to device "mpx.vmhba32:C0:T0:L0" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x24 0x0.

[a_p_]

You are absolutely right, it's risky. That's why I mentioned VMware Support. They should be able to interpret the error codes correctly and help recover the data. What you may want to do in any case - assuming you have enough free space on your storage system - is to create a clone of the LUN.

André

[AureusStone]

Seems like my post didn't go through.

I am guessing you are using IBM hardware from your screenshots.

Have a look at

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=103026...

Could very well be the cause of your issue.  I have lost a weekend resolving this issue before. 😕

[Shakeeb20111014]

Aureus,

          you are right we are using the IBM Hardware, and unfortunatly the article you provided didn't help me with my issue. Also it's been more than a week for me with this issue 😕

I've submitted the issue to vmware support, and waiting for their response.

[AureusStone]

Yes.  The article will not fix the issue, it should prevent it happening in the first place (assuming this is the issue).

I think you did the right thing by going to VMware support.  It may be worth getting your backups ready for a worst case scenario.

The process that was followed to fix my issues was LUN resignature, which worked for the majority of the LUNs.  A few LUN could not be resignatured so we had to create a new LUN and copy the data from the corrupt LUN.