iSCSI problem

[rgore]

Hello

I currently have a VMWare ESXi 3.5 server linked to a QNAP TS-809U for storage

I have 3 iSCSI targets configured on the QNAP NAS and after a reboot, the ESXi server won't map 2 out of the 3 targets.

The first works fine, but I can't find the other ones.. When I go to add storage, the drives are seen there (2 1TB iSCSI Drives on the NAS) but if I were to map them, they would be erased.

I'd like to re-map them without destroying data if at all possible.

If I go to the SSH console and type fdisk -l, I can see all 3 iscsi drives there.

Any ideas?

Thanks

Richard

[kjb007]

Check in your ESXi logs to see if those LUNs that are not mapped are seen as snapshot LUNs.

If they are, then you'll either need to set the lvm.disallowsnapshotlun ESX Advanced Option to 0, or resignature those LUNs and rename the datastores.

-KjB

[rgore]

Ok, I found a few references in /var/log saying those 2 LUNS are snaphots:

Feb 28 17:06:57 vmkernel: 0:00:01:26.831 cpu0:1360)ScsiDevice: 3643: Adding Device "vml.02000000006001405293832b1d941ad4f42d93dbde695343534920" from Plugin "legacyMP", Device Type 0

Feb 28 17:06:57 vmkernel: 0:00:01:26.946 cpu0:1360)SCSI: 5498: Logical device vml.02000000006001405293832b1d941ad4f42d93dbde695343534920 for target vmhba32:0:0 was registered successfully.

Feb 28 17:06:57 vmkernel: 0:00:01:26.948 cpu0:1360)ScsiDevice: 3643: Adding Device "vml.02000000006001405bc91637ad332cd44dad9f67de695343534920" from Plugin "legacyMP", Device Type 0

Feb 28 17:06:57 vmkernel: 0:00:01:26.949 cpu0:1360)LVM: 5573: Device vml.02000000006001405bc91637ad332cd44dad9f67de695343534920:1 detected to be a snapshot:

Feb 28 17:06:57 vmkernel: 0:00:01:26.949 cpu0:1360)LVM: 5580:   queried disk ID: <type 2, len 22, lun 0, devType 0, scsi 6, h(id) 14267401975370591515>

Feb 28 17:06:57 vmkernel: 0:00:01:26.949 cpu0:1360)LVM: 5587:   on-disk disk ID: <type 2, len 22, lun 0, devType 0, scsi 6, h(id) 8588124369381020285>

Feb 28 17:06:57 vmkernel: 0:00:01:26.949 cpu0:1360)ALERT: LVM: 4476: vml.02000000006001405bc91637ad332cd44dad9f67de695343534920:1 may be snapshot: disabling access. See resignaturing section in SAN config gu

Feb 28 17:06:57 vmkernel: 0:00:01:26.953 cpu0:1360)SCSI: 5498: Logical device vml.02000000006001405bc91637ad332cd44dad9f67de695343534920 for target vmhba32:2:0 was registered successfully.

Feb 28 17:06:57 vmkernel: 0:00:01:26.954 cpu0:1360)ScsiDevice: 3643: Adding Device "vml.02000000006001405903ce194dd0dad418bda4b7df695343534920" from Plugin "legacyMP", Device Type 0

Feb 28 17:06:57 vmkernel: 0:00:01:26.956 cpu0:1360)LVM: 5573: Device vml.02000000006001405903ce194dd0dad418bda4b7df695343534920:1 detected to be a snapshot:

Feb 28 17:06:57 vmkernel: 0:00:01:26.956 cpu0:1360)LVM: 5580:   queried disk ID: <type 2, len 22, lun 0, devType 0, scsi 6, h(id) 3523604113744237517>

Feb 28 17:06:57 vmkernel: 0:00:01:26.956 cpu0:1360)LVM: 5587:   on-disk disk ID: <type 2, len 22, lun 0, devType 0, scsi 6, h(id) 2704013798079042520>

Feb 28 17:06:57 vmkernel: 0:00:01:26.956 cpu0:1360)ALERT: LVM: 4476: vml.02000000006001405903ce194dd0dad418bda4b7df695343534920:1 may be snapshot: disabling access. See resignaturing section in SAN config gu

Feb 28 17:06:57 vmkernel: 0:00:01:26.961 cpu0:1360)SCSI: 5498: Logical device vml.02000000006001405903ce194dd0dad418bda4b7df695343534920 for target vmhba32:4:0 was registered successfully.

Feb 28 17:06:57 vmkernel: 0:00:01:26.970 cpu0:1361)SCSI: 861: GetInfo for adapter vmhba32, [0x604ef80], max_vports=0, vports_inuse=0, linktype=0, state=0, failreason=0, rv=-1, sts=bad001f

The first one registers successfully, but the other 2 don't.

I'll try and look at resignaturing ... How do I set the lvm.disallowsnapshotlun ESX Advanced Option to 0 ?

Thanks a lot!

Richard

[rgore]

Ok, sorry about that, I looked a bit and found it.

Can you instead tell me a bit what could have caused the volume to become a "snapshot" and what it implies?

Thanks

Richard

[kjb007]

Use vi client to connect to ESX host.  Go to configuration tab, advanced settings, LVM, LVM.DisallowSnapshotLun to 0, and then rescan HBA.

-KjB

[kjb007 · Accepted solution]

snapshot LUN means that for some reason, could be the same LUN showing up as a different LUN id, the LUN signature beign calculated is not the same as the signature written to the LUN itself.  So, ESX disables access to the LUN, to avoid a conflict with a LUN, and it's mirror being attached to the same host.  In your case, the LUNs are different, but ESX thinks they are a mirror LUN instead.

The LVM.DisallowSnapshotLun will allow you to mount that "snapshot" lun by disabling the snapshot checking feature of ESX.

In that same configuration section,  you can instead use the Resignature option, which will resignature the LUN and create a new name for the datastore on that LUN, without destroying the data on that LUN.

-KjB

[rgore]

I switched the option to 0 and my LUNS are availalble again!

Thanks a lot for your help

One last question: is it a problem if I leave the option to 0? Could it generate problems in the long term?

Thanks!

Richard

[kjb007]

The long-term implication here is if you eventually do create a mirror LUN, and attach that mirror LUN to the same host that has access to the master LUN, then there could be possible data corruption, because you are not blocking that snapshot LUN from being made available to the ESX host.  So, you now have two datastores (one master and one mirror/snapshot) that both have the same name.

-KjB

[cmacmillan]

Richard,

Did you lose power to your Qnap with a volitile write cache? If so, that would explain your datastores being interpreted as snapshots of themselves.

[rgore]

No, I didn't

I shut down everything cleanly last friday night (The electricity company had to work this weekend) and I unplugged both the server and the NAS from the electrical outlet.

That configuration parameter fixed my main problem, but now others are appearing and I'm not sure what's happening...

Now the first LUN is gone ( I didn't have any problems wiht it up to now)... Really strange... Investigatiing