I try to fix a 6tb iscsi volume with VMFS 5
when I first started to look into it the partition table and the area where the magic number is located were completely wiped blank.
I got as far as that the volume is now detected as snapshot but something is still wrong.
Here are some hints in the esxi kernel log:
2012-11-10T19:37:31.668Z cpu0:4003)WARNING: iscsi_vmk: iscsivmk_StartConnection: Sess [ISID: 00023d000001 TARGET: iqn.2012.RMnet-6tera TPGT: 1 TSIH: 0]
2012-11-10T19:37:31.668Z cpu0:4003)WARNING: iscsi_vmk: iscsivmk_StartConnection: Conn [CID: 0 L: 82.145.100.32:63478 R: 82.145.100.116:3260]
2012-11-10T19:37:32.159Z cpu0:2965)ScsiScan: 888: Path 'vmhba33:C0:T0:L0': Vendor: 'SCST_FIO' Model: '6tera ' Rev: ' 300'
2012-11-10T19:37:32.159Z cpu0:2965)ScsiScan: 891: Path 'vmhba33:C0:T0:L0': Type: 0x0, ANSI rev: 6, TPGS: 0 (none)
2012-11-10T19:37:32.160Z cpu0:2965)ScsiScan: 1373: Add path: vmhba33:C0:T0:L0
2012-11-10T19:37:32.213Z cpu0:2965)ScsiPath: 4607: Plugin 'NMP' claimed path 'vmhba33:C0:T0:L0'
2012-11-10T19:37:32.213Z cpu0:2965)ScsiCore: 1483: Power-on Reset occurred on vmhba33:C0:T0:L0
2012-11-10T19:37:32.215Z cpu0:2965)vmw_psp_fixed: psp_fixedSelectPathToActivateInt:479: Changing active path from NONE to vmhba33:C0:T0:L0 for device "Unregistered Device".
2012-11-10T19:37:32.215Z cpu0:2965)StorageApdHandler: 692: APD Handle Created with lock[StorageApd0x410005]
2012-11-10T19:37:32.215Z cpu0:2965)ScsiEvents: 501: Event Subsystem: Device Events, Created!
2012-11-10T19:37:32.215Z cpu0:2965)VMWARE SCSI Id: Id for vmhba33:C0:T0:L0
0x36 0x36 0x36 0x36 0x36 0x74 0x65 0x72 0x61 0x20
2012-11-10T19:37:32.216Z cpu0:2965)ScsiDeviceIO: 5859: QErr is correctly set to 0x0 for device eui.363636362d363636.
2012-11-10T19:37:32.216Z cpu0:2965)ScsiDeviceIO: 6356: Could not detect setting of sitpua for device eui.363636362d363636. Error Not supported.
2012-11-10T19:37:32.218Z cpu0:2965)ScsiDevice: 3382: Successfully registered device "eui.363636362d363636" from plugin "NMP" of type 0
2012-11-10T19:37:32.219Z cpu0:2965)<3>ata2.00: bad CDB len=16, scsi_op=0x9e, max=12
2012-11-10T19:37:32.222Z cpu0:2965)<3>ata2.00: bad CDB len=16, scsi_op=0x9e, max=12
2012-11-10T19:37:32.223Z cpu0:2965)<3>ata2.00: bad CDB len=16, scsi_op=0x9e, max=12
2012-11-10T19:37:32.224Z cpu0:2965)<3>ata2.00: bad CDB len=16, scsi_op=0x9e, max=12
2012-11-10T19:37:32.225Z cpu0:2965)<3>ata2.00: bad CDB len=16, scsi_op=0x9e, max=12
2012-11-10T19:37:32.226Z cpu0:2965)<3>ata2.00: bad CDB len=16, scsi_op=0x9e, max=12
2012-11-10T19:37:32.227Z cpu0:2965)<3>ata2.00: bad CDB len=16, scsi_op=0x9e, max=12
2012-11-10T19:37:32.227Z cpu0:2965)<3>ata2.00: bad CDB len=16, scsi_op=0x9e, max=12
2012-11-10T19:37:32.228Z cpu0:2965)FSS: 4972: No FS driver claimed device 'mpx.vmhba32:C0:T0:L0': Not supported
2012-11-10T19:37:32.228Z cpu0:2965)Vol3: 692: Couldn't read volume header from control: Not supported
2012-11-10T19:37:32.228Z cpu0:2965)Vol3: 692: Couldn't read volume header from control: Not supported
2012-11-10T19:37:32.228Z cpu0:2965)FSS: 4972: No FS driver claimed device 'control': Not supported
2012-11-10T19:37:32.228Z cpu0:2965)VC: 1547: Device rescan time 3 msec (total number of devices 2)
2012-11-10T19:37:32.228Z cpu0:2965)VC: 1550: Filesystem probe time 5 msec (devices probed 2 of 2)
any suggestions ?
Thanks Ulli
does anybody know what
bad CDB len=16, scsi_op=0x9e, max=12
means - or how that can be fixed ?
Not sure if this will help, but have a look at this thread (same errors);
http://communities.vmware.com/thread/391937
thanks for that link - the errors look really similar - but in this case it can not be a hardware problem as the device had worked before
Not related to the specific error message, but is a KB article related to LUN's detected as snapshots (I'm clutching at straws here ) ;
Cheers,
Jon
I tried to force mount using the VMFS-volume-label but ESXi says it does not have a volume with that Label.
As the area where the label is referenced was wiped blank I had to fix that section - and in hexdump it looks ok.
I only know that CDB stands for Command Descriptor Block (SCSI) ... And that scsi_op is the operation code ... Don't know off-hand what 0x9e is though
Hmm - the original damaged 6 TB LUN was connected via iSCSI.
I recreated the headers using a virtual ESXi with a 6TB vmdk connected to a LSI-scsi-controller inside the VM.
Maybe I need to use iSCSI as well .... ???
To follow up ... Apperently 0x9e should be "SERVICE ACTION IN (16)"
It's expecting a length of 12 where it sees 16 ... But how to solve it ... It might be helpfull to configure it as iSCSI yes, I think that is the size that iSCSI uses ... But don't quote me on that