On 06/29/16 at 10:04am, Xunlei Pang wrote:
On 2016/06/28 at 22:08, Baoquan He wrote:
> There are several kinds of iSCSI mode rhel support currently.
> - Pure hardware iSCSI
> - iBFT iSCSI
> - Pure software iSCSI
Since we had the following standard iSCSI naming, how about to use them instead?
- iSCSI HBA (all offload)
- Software iSCSI with iBFT (bnx2i, cxgb3i, cxgb4i)
- Software iSCSI with hybrid (be2iscsi)
- Software initiator based iSCSI
Thanks for your comments, Xunlei.
I want to say, right, these are written into supported-kdump-targets.txt
and customers can check them too. However when we discuss in technical
meeting or face to face talking we used to call the name we can remember
easily, like pure hardware iSCSI, ibft iSCSI and pure software iSCSI. I
refer to them in patch log because commit log can only be seen by us,
kdump dev. When we git blame those code or doc we don't understand, we
can catch it by these commit log. This is why I chose to use these
non-standard but easily remembered names.
I am fine if you insist on this, I can change it.
> Except for the 1st one that firmware takes care of everything to
> make it behave like a local disk, both iBFT and pure software iSCSI
> mode need pass information to kdump kernel for configuring them
> correctly.
>
> Currently kdump takes iBFT mode as a software iSCSI and collects
> the related information to set up software iSCSI in 2nd kernel,
> though dracut can detect and collect information to set up iBFT
> iSCSI of 2nd kernel. This brings up 2 problems:
>
> 1) For iBFT mode 2 sessions will be built in 2nd kernel, one is in
> iBFT mode, the other is pure software mode. This is because both
> kdump and dracut collect iSCSI inforamtion separately for a certain
s/inforamtion/information
> iBFT mode iSCSI of 1st kernel.
Which session will be used in such cases? or it will become dysfunctional with the 2
sessions?
Sorry, I was wrong here. Checked with Minfei again in mail, there's only
one session. The ibft session is setup earlier, then it won't do it
again when parse pure software iSCSI information passed in. Here
only redundent information is connected and passed to 2nd kernel.
>
> 2) These 2 sessions of 2nd kernel for a certain session of 1st kernel
> could contain two "ip=xxx" cmdline option. This will cause cmdline
> handling error in dracut.
Yeah, this is understandable.
> In order to avoid above 2 problems, kdump need detect iBFT mode iSCSI
> and leave it to dracut. This is what is donw in this patch.
s/donw/done
Will update this when repost.
>
> Regards,
> Xunlei
>
> >
> > Signed-off-by: Baoquan He <bhe(a)redhat.com>
> > ---
> > dracut-module-setup.sh | 10 +++++++++-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
> > index ecf7d3f..aa204f8 100755
> > --- a/dracut-module-setup.sh
> > +++ b/dracut-module-setup.sh
> > @@ -511,7 +511,11 @@ kdump_get_iscsi_initiator() {
> > return 1
> > }
> >
> > -# No ibft handling yet.
> > +# Figure out iBFT session according to session type
> > +is_ibft() {
> > + [ "$(kdump_iscsi_get_rec_val $1 "node.discovery_type")"
= fw ]
> > +}
> > +
> > kdump_setup_iscsi_device() {
> > local path=$1
> > local tgt_name; local tgt_ipaddr;
> > @@ -534,6 +538,10 @@ kdump_setup_iscsi_device() {
> > return 1
> > fi
> >
> > + if is_ibft ${path}; then
> > + return
> > + fi
> > +
> > tgt_name=$(kdump_iscsi_get_rec_val ${path} "node.name")
> > tgt_ipaddr=$(kdump_iscsi_get_rec_val ${path}
"node.conn\[0\].address")
> >
> _______________________________________________
> kexec mailing list
> kexec(a)lists.fedoraproject.org
>
https://lists.fedoraproject.org/admin/lists/kexec@lists.fedoraproject.org