<h2>How Anaconda handles iscsi<aclass="headerlink"href="#how-anaconda-handles-iscsi"title="Permalink to this headline">¶</a></h2>
<p>iSCSI comes into play several times while Anaconda does its thing:</p>
<p>In loader, when deciding what NIC we should setup, we check if we have iBFT
information from one of the cards. If we do we set that card up with what we
found in the table, it usually boils down to an IPv4 static or IPv4
DHCP-obtained address. [4][5]</p>
<p>Next, after the main UI startup during filtering (or storage scan, whatever
comes first) we startup the iscsi support code in Anaconda [6]. This currently
involves:
- manually modprobing related kernel modules
- starting the iscsiuio daemon (required by some partial offload cards)
- most importantly, starting the iscsid daemon</p>
<p>All iBFT connections are brought up next by looking at the cards’ iBFT data, if
any. The filtering screen has a feature to add advanced storage devices,
including iSCSI. Both connection types are handled by libiscsi (see below). The
brought up iSCSI devices appear as /dev/sdX and are treated as ordinary block
devices.</p>
<p>When DeviceTree scans all the block devices it uses the udev data (particularly
the ID_BUS and ID_PATH keys) to decide if the device is an iscsi disk. If it is,
it is represented with an iScsiDiskDevice class instance. This helps Anaconda
remember that:</p>
<ulclass="simple">
<li>we need to install dracut-network so the generated dracut image is able to
bring up the underlying NIC and establish the iscsi connection.</li>
<li>if we are booting from the device we need to pass dracut a proper set of
arguments that will allow it to do so.</li>
</ul>
</div>
<divclass="section"id="libiscsi">
<h2>Libiscsi<aclass="headerlink"href="#libiscsi"title="Permalink to this headline">¶</a></h2>
<p>How are iSCSI targets found and logged into? Originally Anaconda was just
running iscsiadm as an external program through execWithRedirect(). This
ultimately proved awkward especially due to the difficulties of handling the
CHAP passphrases this way. That is why Hans de Goede <<aclass="reference external"href="mailto:hdegoede%40redhat.com">hdegoede<span>@</span>redhat<span>.</span>com</a>>, the
previous maintainer of the Anaconda iscsi subsystem decided to write a better
interface and created libiscsi (do not confuse this with the libiscsi.c in
kernel). Currently libiscsi lives as a couple of patches in the RHEL6
iscsi-initiator-utils CVS (and in Fedora package git, in somewhat outdated
version). Since Anaconda is libiscsi’s only client at the moment it is
maintained by the Anaconda team.</p>
<p>The promise of libiscsi is to provide a simple C/Python API to handle iSCSI
connections while being somewhat stable and independent of the changes in the
underlying initiator-utils (while otherwise being tied to it on the
implementation level).</p>
<p>And at the moment libiscsi does just that. It has a set of functions to discover
and login to targets software targets. It supports making connections through
partial offload interfaces, but the only discovery method supported at this
moment is through firmware (iBFT). Its public data structures are independent of
iscsi-initiator-utils. And there is some python boilerplate that wraps the core
functions so we can easily call those from Anaconda.</p>
<p>To start nontrivial hacking on libiscsi prepare to spend some time familiarizing
yourself with the iscsi-initiator-utils internals (it is complex but quite
nice).</p>
</div>
<divclass="section"id="debugging-iscsi-bugs">
<h2>Debugging iSCSI bugs<aclass="headerlink"href="#debugging-iscsi-bugs"title="Permalink to this headline">¶</a></h2>
<p>There is some information in anaconda.log and storage.log but libiscsi itself is
quite bad at logging. Most times useful information can be found by sshing onto
the machine and inspecting the output of different iscsiadm commands [2][7],
especially querying the existing sessions and known interfaces.</p>
<p>If for some reason the DeviceTree fails at recognizing iscsi devices as such,
‘udevadm info –exportdb’ is of interest.</p>
<p>The booting problems are either due to incorrectly generated dracut boot
arguments or they are simply dracut bugs.</p>
<p>Note that many of the iscsi adapters are installed in different Red Hat machines
and so the issues can often be reproduced and debugged.</p>
<ahref="driverdisc.html"class="btn btn-neutral"title="Brief description of DriverDisc version 3"accesskey="p"><spanclass="fa fa-arrow-circle-left"></span> Previous</a>
Built with <ahref="http://sphinx-doc.org/">Sphinx</a> using a <ahref="https://github.com/snide/sphinx_rtd_theme">theme</a> provided by <ahref="https://readthedocs.org">Read the Docs</a>.
