5

Sometimes when you connect to a multipath'ed iSCSI target you will have access to only some of its portals. This is common when the initiator is directly connected to the target's ethernet ports, as opposed to going though switches.

[my actual example at hand of such an infrastructure is a Dell MD3200i / MD3220i SAN with 4 directly connected servers]

When you do iSCSI discovery the initiator will get a list of all portals, even those that it is not actually connected to and can't speak to. With a dual controller, four ports per controller, you would see something like:

# iscsiadm --mode discovery --type sendtargets --portal 192.168.130.101
192.168.130.101:3260,1 iqn.1984-05.com.dell:powervault.md3200i.690b11c0123456789012345678901234
192.168.131.101:3260,1 iqn.1984-05.com.dell:powervault.md3200i.690b11c0123456789012345678901234
192.168.132.101:3260,1 iqn.1984-05.com.dell:powervault.md3200i.690b11c0123456789012345678901234
192.168.133.101:3260,1 iqn.1984-05.com.dell:powervault.md3200i.690b11c0123456789012345678901234
192.168.130.102:3260,2 iqn.1984-05.com.dell:powervault.md3200i.690b11c0123456789012345678901234
192.168.131.102:3260,2 iqn.1984-05.com.dell:powervault.md3200i.690b11c0123456789012345678901234
192.168.132.102:3260,2 iqn.1984-05.com.dell:powervault.md3200i.690b11C0123456789012345678901234
192.168.133.102:3260,2 iqn.1984-05.com.dell:powervault.md3200i.690b11c0123456789012345678901234

...but the host is physically cabled to the first (192.168.130.101) and sixth (192.168.131.102) ports, so it will never be able to speak with the other six portals.

Following typical documentation for iSCSI targets one ends up with all portals "known" by the initiator but the latter will only do the actual login on the ones of interest (two of them in the above example).

Should the "unreachable" ones be deleted from the initiator's configuration? Can they pose any problem being "known" even if not actually logged into ?

3 Answers 3

1

Discover mode shows available by configuration portals, but it do not connects to such targets and do not checks availibility.

Only when you login to target, initiator trying to connect such portals (for all discovered portals or for one specified portal), and then some of such connections just be refused by login process. Only availible portals get establish connections and provide luns for you. After that process, initiator shoud not need information about failed portals. It need it only by discover. In that case, i think you may get problems only with speed of discover process (if using not standart timeouts + drop packets), but not with anything else.

2

I have a similar setup using direct attached Proxmox hosts. The daemon.log was filled with 700K entries per day although the startup of the unneeded nodes was set to manual (which was sufficient at first).

On each host, I removed all but the needed nodes like this:

iscsiadm -m node -T iqn.1984-05.com.dell:powervault.md3200i.690b11c0123456789012345678901234 -p 10.0.2.120 -I iscsi_enp2s0f0 -o delete
iscsiadm -m node -T iqn.1984-05.com.dell:powervault.md3200i.690b11c0123456789012345678901234 -p 10.0.2.120 -I iscsi_enp2s0f1 -o delete
1

You can leave these 'discovered unavailable' targets there, the initiator can't login to these targets. However, these 'unavailable' targets will slow down the initiator start/stop time, so it would be better just remove them. You will find all discovered targets in /var/lib/iscsi/nodes, so run

rm -rf /var/lib/iscsi/nodes/iqn.1984-05.com.dell:powervault.md3200i.690b11c0123456789012345678901234/192.168.132.101,3260,1

I noticed this article shows a very good example for iscsi setup, configuration, debug, and tuning.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .