[ovirt-users] iSCSI Discovery cannot detetect LUN
Kevin Goldblatt
kgoldbla at redhat.com
Wed Mar 29 11:13:13 UTC 2017
Hi Eduardo,
You say that the same iscsi storage works on another system? Are you using
different hosts there?
If so you need to check that the problematic systems host iqn is correctly
mapped in the storage provider:
Please check you current hosts and ensure that
/etc/iscsi/initiatorname.iscsi is the same as the one you defined in the
storage provider:
e.g.
cat cat /etc/iscsi/initiatorname.iscsi
InitiatorName=iqn.1994-05.com.mycorp:myhostname-vdsa
So then the iqn in the storage provider should also be:
iqn.1994-05.com.mycorp:myhostname-vdsa
After that reboot the host and rescan with the iscsiadm tool if needed
Regards,
Kevin
On Wed, Mar 29, 2017 at 1:12 PM, Liron Aravot <laravot at redhat.com> wrote:
>
>
> 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/20170329/d8116c1e/attachment-0001.html>
More information about the Users
mailing list