[PATCH] support NIC configuration in iBFT
Alex Zeffertt
source. Note: this patch depends on support-multidisk-ibft.patch sent earlier.
Regards,
Alex Zeffertt
Changelog:
---------
For each target listed, iSCSI Boot Firmware Tables specify which NIC to use and
how it should be configured. Until now this information has been ignored by
open-iscsi.
This patch enables this information to be listed by iscsiadm/iscsistart, and it
also enables iscsistart to apply the configuration.
The existing commands "iscsiadm -m fw" and "iscsistart -f" now list the NIC
configuration from the iBFT in addition to the other information.
The new command "iscsiadm -n" applies the NIC configuration specified in the
iBFT for each valid target.
The primary benefit of this is that it allows the initrd to extract networking
information from the iBFT rather than hard code it. If the initrd uses the iBFT
for networking info then when the setup is modified via the BIOS it is not
necessary to rebuild the initrd.
Alex Zeffertt
Please ignore the patch in my previous email and use the one attached instead.
I fixed a bug in the previous patch where "iscsistart -n" was assuming that the
interface being configured was already up.
Regards,
Alex
Mike Christie
For offload with bnx2i and cxgb3i, this is going to be needed. Instead
of the net ioctls, we have to pass this info down to the iscsi offload
drivers using the iscsi interface.
For software iscsi with ibft, I think it will be useful too. I am just
not sure if it might mess up other distro stuff. Have you evaluated
them? Let's see if Hannes from SUSE or Hans from Red Hat have an opinion.
Alex Zeffertt
I've now rebased this patch so that it applies to the top of the open-iscsi git
tree, as requested.
Please let me know if there is anything you would like me to alter before it is
applied.
Regards,
Alex
Changelog:
---------
For each target listed, iSCSI Boot Firmware Tables specify which NIC to use and
how it should be configured. Until now this information has been ignored by
open-iscsi. This patch enables iscsistart to apply the NIC configuration.
The new command "iscsiadm -n" applies the NIC configuration specified in the
iBFT for each valid target.
The primary benefit of this is that it allows the initrd to extract networking
information from the iBFT rather than hard code it. If the initrd uses the iBFT
for networking info then when this info is modified via the BIOS it is not
necessary to rebuild the initrd.
Signed-off-by <alex.z...@eu.citrix.com>
Mike Christie
Thanks for doing this. Sorry for the late reply.
Just one comment on the patch. Could you move the code in the 'n' case
+ case 'n':
+ /*
+ * Bring up NICs required by targets in iBFT
+ * using IP addresses and routing info from iBFT.
+ */
......
to some helper function, so it is not so crowed and a little easier to read?
Alex Zeffertt
>
> Thanks for doing this. Sorry for the late reply.
>
>
> Just one comment on the patch. Could you move the code in the 'n' case
>
> + case 'n':
> + /*
> + * Bring up NICs required by targets in iBFT
> + * using IP addresses and routing info from iBFT.
> + */
>
> ......
>
>
> to some helper function, so it is not so crowed and a little easier to read?
>
No problem. Please find a new patch attached.
Regards,
Alex
Ulrich Windl
I always prefer to list options in an ordered way (alphabetically).
- while ((ch = getopt_long(argc, argv, "i:t:g:a:p:d:u:w:U:W:bfvh",
+ while ((ch = getopt_long(argc, argv, "i:t:g:a:p:d:u:w:U:W:bnfvh",
Mike Christie
Merged in commit 39f4761231e2aa20b468cd5258785d6f56472772. It should
show up in the git tree in a little bit and in the next major release.
Thanks!
Hannes Reinecke
In principle this is a good idea; it certainly saves quite some trouble
for eg initrd as we don't have to worry about interface naming etc.
However:
Having iscsiadm setting up the network interfaces we do have the problem
that we're doing it alongside the 'normal' system network configuration.
IE the system hasn't any idea that we've already configured the interface
nor how it should handle it.
This is especially a problem during shutdown, where the networking scripts
are prone to shutdown any unknown interface.
And having the networking scripts calling out to iscsiadm is not earning
us much favours I would assume.
A possible route here would be to modify the networking scripts to check
the ibft variables; however, this requires quite some bit of sysfs tree
walking. And given the somewhat fluctuating nature of sysfs it will earn
us even less favours.
It would be cool if we had an 'ibft' link in the network interface, though ...
Hmm. Maybe I can trick Kay Sievers into doing one ...
But apart from that is a pretty cool thing.
It especially fixes the problem we have right now that changes in the
iBFT BIOS are not picked up once the machines are installed.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
ha...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N�rnberg
GF: Markus Rex, HRB 16746 (AG N�rnberg)
Alex Zeffertt
Remember that the context is that this has to be done in the initrd! (You have
to bring up the LUNs present in the iBFT to access the root disk, and to do that
you need to apply the network configuration in the iBFT.)
You may not be able to do much scripting in the initrd. In particular Redhat
initrds use an interpreter called nash which is hopeless for scripting - you
can't even assign an environment variable in nash! Adding one line which says
"iscsistart -n" is much simpler.
Most distro's shutdown scripts will only shutdown interfaces if they have been
explicitly configured. So to avoid the interface being shutdown (and thereby
breaking the root disk) it should just be sufficient to just not write
ifcfg-ethN (or equivalent for your distro).
> It would be cool if we had an 'ibft' link in the network interface, though ...
> Hmm. Maybe I can trick Kay Sievers into doing one ...
>
> But apart from that is a pretty cool thing.
> It especially fixes the problem we have right now that changes in the
> iBFT BIOS are not picked up once the machines are installed.
Thanks!
-- Alex
>
> Cheers,
>
> Hannes
>