[ovirt-users] iSCSI Discovery cannot detetect LUN
Lukáš Kaplan
lkaplan at dragon.cz
Sun Apr 2 19:17:12 UTC 2017
I am using Centos 7 and tgtd (scsi-target-utils)
# cat /etc/centos-release
CentOS Linux release 7.3.1611 (Core)
# tgtd -V
1.0.55
# rpm -qi scsi-target-utils
Name : scsi-target-utils
Version : 1.0.55
Release : 4.el7
Architecture: x86_64
... etc....
--
Lukas Kaplan
2017-03-31 21:59 GMT+02:00 Yaniv Kaul <ykaul at redhat.com>:
>
>
> On Fri, Mar 31, 2017 at 3:43 PM, Lukáš Kaplan <lkaplan at dragon.cz> wrote:
>
>> I solved this issue now.
>>
>> I thought till today, that iSCSI LUN ID (WWN or WWID) is globaly unique.
>> It is not true!
>> If you power on two identical linux machines and create iSCSI target on
>> them, their LUN IDs will be same...
>>
>> 360000000000000000e00000000010001 - for first LUN
>> 360000000000000000e00000000010002 - for second LUN etc
>>
>
> How did you get to such a number with so many zero's? Usually, there's
> some vendor ID and so on there...
> What target are you using?
> Y.
>
>
>>
>> You have to change LUN ID manualy (and take care of that uniqueness in
>> your domain) in /etc/tgtd/targets.conf for example:
>>
>> <target iqn.2017-03.com.example.domain>
>> <backing-store /dev/md124>
>> scsi_id 00020001
>> </backing-store>
>> <backing-store /dev/md125>
>> scsi_id 00020002
>> </backing-store>
>> initiator-address 192.168.1.0/24
>> </target>
>>
>>
>>
>> --
>> Lukas Kaplan
>>
>>
>>
>> 2017-03-31 9:06 GMT+02:00 Lukáš Kaplan <lkaplan at dragon.cz>:
>>
>>> Is it possible that problem can be in conflicting LUN IDs?
>>> I see that first LUN from both storage servers have same LUN ID
>>> 360000000000000000e00000000010001. One storage server is connected to
>>> ovirt and second is not connected because of described problem (ovirt dont
>>> show lun after login and discovery).
>>>
>>> I am using tgtd as iscsi target server on both servers. Both have same
>>> configuration (same disks, md raid6), but different iqn and ip address...
>>>
>>> --
>>> Lukas Kaplan
>>>
>>> Dragon Internet a.s.
>>>
>>
>>
>>> 2017-03-29 12:12 GMT+02:00 Liron Aravot <laravot at redhat.com>:
>>>
>>>>
>>>>
>>>> On Wed, Mar 29, 2017 at 12:59 PM, Eduardo Mayoral <emayoral at arsys.es>
>>>> wrote:
>>>>
>>>>> I had a similar problem, in my case this was related to multipath, it
>>>>> was not masking the LUNs correctly, it was seeing it multiple times (one
>>>>> per path), and I could not select the LUNs in the oVirt interface.
>>>>>
>>>>> Once I configured multipath correctly, everything worked like a charm.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> --
>>>>>
>>>>> Eduardo Mayoral.
>>>>>
>>>>> On 29/03/17 11:30, Lukáš Kaplan wrote:
>>>>>
>>>>> Hello all,
>>>>>
>>>>> I did all steps as I described in previous email, but no change. I
>>>>> can't see any LUN after discovery and login of new iSCSI storage.
>>>>> (That storage is ok, if I try to connect it to another and older ovirt
>>>>> domain, it is working...)
>>>>>
>>>>> I tryed it on 3 new iSCSI targets alredy, all have same problem...
>>>>>
>>>>> Can somebody help me, please?
>>>>>
>>>>> --
>>>>> Lukas Kaplan
>>>>>
>>>>>
>>>> Hi Lukas,
>>>> If you try to perform the discovery yourself, do you see the luns?
>>>>
>>>>>
>>>>>
>>>>> 2017-03-27 16:22 GMT+02:00 Lukáš Kaplan <lkaplan at dragon.cz>:
>>>>>
>>>>>> I did following steps:
>>>>>>
>>>>>> - delete target on all initiators (ovirt nodes)
>>>>>> iscsiadm -m node -T iqn.2017-03.cz.dragon.ovirt.fuvs-sn1:10T -p
>>>>>> 10.53.1.201:3260 -u
>>>>>> iscsiadm -m node -T iqn.2017-03.cz.dragon.ovirt.fuvs-sn1:10T -p
>>>>>> 10.53.1.201:3260 -o delete
>>>>>>
>>>>>> - stop tgtd on target
>>>>>> - fill storage by zeroes (dd if=/dev/zero of=/dev/md125 bs=4096
>>>>>> status=progress)
>>>>>> - start tgtd
>>>>>> - tried to connect to ovirt (Discovery=ok, Login=ok, but can not see
>>>>>> any LUN).
>>>>>>
>>>>>> === After that I ran this commands on one node: ===
>>>>>>
>>>>>> [root at fudi-cn1 ~]# iscsiadm -m session -o show
>>>>>> tcp: [1] 10.53.0.10:3260,1 iqn.2017-03.cz.dragon.ovirt:ovirtengine
>>>>>> (non-flash)
>>>>>> tcp: [11] 10.53.0.201:3260,1 iqn.2017-03.cz.dragon.ovirt.fudi-sn1:10T
>>>>>> (non-flash)
>>>>>> tcp: [12] 10.53.1.201:3260,1 iqn.2017-03.cz.dragon.ovirt.fuvs-sn1:10T
>>>>>> (non-flash)
>>>>>>
>>>>>> [root at fudi-cn1 ~]# iscsiadm -m discoverydb -P1
>>>>>> SENDTARGETS:
>>>>>> DiscoveryAddress: 10.53.0.201,3260
>>>>>> Target: iqn.2017-03.cz.dragon.ovirt:ovirtengine
>>>>>> Portal: 10.53.0.201:3260,1
>>>>>> Iface Name: default
>>>>>> iSNS:
>>>>>> No targets found.
>>>>>> STATIC:
>>>>>> Target: iqn.2017-03.cz.dragon.ovirt.fuvs-sn1:10T
>>>>>> Portal: 10.53.1.201:3260,1
>>>>>> Iface Name: default
>>>>>> Target: iqn.2017-03.cz.dragon.ovirt:ovirtengine
>>>>>> Portal: 10.53.0.10:3260,1
>>>>>> Iface Name: default
>>>>>> Target: iqn.2017-03.cz.dragon.ovirt.fudi-sn1:10T
>>>>>> Portal: 10.53.0.201:3260,1
>>>>>> Iface Name: default
>>>>>> FIRMWARE:
>>>>>> No targets found.
>>>>>>
>>>>>> === On iscsi target: ===
>>>>>> [root at fuvs-sn1 ~]# cat /proc/mdstat
>>>>>> Personalities : [raid1] [raid6] [raid5] [raid4]
>>>>>> md125 : active raid6 sdl1[11] sdk1[10] sdj1[9] sdi1[8] sdh1[7]
>>>>>> sdg1[6] sdf1[5] sde1[4] sdd1[3] sdc1[2] sdb1[1] sda1[0]
>>>>>> 9766302720 blocks super 1.2 level 6, 512k chunk, algorithm 2
>>>>>> [12/12] [UUUUUUUUUUUU]
>>>>>> bitmap: 0/8 pages [0KB], 65536KB chunk
>>>>>> ...etc...
>>>>>>
>>>>>>
>>>>>> [root at fuvs-sn1 ~]# cat /etc/tgt/targets.conf
>>>>>> default-driver iscsi
>>>>>>
>>>>>> <target iqn.2017-03.cz.dragon.ovirt.fuvs-sn1:10T>
>>>>>> # provided devicce as a iSCSI target
>>>>>> backing-store /dev/md125
>>>>>> # iSCSI Initiator's IP address you allow to connect
>>>>>> #initiator-address 10.53.0.0/23
>>>>>> </target>
>>>>>>
>>>>>> --
>>>>>> Lukas Kaplan
>>>>>>
>>>>>> 2017-03-25 12:36 GMT+01:00 Lukas Kaplan <lkaplan at dragon.cz>:
>>>>>>
>>>>>>> Co muze myslet tim mappingem?
>>>>>>>
>>>>>>> Jinak muzu zkusit ddckem celou storage prepsat nulami.
>>>>>>>
>>>>>>> co ty na to?
>>>>>>>
>>>>>>> Odesláno z iPhonu
>>>>>>>
>>>>>>> Začátek přeposílané zprávy:
>>>>>>>
>>>>>>> *Od:* Yaniv Kaul <ykaul at redhat.com>
>>>>>>> *Datum:* 24. března 2017 23:25:21 SEČ
>>>>>>> *Komu:* Lukáš Kaplan <lkaplan at dragon.cz>
>>>>>>> *Kopie:* users <users at ovirt.org>
>>>>>>> *Předmět:* *Re: [ovirt-users] iSCSI Discovery cannot detetect LUN*
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Mar 24, 2017 at 1:34 PM, Lukáš Kaplan <lkaplan at dragon.cz>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hello all,
>>>>>>>>
>>>>>>>> please do you have some experience with troubleshooting adding of
>>>>>>>> iSCSI domain to ovirt 4.1.1?
>>>>>>>>
>>>>>>>> I am chalenging this issue now:
>>>>>>>>
>>>>>>>> 1) I have successfuly installed oVirt 4.1.1 environment with
>>>>>>>> self-hosted engine, 3 nodes and 3 storages (iSCSI Master domain, iSCSI for
>>>>>>>> hosted engine and NFS ISO domain). Everything is working now.
>>>>>>>>
>>>>>>>> 2) But, when I want to add new iSCSI domain, I can discover it, I
>>>>>>>> can login, but I cant see any LUN on that storage. (I had same problem in
>>>>>>>> oVirt 4.1.0, so I made upgrade to 4.1.1)
>>>>>>>>
>>>>>>>
>>>>>>> Are you sure mappings are correct?
>>>>>>> Can you ensure the LUN is empty?
>>>>>>> Y.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> 3) Then I tryed to add this storage to another oVirt environment
>>>>>>>> (oVirt 3.6) and there are no problem. I can see LUN on that storage and I
>>>>>>>> can connect it to oVirt.
>>>>>>>>
>>>>>>>> I tryed to examine vdsm.log, but it is very detailed and unredable
>>>>>>>> for me :-/
>>>>>>>>
>>>>>>>> Thak you in advance, have a nice day,
>>>>>>>> --
>>>>>>>> Lukas Kaplan
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Users mailing list
>>>>>>>> Users at ovirt.org
>>>>>>>> http://lists.ovirt.org/mailman/listinfo/users
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing listUsers at ovirt.orghttp://lists.ovirt.org/mailman/listinfo/users
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/users
>>>>>
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20170402/b3722388/attachment-0001.html>
More information about the Users
mailing list