Bug 1034291

I think blivet needs to change to always check for iscsi firmware devices.  Now it seems to only do so if ip=ibft is on the command line, but not all iSCSI offload solutions use iBFT or need network interfaces configured by the OS to function.

Trying to work around this with rd.iscsi.firmware=1 is wrong, because that results in the initrd establishing the connection early and blivit/anaconda treat the iSCSI disk as a local SCSI disk - there is no iSCSI configuration stored and no runtime services running to manage the session.

I agree with Chris. I am posting a patch to anaconda-patches.

updates image for latest nightly for testing:
http://rvykydal.fedorapeople.org/updates.r7autofirmware.img

With the updated image the iSCSI sessions are created successfully.

[anaconda root@localhost ~]# iscsiadm -m session
be2iscsi: [1] 10.16.41.222:3260,1 iqn.1992-08.com.netapp:sn.151753773
be2iscsi: [2] 10.16.43.127:3260,1 iqn.1992-08.com.netapp:sn.151753773
be2iscsi: [3] 10.16.41.222:3260,1 iqn.1992-08.com.netapp:sn.151753773
be2iscsi: [4] 10.16.43.127:3260,1 iqn.1992-08.com.netapp:sn.151753773


Do you know which blivet version will have this update?

(In reply to Bruno Goncalves from comment #9)
 
> Do you know which blivet version will have this update?

It will be set in Fixed In Version field when the patch gets reviewed and pushed.

Server installed properly with:
 
anaconda 19.31.48-1
python-blivet-0.18.16-1.el7

*** Bug 1026916 has been marked as a duplicate of this bug. ***

I was installing RHEL 7 snapshot 10 on an iSCSI disk using BCM 57810 device. The device has the iBFT configured with initiator and target details provided in the NIC. I observed that ip=ibft had to be passed on the command line during booting into DVD for the OS interface to get IP. The python-blivet version in snapshot 10 is 0.18.31-1.el7. I am not sure if i am missing something here. This bug seems to indicate that for python-blivet versions >= 0.18.16-1, there is no need to pass ip=ibft. It needs to be picked up automatically.

Narendra,

I'm using PXE to install my server and I use the following options to install and boot it successfully. I didn't need to use ip=ibft.

Install Command line:
Command line: initrd=/images/storageqe-11.rhts.eng.bos.redhat.com/initrd console=ttyS1,115200 ks=http://beaker.engineering.redhat.com/kickstart/672714 ksdevice=E8:39:35:20:DE:CA serial netboot_method=pxe BOOT_IMAGE=/images/storageqe-11.rhts.eng.bos.redhat.com/kernel BOOTIF=01-e8-39-35-20-de-ca  

[0.000000] iBFT found at 0x8aa80. 


Boot command line:
Kernel command line: BOOT_IMAGE=/vmlinuz-3.10.0-110.el7.x86_64 root=UUID=2d3f1040-e55d-4442-9ab1-7d4798fd42b2 ro ip=enp4s0f0:dhcp iscsi_firmware rd.lvm.lv=rhel_storageqe-11/root crashkernel=auto ifname=enp4s0f0:e8:39:35:20:de:ca rd.lvm.lv=rhel_storageqe-11/swap vconsole.keymap=us console=ttyS1,115200 vconsole.font=latarcyrheb-sun16 LANG=en_US.UTF-8

(In reply to Narendra K from comment #14)
> I was installing RHEL 7 snapshot 10 on an iSCSI disk using BCM 57810 device.
> The device has the iBFT configured with initiator and target details
> provided in the NIC. I observed that ip=ibft had to be passed on the command
> line during booting into DVD for the OS interface to get IP. The
> python-blivet version in snapshot 10 is 0.18.31-1.el7. I am not sure if i am
> missing something here. This bug seems to indicate that for python-blivet
> versions >= 0.18.16-1, there is no need to pass ip=ibft. It needs to be
> picked up automatically.

Please see bug #1063790 comment #2.

Main reason for not requiring ip=ibft option [1] for installer to try to discover and connect to targets found in firmware (ie the point of this BZ) was that for some offload solutions using the option would even make it fail in initramfs. This is also the reason why we can't assume ip=ibft (ie configure network device automatically according to iBFT) in every case when iBFT configuration is found.

[1] ip=ibft option just tells dracut/initramfs (at early stage of installation) to configure a network device based on information found in iBFT table.

(In reply to Bruno Goncalves from comment #15)
> Narendra,
> 
> I'm using PXE to install my server and I use the following options to
> install and boot it successfully. I didn't need to use ip=ibft.
> 

Thanks Bruno for the information. PXE booting from an interface would also ensure that interface will get an IP address (DHCP). In this scenario, i think ip=ibft is not required. But if a user is installing using DVD, then no interface will get an IP address until we configure it in the subsequent stages of an installation.

Exactly, trying to make me more clear: with fix for this bug ip=ibft in not required for connecting to firmware targets automatically, but it is required if the iSCSI solution needs a network device to be configured by OS and it would not happen by other means (ie configuring the device for fetching kickstart and installation image which is most probably Bruno's case).

(In reply to Radek Vykydal from comment #18)
> Exactly, trying to make me more clear: with fix for this bug ip=ibft in not
> required for connecting to firmware targets automatically, but it is
> required if the iSCSI solution needs a network device to be configured by OS
> and it would not happen by other means (ie configuring the device for
> fetching kickstart and installation image which is most probably Bruno's
> case).

1.To understand this better, does this mean that target IP and target IQN is fetched from iBFT (user need not provide it manually ? ), initiator iqn is fetched from iBFT, but initiator IP is not fetched from IBFT, though iBFT would have one assigned during pre-boot when it connects to target during POST. Is this understanding correct ?

Also, in PXE scenario the interface which gets IP address is different than the once which is configured for iBFT. So it seems like the OS connects to the target using a different interface than which is configured for iBFT.

2. If a user is installing using DVD (no other network device activation method), then, then ip=ibft is required. 

Bruno, could you please share the output from 'iscsiadm -m fw' and 'ip addr show' ?

(In reply to Radek Vykydal from comment #16)
> (In reply to Narendra K from comment #14)
[...]
> 
> Please see bug #1063790 comment #2.

Could you please provide me access to this bug ? I don't have access.

Narendra, I added you to CC of the bug 1063790, you should be able to access the bug now.

(In reply to Narendra K from comment #19)
> (In reply to Radek Vykydal from comment #18)
> > Exactly, trying to make me more clear: with fix for this bug ip=ibft in not
> > required for connecting to firmware targets automatically, but it is
> > required if the iSCSI solution needs a network device to be configured by OS
> > and it would not happen by other means (ie configuring the device for
> > fetching kickstart and installation image which is most probably Bruno's
> > case).
> 
> 1.To understand this better, does this mean that target IP and target IQN is
> fetched from iBFT (user need not provide it manually ? ), initiator iqn is
> fetched from iBFT, but initiator IP is not fetched from IBFT, though iBFT
> would have one assigned during pre-boot when it connects to target during
> POST. Is this understanding correct ?

Information about iSCSI targets and initiator iqn is always fetched from iBFT automatically (in anaconda, after switchroot) and anaconda tries to connect to the targets. But a network device would be configured with configuration from iBFT and brought up only if ip=ibft option is present (this would happen in initramfs, before switchroot).

> 
> Also, in PXE scenario the interface which gets IP address is different than
> the once which is configured for iBFT. So it seems like the OS connects to
> the target using a different interface than which is configured for iBFT.

Yes, this can happen. In this case you need to use ip=ibft and possibly another ip= options for other interfaces you want to use for installation (eg to fetch packages).

> 
> 2. If a user is installing using DVD (no other network device activation
> method), then, then ip=ibft is required. 
> 

Yes.

(In reply to Narendra K from comment #19)
> Bruno, could you please share the output from 'iscsiadm -m fw' and 'ip addr
> show' ?

You are right, we need to add "ip=ibft" if we want the server to boot using iBFT interface, otherwise as on my PXE scenario it will use the PXE interface as shown below.

# iscsiadm -m session -P1
Target: iqn.1992-08.com.netapp:sn.151753773 (non-flash)
    Current Portal: 10.16.43.127:3260,1
    Persistent Portal: 10.16.43.127:3260,1
        **********
        Interface:
        **********
        Iface Name: default
        Iface Transport: tcp
        Iface Initiatorname: iqn.1994-05.com.redhat:storageqe-11
        Iface IPaddress: 10.16.67.73
        Iface HWaddress: <empty>
        Iface Netdev: <empty>
        SID: 1
        iSCSI Connection State: LOGGED IN
        iSCSI Session State: LOGGED_IN
        Internal iscsid Session State: NO CHANGE

# iscsiadm -m fw
# BEGIN RECORD 6.2.0.873-20
iface.initiatorname = iqn.1994-05.com.redhat:storageqe-11
iface.transport_name = tcp
iface.hwaddress = e8:39:35:20:de:cc
iface.bootproto = DHCP
iface.ipaddress = 10.16.70.161
iface.subnet_mask = 255.255.248.0
iface.gateway = 10.16.71.254
iface.primary_dns = 10.16.36.29
iface.secondary_dns = 10.11.5.19
iface.vlan_id = 0
iface.net_ifacename = enp4s0f1
node.name = iqn.1992-08.com.netapp:sn.151753773
node.conn[0].address = 10.16.43.127
node.conn[0].port = 3260
node.boot_lun = 00000000
# END RECORD

# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp4s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether e8:39:35:20:de:ca brd ff:ff:ff:ff:ff:ff
    inet 10.16.67.73/21 brd 10.16.71.255 scope global dynamic enp4s0f0
       valid_lft 86351sec preferred_lft 86351sec
    inet6 2620:52:0:1040:ea39:35ff:fe20:deca/64 scope global dynamic 
       valid_lft 2591998sec preferred_lft 2591998sec
    inet6 fec0:0:a10:4000:ea39:35ff:fe20:deca/64 scope site dynamic 
       valid_lft 2591998sec preferred_lft 2591998sec
    inet6 fe80::ea39:35ff:fe20:deca/64 scope link 
       valid_lft forever preferred_lft forever
3: enp4s0f1: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether e8:39:35:20:de:cc brd ff:ff:ff:ff:ff:ff
    inet6 2620:52:0:1040:ea39:35ff:fe20:decc/64 scope global dynamic 
       valid_lft 2591998sec preferred_lft 2591998sec
    inet6 fec0:0:a10:4000:ea39:35ff:fe20:decc/64 scope site dynamic 
       valid_lft 2591998sec preferred_lft 2591998sec
    inet6 fe80::ea39:35ff:fe20:decc/64 scope link 
       valid_lft forever preferred_lft forever
4: enp5s0f0: <NO-CARRIER,BROADCAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether e8:39:35:20:de:ce brd ff:ff:ff:ff:ff:ff
5: enp5s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether e8:39:35:20:de:d0 brd ff:ff:ff:ff:ff:ff

(In reply to Bruno Goncalves from comment #22)
> (In reply to Narendra K from comment #19)
> > Bruno, could you please share the output from 'iscsiadm -m fw' and 'ip addr
> > show' ?
> 
> You are right, we need to add "ip=ibft" if we want the server to boot using
> iBFT interface, otherwise as on my PXE scenario it will use the PXE
> interface as shown below.

Bruno, thank you for the information. Also, on my system i am observing that the interface which is set up for iBFT gets renamed as 'ibft0'. Is the behavior same in your set up ? Is it as expected ?

Per bug #828505, ibftX renaming is expected behaviour.

This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.