9:22 a.m.
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@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@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@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@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(a)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(a)redhat.com>
*Datum:* 24. března 2017 23:25:21 SEČ
*Komu:* Lukáš Kaplan <lkaplan(a)dragon.cz>
*Kopie:* users <users(a)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(a)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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
4:30 a.m.
New subject: iSCSI Discovery cannot detetect LUN
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
2017-03-27 16:22 GMT+02:00 Lukáš Kaplan <lkaplan(a)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@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@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@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@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(a)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(a)redhat.com>
> *Datum:* 24. března 2017 23:25:21 SEČ
> *Komu:* Lukáš Kaplan <lkaplan(a)dragon.cz>
> *Kopie:* users <users(a)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(a)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(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
>
4:59 a.m.
New subject: iSCSI Discovery cannot detetect LUN
This is a multi-part message in MIME format.
--------------8A7453E4F89AAABE5D73CCA3
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
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
2017-03-27 16:22 GMT+02:00 Lukáš Kaplan <lkaplan(a)dragon.cz
<mailto:lkaplan@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 <http://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 <http://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@fudi-cn1 ~]# iscsiadm -m session -o show
tcp: [1] 10.53.0.10:3260 <http://10.53.0.10:3260>,1
iqn.2017-03.cz.dragon.ovirt:ovirtengine (non-flash)
tcp: [11] 10.53.0.201:3260 <http://10.53.0.201:3260>,1
iqn.2017-03.cz.dragon.ovirt.fudi-sn1:10T (non-flash)
tcp: [12] 10.53.1.201:3260 <http://10.53.1.201:3260>,1
iqn.2017-03.cz.dragon.ovirt.fuvs-sn1:10T (non-flash)
[root@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 <http://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 <http://10.53.1.201:3260>,1
Iface Name: default
Target: iqn.2017-03.cz.dragon.ovirt:ovirtengine
Portal: 10.53.0.10:3260 <http://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 <http://10.53.0.201:3260>,1
Iface Name: default
FIRMWARE:
No targets found.
=== On iscsi target: ===
[root@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@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 <http://10.53.0.0/23>
</target>
--
Lukas Kaplan
2017-03-25 12:36 GMT+01:00 Lukas Kaplan <lkaplan(a)dragon.cz
<mailto:lkaplan@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(a)redhat.com <mailto:ykaul@redhat.com>>
> *Datum:* 24. března 2017 23:25:21 SEČ
> *Komu:* Lukáš Kaplan <lkaplan(a)dragon.cz
> <mailto:lkaplan@dragon.cz>>
> *Kopie:* users <users(a)ovirt.org <mailto:users@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(a)dragon.cz <mailto:lkaplan@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(a)ovirt.org <mailto:Users@ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/users
> <http://lists.ovirt.org/mailman/listinfo/users>
>
>
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
--------------8A7453E4F89AAABE5D73CCA3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=UTF-8"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>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.</p>
<p>Once I configured multipath correctly, everything worked like a
charm.</p>
<p>Best regards,</p>
<p>--</p>
<p>Eduardo Mayoral.<br>
</p>
<br>
<div class="moz-cite-prefix">On 29/03/17 11:30, Lukáš Kaplan
wrote:<br>
</div>
<blockquote
cite="mid:CAFsAhbmqzJj6CCfJWoskn0LXoPOBmCD6JpKLhmZCPUz51w7FHw@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<div dir="ltr">Hello all,
<div><br>
</div>
<div>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.</div>
<div>(That storage is ok, if I try to connect it to another and
older ovirt domain, it is working...)</div>
<div><br>
</div>
<div>I tryed it on 3 new iSCSI targets alredy, all have same
problem...</div>
<div><br>
</div>
<div>Can somebody help me, please?<br>
<div class="gmail_extra"><br clear="all">
<div>
<div class="gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>--<br>
Lukas Kaplan<br>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">2017-03-27 16:22 GMT+02:00 Lukáš
Kaplan <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:lkaplan@dragon.cz"
target="_blank">lkaplan@dragon.cz</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">I did following steps:
<div> </div>
<div> - delete target on all initiators (ovirt nodes)</div>
<div> iscsiadm -m node -T
iqn.2017-03.cz.dragon.ovirt.<wbr>fuvs-sn1:10T -p
<a moz-do-not-send="true"
href="http://10.53.1.201:3260"
target="_blank">10.53.1.201:3260</a>
-u</div>
<div> iscsiadm -m node -T
iqn.2017-03.cz.dragon.ovirt.<wbr>fuvs-sn1:10T -p
<a moz-do-not-send="true"
href="http://10.53.1.201:3260"
target="_blank">10.53.1.201:3260</a>
-o delete<br>
<div> </div>
<div> - stop tgtd on target</div>
<div> - fill storage by zeroes (dd if=/dev/zero
of=/dev/md125 bs=4096 status=progress)</div>
<div> - start tgtd</div>
<div> - tried to connect to ovirt (Discovery=ok,
Login=ok, but can not see any LUN).</div>
</div>
<div><br>
</div>
<div>=== After that I ran this commands on one node:
===</div>
<div><br>
</div>
<div>
<div>[root@fudi-cn1 ~]# iscsiadm -m session -o show</div>
<div>tcp: [1] <a moz-do-not-send="true"
href="http://10.53.0.10:3260"
target="_blank">10.53.0.10:3260</a>,1
iqn.2017-03.cz.dragon.ovirt:<wbr>ovirtengine
(non-flash)</div>
<div>tcp: [11] <a moz-do-not-send="true"
href="http://10.53.0.201:3260"
target="_blank">10.53.0.201:3260</a>,1
iqn.2017-03.cz.dragon.ovirt.<wbr>fudi-sn1:10T
(non-flash)</div>
<div>tcp: [12] <a moz-do-not-send="true"
href="http://10.53.1.201:3260"
target="_blank">10.53.1.201:3260</a>,1
iqn.2017-03.cz.dragon.ovirt.<wbr>fuvs-sn1:10T
(non-flash)</div>
</div>
<div><br>
</div>
<div>
<div>[root@fudi-cn1 ~]# iscsiadm -m discoverydb -P1</div>
<div>SENDTARGETS:</div>
<div>DiscoveryAddress: 10.53.0.201,3260</div>
<div>Target:
iqn.2017-03.cz.dragon.ovirt:<wbr>ovirtengine</div>
<div> Portal: <a moz-do-not-send="true"
href="http://10.53.0.201:3260"
target="_blank">10.53.0.201:3260</a>,1</div>
<div> Iface Name: default</div>
<div>iSNS:</div>
<div>No targets found.</div>
<div>STATIC:</div>
<div>Target:
iqn.2017-03.cz.dragon.ovirt.<wbr>fuvs-sn1:10T</div>
<div> Portal: <a moz-do-not-send="true"
href="http://10.53.1.201:3260"
target="_blank">10.53.1.201:3260</a>,1</div>
<div> Iface Name: default</div>
<div>Target:
iqn.2017-03.cz.dragon.ovirt:<wbr>ovirtengine</div>
<div> Portal: <a moz-do-not-send="true"
href="http://10.53.0.10:3260"
target="_blank">10.53.0.10:3260</a>,1</div>
<div> Iface Name: default</div>
<div>Target:
iqn.2017-03.cz.dragon.ovirt.<wbr>fudi-sn1:10T</div>
<div> Portal: <a moz-do-not-send="true"
href="http://10.53.0.201:3260"
target="_blank">10.53.0.201:3260</a>,1</div>
<div> Iface Name: default</div>
<div>FIRMWARE:</div>
<div>No targets found.</div>
</div>
<div><br>
</div>
<div class="gmail_extra">
<div class="gmail_extra">=== On iscsi target:
===</div>
<div class="gmail_extra">
<div class="gmail_extra">[root@fuvs-sn1 ~]# cat
/proc/mdstat </div>
<div class="gmail_extra">Personalities : [raid1]
[raid6] [raid5] [raid4] </div>
<div class="gmail_extra">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]</div>
<div class="gmail_extra"> 9766302720 blocks
super 1.2 level 6, 512k chunk, algorithm 2
[12/12] [UUUUUUUUUUUU]</div>
<div class="gmail_extra"> bitmap: 0/8 pages
[0KB], 65536KB chunk</div>
<div>...etc...</div>
</div>
<div>
<div><br>
</div>
<div><br>
</div>
<div>[root@fuvs-sn1 ~]# cat
/etc/tgt/targets.conf </div>
<div>default-driver iscsi<br>
</div>
<div><br>
</div>
<div><target
iqn.2017-03.cz.dragon.ovirt.<wbr>fuvs-sn1:10T><br>
</div>
<div> # provided devicce as a iSCSI target</div>
<div> backing-store /dev/md125</div>
<div> # iSCSI Initiator's IP address you
allow to connect</div>
<div> #initiator-address <a
moz-do-not-send="true"
href="http://10.53.0.0/23"
target="_blank">10.53.0.0/23</a></div>
<div></target></div>
</div>
<div>
<div><br>
</div>
</div>
<div>
<div
class="m_-8160082185690820700gmail-m_5377000683826010473gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>--<br>
Lukas Kaplan<br>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
<div>
<div class="h5">
<div class="gmail_quote">2017-03-25 12:36
GMT+01:00 Lukas Kaplan <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:lkaplan@dragon.cz"
target="_blank">lkaplan@dragon.cz</a>></span>:<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="auto">
<div>Co muze myslet tim mappingem?</div>
<div
id="m_-8160082185690820700gmail-m_5377000683826010473m_5120060402219677135AppleMailSignature"><br>
</div>
<div
id="m_-8160082185690820700gmail-m_5377000683826010473m_5120060402219677135AppleMailSignature">Jinak
muzu zkusit ddckem celou storage prepsat
nulami.</div>
<div
id="m_-8160082185690820700gmail-m_5377000683826010473m_5120060402219677135AppleMailSignature"><br>
</div>
<div
id="m_-8160082185690820700gmail-m_5377000683826010473m_5120060402219677135AppleMailSignature">co
ty na to?<br>
<br>
Odesláno z iPhonu</div>
<div><br>
Začátek přeposílané zprávy:<br>
<br>
</div>
<blockquote type="cite">
<div><b>Od:</b> Yaniv Kaul
<<a
moz-do-not-send="true"
href="mailto:ykaul@redhat.com"
target="_blank">ykaul(a)redhat.com</a>&gt;<br>
<b>Datum:</b> 24. března 2017 23:25:21
SEČ<br>
<b>Komu:</b> Lukáš Kaplan <<a
moz-do-not-send="true"
href="mailto:lkaplan@dragon.cz"
target="_blank">lkaplan(a)dragon.cz</a>&gt;<br>
<b>Kopie:</b> users <<a
moz-do-not-send="true"
href="mailto:users@ovirt.org"
target="_blank">users(a)ovirt.org</a>&gt;<br>
<b>Předmět:</b> <b>Re: [ovirt-users]
iSCSI Discovery cannot detetect
LUN</b><br>
<br>
</div>
</blockquote>
<blockquote type="cite">
<div>
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri,
Mar 24, 2017 at 1:34 PM, Lukáš
Kaplan <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:lkaplan@dragon.cz"
target="_blank">lkaplan(a)dragon.cz</a>&gt;</span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">Hello all,
<div><br>
</div>
<div>please do you have some
experience with
troubleshooting adding of
iSCSI domain to ovirt
4.1.1? </div>
<div><br>
</div>
<div>I am chalenging this
issue now:</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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)</div>
</div>
</blockquote>
<div><br>
</div>
<div>Are you sure mappings are
correct? </div>
<div>Can you ensure the LUN is
empty?</div>
<div>Y.</div>
<div> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>I tryed to examine
vdsm.log, but it is very
detailed and unredable for
me :-/</div>
<div><br>
</div>
<div>Thak you in advance,
have a nice day,<span
class="m_-8160082185690820700gmail-m_5377000683826010473HOEnZb"><font
color="#888888"><br
clear="all">
<div>
<div
class="m_-8160082185690820700gmail-m_5377000683826010473m_5120060402219677135m_2866670472223528587gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>--<br>
Lukas Kaplan<br>
<br>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</font></span></div>
</div>
<span
class="m_-8160082185690820700gmail-m_5377000683826010473HOEnZb"><font
color="#888888">
<br>
______________________________<wbr>_________________<br>
Users mailing list<br>
<a moz-do-not-send="true"
href="mailto:Users@ovirt.org"
target="_blank">Users(a)ovirt.org</a><br>
<a moz-do-not-send="true"
href="http://lists.ovirt.org/mailman/listinfo/users" rel="noreferrer"
target="_blank">http://lists.ovirt.org/mailman<wbr>/li...
<br>
</font></span></blockquote>
</div>
<span
class="m_-8160082185690820700gmail-m_5377000683826010473HOEnZb"><font
color="#888888"><br>
</font></span></div>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated"
href="mailto:Users@ovirt.org">Users@ovirt.org</a>
<a class="moz-txt-link-freetext"
href="http://lists.ovirt.org/mailman/listinfo/users">http://...
</pre>
</blockquote>
<br>
</body>
</html>
--------------8A7453E4F89AAABE5D73CCA3--
5:12 a.m.
New subject: iSCSI Discovery cannot detetect LUN
On Wed, Mar 29, 2017 at 12:59 PM, Eduardo Mayoral <emayoral(a)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(a)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@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@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@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@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(a)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(a)redhat.com>
>> *Datum:* 24. března 2017 23:25:21 SEČ
>> *Komu:* Lukáš Kaplan <lkaplan(a)dragon.cz>
>> *Kopie:* users <users(a)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(a)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(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users
>>>
>>>
>>
>
_______________________________________________
Users mailing listUsers@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
6:13 a.m.
New subject: iSCSI Discovery cannot detetect LUN
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(a)redhat.com> wrote:
On Wed, Mar 29, 2017 at 12:59 PM, Eduardo Mayoral <emayoral(a)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(a)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@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@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@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@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(a)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(a)redhat.com>
>>> *Datum:* 24. března 2017 23:25:21 SEČ
>>> *Komu:* Lukáš Kaplan <lkaplan(a)dragon.cz>
>>> *Kopie:* users <users(a)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(a)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(a)ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/users
>>>>
>>>>
>>>
>>
>
>
> _______________________________________________
> Users mailing listUsers@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/users
>
>
>
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
2:06 a.m.
New subject: iSCSI Discovery cannot detetect LUN
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...
--
Lukáš Kaplan
Dragon Internet a.s.
Pod Loretou 883
293 06 Kosmonosy
tel: +420 326 706 166
fax: +420 326 706 154
gsm: +420 736 736 346
web: http://www.dragon.cz
e-mail: lkaplan(a)dragon.cz
2017-03-29 12:12 GMT+02:00 Liron Aravot <laravot(a)redhat.com>:
On Wed, Mar 29, 2017 at 12:59 PM, Eduardo Mayoral <emayoral(a)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(a)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@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@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@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@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(a)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(a)redhat.com>
>>> *Datum:* 24. března 2017 23:25:21 SEČ
>>> *Komu:* Lukáš Kaplan <lkaplan(a)dragon.cz>
>>> *Kopie:* users <users(a)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(a)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(a)ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/users
>>>>
>>>>
>>>
>>
>
>
> _______________________________________________
> Users mailing listUsers@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/users
>
>
>
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
7:43 a.m.
New subject: iSCSI Discovery cannot detetect LUN
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
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(a)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(a)redhat.com>:
>
>
> On Wed, Mar 29, 2017 at 12:59 PM, Eduardo Mayoral <emayoral(a)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(a)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@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@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@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@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(a)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(a)redhat.com>
>>>> *Datum:* 24. března 2017 23:25:21 SEČ
>>>> *Komu:* Lukáš Kaplan <lkaplan(a)dragon.cz>
>>>> *Kopie:* users <users(a)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(a)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(a)ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/users
>>>>>
>>>>>
>>>>
>>>
>>
>>
>> _______________________________________________
>> Users mailing listUsers@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/users
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
>
2:59 p.m.
New subject: iSCSI Discovery cannot detetect LUN
On Fri, Mar 31, 2017 at 3:43 PM, Lukáš Kaplan <lkaplan(a)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(a)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(a)redhat.com>:
>
>>
>>
>> On Wed, Mar 29, 2017 at 12:59 PM, Eduardo Mayoral <emayoral(a)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(a)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@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@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@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@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(a)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(a)redhat.com>
>>>>> *Datum:* 24. března 2017 23:25:21 SEČ
>>>>> *Komu:* Lukáš Kaplan <lkaplan(a)dragon.cz>
>>>>> *Kopie:* users <users(a)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(a)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(a)ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/users
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing
listUsers@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/users
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users
>>>
>>>
>>
>
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
2:17 p.m.
New subject: iSCSI Discovery cannot detetect LUN
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(a)redhat.com>:
On Fri, Mar 31, 2017 at 3:43 PM, Lukáš Kaplan <lkaplan(a)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(a)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(a)redhat.com>:
>>
>>>
>>>
>>> On Wed, Mar 29, 2017 at 12:59 PM, Eduardo Mayoral <emayoral(a)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(a)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@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@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@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@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(a)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(a)redhat.com>
>>>>>> *Datum:* 24. března 2017 23:25:21 SEČ
>>>>>> *Komu:* Lukáš Kaplan <lkaplan(a)dragon.cz>
>>>>>> *Kopie:* users <users(a)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(a)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(a)ovirt.org
>>>>>>> http://lists.ovirt.org/mailman/listinfo/users
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing
listUsers@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/users
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users(a)ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/users
>>>>
>>>>
>>>
>>
>
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
5:05 a.m.
New subject: iSCSI Discovery cannot detetect LUN
On Sun, Apr 2, 2017 at 10:17 PM, Lukáš Kaplan <lkaplan(a)dragon.cz> wrote:
I am using Centos 7 and tgtd (scsi-target-utils)
Interesting - still doesn't explain it though. Certainly looks like some
tgtd issue (see http://www.spinics.net/lists/linux-stgt/msg04392.html for
example). Try changing the scsi_id in targets.conf perhaps?
I recommend, btw, targetcli (LIO) instead. Fairly simple to set up.
Y.
# 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(a)redhat.com>:
>
>
> On Fri, Mar 31, 2017 at 3:43 PM, Lukáš Kaplan <lkaplan(a)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(a)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(a)redhat.com>:
>>>
>>>>
>>>>
>>>> On Wed, Mar 29, 2017 at 12:59 PM, Eduardo Mayoral
<emayoral(a)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(a)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@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@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@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@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(a)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(a)redhat.com>
>>>>>>> *Datum:* 24. března 2017 23:25:21 SEČ
>>>>>>> *Komu:* Lukáš Kaplan <lkaplan(a)dragon.cz>
>>>>>>> *Kopie:* users <users(a)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(a)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(a)ovirt.org
>>>>>>>> http://lists.ovirt.org/mailman/listinfo/users
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing
listUsers@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/users
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users(a)ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/users
>>>>>
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Users mailing list
>> Users(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
>
5:36 a.m.
New subject: iSCSI Discovery cannot detetect LUN
Yes I agree. As I wrote in some previous message, scsi_id helped me.
For example:
cat /etc/targets.conf
<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-04-04 12:05 GMT+02:00 Yaniv Kaul <ykaul(a)redhat.com>:
On Sun, Apr 2, 2017 at 10:17 PM, Lukáš Kaplan <lkaplan(a)dragon.cz> wrote:
> I am using Centos 7 and tgtd (scsi-target-utils)
>
Interesting - still doesn't explain it though. Certainly looks like some
tgtd issue (see http://www.spinics.net/lists/linux-stgt/msg04392.html for
example). Try changing the scsi_id in targets.conf perhaps?
I recommend, btw, targetcli (LIO) instead. Fairly simple to set up.
Y.
>
> # 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(a)redhat.com>:
>
>>
>>
>> On Fri, Mar 31, 2017 at 3:43 PM, Lukáš Kaplan <lkaplan(a)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(a)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(a)redhat.com>:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Mar 29, 2017 at 12:59 PM, Eduardo Mayoral
<emayoral(a)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(a)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@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@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@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@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(a)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(a)redhat.com>
>>>>>>>> *Datum:* 24. března 2017 23:25:21 SEČ
>>>>>>>> *Komu:* Lukáš Kaplan <lkaplan(a)dragon.cz>
>>>>>>>> *Kopie:* users <users(a)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(a)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(a)ovirt.org
>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/users
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing
listUsers@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/users
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users(a)ovirt.org
>>>>>> http://lists.ovirt.org/mailman/listinfo/users
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users
>>>
>>>
>>
>
2819
days inactive
2827
days old
11 comments
6 participants
participants (6)
-
Eduardo Mayoral -
Kevin Goldblatt -
Liron Aravot -
Lukáš Kaplan -
Yaniv Kaul -
Николаев Алексей