Re: [ovirt-users] iSCSI Discovery cannot detetect LUN
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@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@redhat.com> *Datum:* 24. března 2017 23:25:21 SEČ *Komu:* Lukáš Kaplan <lkaplan@dragon.cz> *Kopie:* users <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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
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@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@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@redhat.com> *Datum:* 24. března 2017 23:25:21 SEČ *Komu:* Lukáš Kaplan <lkaplan@dragon.cz> *Kopie:* users <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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
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@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@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@redhat.com <mailto:ykaul@redhat.com>> *Datum:* 24. března 2017 23:25:21 SEČ *Komu:* Lukáš Kaplan <lkaplan@dragon.cz <mailto:lkaplan@dragon.cz>> *Kopie:* users <users@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@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@ovirt.org <mailto:Users@ovirt.org> http://lists.ovirt.org/mailman/listinfo/users <http://lists.ovirt.org/mailman/listinfo/users>
_______________________________________________ Users mailing list Users@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@redhat.com</a>><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@dragon.cz</a>><br> <b>Kopie:</b> users <<a moz-do-not-send="true" href="mailto:users@ovirt.org" target="_blank">users@ovirt.org</a>><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@dragon.cz</a>></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@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>/listinfo/users</a><br> <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://lists.ovirt.org/mailman/listinfo/users</a> </pre> </blockquote> <br> </body> </html> --------------8A7453E4F89AAABE5D73CCA3--
On Wed, Mar 29, 2017 at 12:59 PM, Eduardo Mayoral <emayoral@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@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@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@redhat.com> *Datum:* 24. března 2017 23:25:21 SEČ *Komu:* Lukáš Kaplan <lkaplan@dragon.cz> *Kopie:* users <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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing listUsers@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
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@redhat.com> wrote:
On Wed, Mar 29, 2017 at 12:59 PM, Eduardo Mayoral <emayoral@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@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@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@redhat.com> *Datum:* 24. března 2017 23:25:21 SEČ *Komu:* Lukáš Kaplan <lkaplan@dragon.cz> *Kopie:* users <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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing listUsers@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
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@dragon.cz 2017-03-29 12:12 GMT+02:00 Liron Aravot <laravot@redhat.com>:
On Wed, Mar 29, 2017 at 12:59 PM, Eduardo Mayoral <emayoral@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@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@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@redhat.com> *Datum:* 24. března 2017 23:25:21 SEČ *Komu:* Lukáš Kaplan <lkaplan@dragon.cz> *Kopie:* users <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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing listUsers@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
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@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@redhat.com>:
On Wed, Mar 29, 2017 at 12:59 PM, Eduardo Mayoral <emayoral@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@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@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@redhat.com> *Datum:* 24. března 2017 23:25:21 SEČ *Komu:* Lukáš Kaplan <lkaplan@dragon.cz> *Kopie:* users <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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing listUsers@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On Fri, Mar 31, 2017 at 3:43 PM, Lukáš Kaplan <lkaplan@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@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@redhat.com>:
On Wed, Mar 29, 2017 at 12:59 PM, Eduardo Mayoral <emayoral@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@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@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@redhat.com> *Datum:* 24. března 2017 23:25:21 SEČ *Komu:* Lukáš Kaplan <lkaplan@dragon.cz> *Kopie:* users <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@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@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > >
_______________________________________________ Users mailing listUsers@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
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@redhat.com>:
On Fri, Mar 31, 2017 at 3:43 PM, Lukáš Kaplan <lkaplan@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@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@redhat.com>:
On Wed, Mar 29, 2017 at 12:59 PM, Eduardo Mayoral <emayoral@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@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@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@redhat.com> > *Datum:* 24. března 2017 23:25:21 SEČ > *Komu:* Lukáš Kaplan <lkaplan@dragon.cz> > *Kopie:* users <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@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@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users >> >> >
_______________________________________________ Users mailing listUsers@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On Sun, Apr 2, 2017 at 10:17 PM, Lukáš Kaplan <lkaplan@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@redhat.com>:
On Fri, Mar 31, 2017 at 3:43 PM, Lukáš Kaplan <lkaplan@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@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@redhat.com>:
On Wed, Mar 29, 2017 at 12:59 PM, Eduardo Mayoral <emayoral@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@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@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@redhat.com> >> *Datum:* 24. března 2017 23:25:21 SEČ >> *Komu:* Lukáš Kaplan <lkaplan@dragon.cz> >> *Kopie:* users <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@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@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >>> >>> >> >
_______________________________________________ Users mailing listUsers@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
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@redhat.com>:
On Sun, Apr 2, 2017 at 10:17 PM, Lukáš Kaplan <lkaplan@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@redhat.com>:
On Fri, Mar 31, 2017 at 3:43 PM, Lukáš Kaplan <lkaplan@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@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@redhat.com>:
On Wed, Mar 29, 2017 at 12:59 PM, Eduardo Mayoral <emayoral@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@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@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@redhat.com> >>> *Datum:* 24. března 2017 23:25:21 SEČ >>> *Komu:* Lukáš Kaplan <lkaplan@dragon.cz> >>> *Kopie:* users <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@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@ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/users >>>> >>>> >>> >> > > > _______________________________________________ > Users mailing listUsers@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > >
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
participants (6)
-
Eduardo Mayoral -
Kevin Goldblatt -
Liron Aravot -
Lukáš Kaplan -
Yaniv Kaul -
Николаев Алексей