Mike Christie <[email protected]> writes:
> On 10/6/15, 5:58 AM, Ferenc Wagner wrote:
>
>> When booting Linux from iSCSI, the initial connections are set up like
>>
>> modprobe iscsi_tcp
>> modprobe crc32c
>> modprobe iscsi_ibft
>> iscsistart -N
>> iscsistart -b
>>
>> that is, all the parameters are set in the offload card via the adapter
>> ROM utility and the initramfs scripts read them from the iBFT.
>
> Did you implement this solution yourself or what distro are you using?
I'm using Debian jessie, and the above is from an initramfs hook script
I implemented myself.
>> My questions:
>>
>> 1. Can the iBFT contain two target specifications (one per NIC) only? I
>> can set up more in the adapter ROM utility.
>
> If there are more than one targets exported in sysfs then the iscsi
> tools will try to log into them all. Some iBFT/FW implementations only
> export the specific target they used though. For example, you can
> define 2 targets, but one is only used by the iBFT initiator for
> failover, and the backup one is sometimes not exported.
It's actually a dual-port card. I set up two targets for each port, but
in sysfs I can only see one for each. I don't know whether the adapter
ROM logged in to both or not, though that wouldn't make much sense, as I
doubt it did multipathing.
>> 2. The iscsistart utility starts up sessions with iface_name like
>> <transport>.<MAC> (be2iscsi.aa:bb:cc:dd:ee:ff in my case), but iscsid
>
> Are you using iscsi_tcp and ibft or be2iscsi or both? iscsi_tcp is for
> software iscsi and you would normally boot from that driver with
> iBFT. Your example above has be2iscsi which is the emulex/advogato
> offload driver and that does not use ibft.
I don't use iscsi_tcp, that's left in inadvertently, sorry for creating
confusion. I use a dual port Emulex offload card. I thought I needed
iscsi_ibft to get iscsistart read out the target parameters from sysfs,
but if it's not needed, then I'll remove that as well. Thanks for
clearing this up.
>> uses iface_names like <transport>.<MAC>.ipv4.1. This leads to 6
>> sessions instead of 4, because iscsid does not take over the two
>> created by iscsistart, since the interface names are different. It's
>> possible to define ifaces with the simple names and override the
>> interface names used by iscsid, but that's a hassle and the qualified
>> interface names appear nevertheless. Is there an elegant way to get
>> both utilities use the same names? Looks like ac38eee2 introduced
>> this discrepancy.
>
> Yeah, sorry that is a bug in the code. Thanks for debugging.
Well then, if it's possible to fix with a straightforward patch, which
can be backported to 2.0.873 (3b4b4500, more precisely), it could be
possible to include the fix in a stable update. What do you think?
> Do you have records setup for the boot targets (did you run the
> iscsiadm discovery command to the boot targets and so in
> /etc/iscsi/targets you have info for them)?
I did not run discovery, I added the nodes by hand after boot.
> If you run
> iscsiadm -m node -P 1
> from the booted buggy system what do you see?
I've already defined interfaces with the iscsistart names, so it's
Target: iqn.2000-02.hu.niif:dx90.pc
Portal: 10.0.3.1:3260,-1
Iface Name: be2iscsi.90:1b:0e:23:cc:51
Portal: 10.0.3.2:3260,-1
Iface Name: be2iscsi.90:1b:0e:23:cc:51
Portal: 10.0.4.1:3260,-1
Iface Name: be2iscsi.90:1b:0e:23:cc:55
Portal: 10.0.4.2:3260,-1
Iface Name: be2iscsi.90:1b:0e:23:cc:55
I'm installing a new system with similar hardware, and will send you
output from all (even buggy) stages. This is what I have in the
/etc/iscsi/ifaces directory:
be2iscsi.90:1b:0e:23:cc:51 be2iscsi.90:1b:0e:23:cc:55
be2iscsi.90:1b:0e:23:cc:51.ipv4.0 be2iscsi.90:1b:0e:23:cc:55.ipv4.0
be2iscsi.90:1b:0e:23:cc:51.ipv6.0 be2iscsi.90:1b:0e:23:cc:55.ipv6.0
I added the short ones by hand, and the long ones are always recreated
if I delete them.
> When the system is booted in the buggy state could you also run:
> iscsiadm -m session -P 1
> and send the output?
I will. But I remember pretty well: SID 1 used Iface Name:
be2iscsi.90:1b:0e:23:cc:51, SID 2 be2iscsi.90:1b:0e:23:cc:55. Without
explicit iface configuration, iscsiadm only allowed the long iface names
above, and then created SID 3-6 with them when I logged in to two
portals from each. Multipathd then created two failover groups with 3-3
paths in each.
> Also if you are not using SUSE and if when you run the command above
> you see this:
>
> Target: your target
> Portal: your_ip:port
> <transport>.<MAC>.ipv4.1
>
> Could you delete it manually
>
> iscsiadm -m session -T your_target -p your_ip -I <transport>.<MAC>.ipv4.1
> --logout
> iscsiadm -m node -T your_target -p your_ip -I <transport>.<MAC>.ipv4.1
>
> and reboot and see if you still get the extra sessions?
In a pristine system (iscsistart only, no targets configured by
iscsiadm) I only get two sessions (with short interfaces names). With
an older open-iscsi version I could then add the four needed node, and
after login iscsid took over the two from iscsistart and also started
the two other. Now, that iscsid uses long interface names, it creates
four new sessions and leaves the two from iscsistart unmanaged. Than
is, unless I define interfaces with the old (short) names and use them
when adding the nodes with iscsiadm.
> This is just to confirm where the extra sessions are coming from. To
> fix this properly I will need to modify the iscsistart default iface
> name creation, and you will have make sure your solution loads
> be2iscsi before running iscsistart if that is the driver you are
> using.
Sounds sweet, thanks! The be2iscsi module seems to be loaded
automatically early during the boot (initramfs phase), probably by udev.
But I'll load it explicitly if needed.
--
Regards,
Feri.
--
You received this message because you are subscribed to the Google Groups
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
