Bug 1283436 - [RFE] Diskless boot via iSCSI & iBFT
Summary: [RFE] Diskless boot via iSCSI & iBFT
Status: CLOSED DUPLICATE of bug 1509992
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: rhosp-director
Version: 8.0 (Liberty)
Hardware: x86_64
OS: All
Target Milestone: ---
: ---
Assignee: Ben Nemec
QA Contact: Shai Revivo
Depends On: 1382890 1411366 1467377
Blocks: 1273812 1317731
TreeView+ depends on / blocked
Reported: 2015-11-18 23:52 UTC by Dave Cain
Modified: 2018-08-01 15:44 UTC (History)
37 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2018-08-01 15:44:12 UTC
Target Upstream Version:

Attachments (Terms of Use)
BZ1283436 Picture of provisioned Overcloud server booted via rescue mode and associated commands (456.56 KB, image/jpeg)
2016-01-08 19:03 UTC, Dave Cain
no flags Details
First Overcloud boot (124.62 KB, image/jpeg)
2016-06-22 17:23 UTC, Yossi Ovadia
no flags Details
Second overcloud boot (89.11 KB, image/jpeg)
2016-06-22 17:24 UTC, Yossi Ovadia
no flags Details

System ID Priority Status Summary Last Updated
Launchpad 1590606 None None None 2016-06-10 11:32:35 UTC
OpenStack gerrit 298439 'None' 'MERGED' 'Force rebuild of ramdisk as part of overcloud-full' 2019-12-08 05:31:50 UTC
OpenStack gerrit 327807 'None' 'MERGED' 'Handle diskless hardware connected to remote iscsi' 2019-12-08 05:31:50 UTC
Red Hat Bugzilla 1276147 None None None 2019-12-08 05:31:48 UTC
Red Hat Bugzilla 1317731 'high' 'CLOSED' '[RFE] IPA needs to support Multipathed SAN LUNs for root disk' 2019-12-08 05:31:49 UTC
Red Hat Bugzilla 1382890 None None None 2019-12-08 05:31:48 UTC
Red Hat Knowledge Base (Solution) 2352991 None None None 2016-10-11 21:31:16 UTC

Internal Links: 1276147 1317731 1322430 1382890

Description Dave Cain 2015-11-18 23:52:03 UTC
Description: When using the rhel-osp-director (RHEL7.1), the /usr/lib/python2.7/site-packages/ironic/drivers/modules/ipxe_config.template file can be amended with the options "rd.iscsi.ibft=1 rd.iscsi.firmware=1" in order to facilitate iSCSI boots for remotely presented iSCSI LUNs to servers for stateless booting (no local disks present in the server itself).  The file /httpboot/discoverd.ipxe can also be amended with "rd.iscsi.firmware=1" so that Ironic discovers the remote LUN during discovery/introspection, which it does.

However, the booted server nodes incorrectly begin the "targetcli-wrapper /backstores/block create block1 dev=/dev/sda" command and become hung.  Udev then crashes it appears.  I'm not certain, but I think the other iSCSI IQN of the Ironic server presented to the provisioned node (for kernel and ramdisk) may be accidentally being chosen by the targetcli-wrapper script, complicating matters.  How can we install RHEL-OSP7 on server nodes with LUNs provided by iSCSI instead of local disks?  The ability to pass "ip=ibft" to probe the iSCSI Boot Firmware table used to work in RHEL-OSP6, but no longer does with Ironic and iPXE for RHEL-OSP7.  I need some help debugging this.

If this is the incorrect component for this bug, I apologize.  Can it be redirected please?  We will really need this ability for OSP8 GA.

Details: Base install of RHEL 7.1 with partner provided key (NetApp) for OSP7 repositories.  Specific package levels:


Bugzilla dependencies (if any): N/A

Hardware dependencies (if any): N/A

Upstream information

Date it will be upstream: N/A

Version: RHEL-OSP7

External links:

Severity (U/H/M/L): H

Business Priority: Must

Comment 2 Dave Cain 2015-12-04 16:46:00 UTC
Hey Lucas, do you think this is an RFE or a defect?

Comment 3 Lucas Alvares Gomes 2015-12-08 12:14:13 UTC
Hi @Dave,

Ironic currently does not support booting from volume, we have related specs upstream [0][1] about booting cinder volumes in Ironic.

[0] https://review.openstack.org/#/c/200496/
[1] https://wiki.openstack.org/wiki/Ironic/blueprints/cinder-integration

Comment 4 Dave Cain 2015-12-14 21:14:45 UTC
Hi @Lucas, this is actually outside of Cinder itself.  

Normally one can provide a block device through either Fibre Channel, iSCSI, or even FCoE to the host as a root volume for the operating system directly.  Booting from SAN through either of these protocols can be done versus having the OS installed on local disks in the system. This provides significant advantages such as reduced management cost, allowing server profiles to "move" throughout the overall infrastructure (since it's disk is hosted on the managed storage device and is stateless), and the ability to employ space efficiency on the volume containing server LUNs.

This used to work in OSP6 by passing the "ip=ibft" option to the kernel command line, and it would probe the iSCSI Boot Firmware table (ibft) and see the remote LUN hosted on a managed storage device (like NetApp).

In the past few days, I've been able to figure out how to get the discovery image to detect and find the LUN and add it to the Ironic node database.  Doing an ironic node-validate against the discovered node shows a UUID for the block device, which is the LUN.  It even looks as if Ironic installs RHEL 7.1 on the discovered nodes properly through the deployment ramdisk and associated kernel.  The server even reboots and I see the RHEL7.1 grub screen, which is a great sign!  However, the server starts to boot and then never finds its root disk, dropping to a dracut shell.  Upon further inspection I see the following issues:

(1) passing "iscsi_firmware" or "ip=ibft" to the kernel appears as if these modules are not included in the overcloud image.
(2) all of the physical interfaces are down on the server, which would prevent iscsistart from logging into the remote storage device.
(3) Grub inserts root=UUID=<UUIDX>, where UUIDX is the same disk used to install RHEL7.1 by the deployment ramdisk in Ironic.  This won't work.

Comment 5 Dmitry Tantsur 2016-01-06 10:54:15 UTC

1) It's pretty possible that we don't include all modules. Are these shipped in separate packages?
2) I suspect here the problem is that we bootstrap DHCP in user space after root disk is mounted. I will defer the response to TripleO folks, as I'm not sure how to proceed with it.
3) Could you elaborate on why it's wrong? What should be done instead?

I'm retargeting this bug to a more generic component, as it's not only ironic problem.

Comment 6 Dave Cain 2016-01-08 19:02:43 UTC
Dmitry, thanks for responding to my e-mail here.

It looks like older overcloud images don't have the iscsi_ibft.ko kernel module in the /lib/modules directory.  My beta copy of OSP8 seems to have that now, so that's great.

For the root=UUID, since the overcloud image and subsequent provisioning process does not accommodate LVM and uses just straight partitions (/dev/sd[a-x]), I would rather it target the symbolic link /dev/disk/by-label/img-rootfs, which appears to be more properly mapped to (on my system at least) /dev/dm-4, so that dm-multipath mounts the proper root device.  This could be a red herring, but just comparing this to my installed OSP6 environment w/ RHEL 7.1 that uses LVM and has me somewhat concerned.

Can't say if that's completely the problem as the NIC cards are all down.  Any way that you know of for me to force them up, short of opening up and modifying the overcloud image?

I can boot a rescue image and mount the provisioned overcloud image and see the disk, so I'm feeling a bit better and am more confident that it provisions now, just can't get it to boot right.  Thoughts?  I'm attaching a picture of some command output on my provisioned overcloud server and booting it with a rescue image to see what's going on in it.

Comment 7 Dave Cain 2016-01-08 19:03:56 UTC
Created attachment 1112961 [details]
BZ1283436 Picture of provisioned Overcloud server booted via rescue mode and associated commands

Comment 8 Dmitry Tantsur 2016-01-12 10:17:15 UTC
Adding Dan.

Dan, when is dhcp-all-interfaces run on the overcloud? I have a feeling that it happens after root is mounted which can be a problem in this case.

Comment 9 Dan Prince 2016-01-12 19:13:06 UTC
We bootstrap DHCP on the nodes via this udev rule:


That rule starts a service which ultimately runs this script:


The idea is we want to run DHCP as early as possible when network interfaces are discovered and active. I'd be curious to know why any of this might be causing udev to crash though...

Comment 10 Dave Cain 2016-01-12 20:30:17 UTC
Dan, I haven't seen udev crash since trying to get this functionality to work in OSP7.  I moved on hoping that things were better in OSP8, and I have not seen that specific failure since.

With respect to the network interfaces, it looks as if my provisioned bare-metal overcloud node starts DHCP on the ibft0 and ibft1 interfaces as read from the iscsi boot firmware table.  I can ping both of the interfaces that are set (if I use rd.debug) from my storage hardware, so I think we're good there.  What doesn't seem to happen is logging into the fabric via "iscsistart -b".  I never see those iscsi sessions on my storage hardware, so I don't think it is getting there.  Does it try and look for the root disk before launching that command from dracut scripts?

Dmitry was helping me over IRC and trying to get it to where I could look at the console here.  No luck so far to report with trying "rd.break=pre-mount” or "rd.break=initqueue” passing to the kernel.  It always freezes with:

dracut-initqueue[564]: Warning: dracut-initqueue timeout - starting timeout scripts
dracut-initqueue[564]: Warning: Could not boot.

Comment 11 Ben Nemec 2016-01-13 15:39:06 UTC
Note that dhcp-all-interfaces only happens after dracut switches execution to the root partition.  If dracut is failing then it isn't related to that.

You may need to stop the boot process even earlier to see what's going on.  Probably pre-udev or pre-trigger.  I'm not sure whether initqueue is considered a valid stopping point.  It's possible that rd.break only recognizes the steps prefixed with Hook: on https://www.kernel.org/pub/linux/utils/boot/dracut/dracut.html#_hook_pre_udev

I can't say I have any experience booting with an iscsi root partition, but I see there are a pile of dracut options here: https://www.kernel.org/pub/linux/utils/boot/dracut/dracut.html#_iscsi  Do any of those look helpful?

Comment 12 Dave Cain 2016-01-20 22:26:46 UTC
Part of the problem here I think is that the overcloud image that I have, overcloud-full-8.0-20151203.1-beta-2.tar, does not have the "multipath", "md", or "iscsi" modules inserted into the initramfs.  I think that's why dracut whines about not being able to boot, it doesn't have the ability to find the disk at that stage.  

If I get onto the provisioned server using the rescue image and regenerate the ramdisk with dracut and reboot, it now boots.  I just got a two node deployment working on remote LUNs via iSCSI among a slew of other modifications in the discoverd portion of ironic, and the overcloud image itself.

I'm looking for a more automated way to fix this problem though as a part of an OpenStack deployment using the Director.  Who can I talk to about the overcloud image to see what can be done here?

Comment 13 Ben Nemec 2016-01-28 21:19:42 UTC
Okay, that makes me think the problem is that the overcloud images are built from a RHEL cloud image base.  I would guess the cloud image doesn't include those modules in the interest of saving space, and since we just pull the initramfs out of the image we only get what was already included.

One workaround would be to save a copy of the regenerated initramfs and replace the ramdisk image from the tar file with the regenerated one.  If you then run "openstack overcloud image upload --update-existing" it will use the regenerated image for future deployments.

Obviously this isn't ideal since it would potentially need to be done again for every release, but until we can get it resolved properly it might unblock you.  I'll have to look into whether just running dracut as part of our image build will generate an initramfs with the necessary modules.

Comment 14 Dave Cain 2016-01-29 01:01:53 UTC
Ben, what you're describing is exactly what I've done to get me going: repackaging the overcloud deployment image with a newly generated initramfs (with "multipath", "md", or "iscsi") and re-uploaded it to Glance for future deployments.  Totally agree with you, we 100% need to get functionality added to the overcloud images to support diskless provisioning/boot so we're not opening up the overcloud image each release to do this.  Please do let me know if there's a different way to get that initramfs updated in the meantime.

One thing that is not working however throughout all of this is the Ironic Python Agent (IPA).  The discovery process it appears uses this now, and I can't get it to find the iSCSI LUN no matter what I pass to the kernel.  I've been using the old bash discoverd boot disk from OSP7 for now to get me over this hump.  It looks as if the deployment ramdisk in my copy of the OSP8 beta (8.0-20151203.1-beta-2) is the old bash-based one, so I fear the same problem will be evident if OSP8 GA only includes the IPA for both discovery and deployment.  How can we handle this?

Comment 15 Dave Cain 2016-02-09 13:52:03 UTC
(In reply to Ben Nemec from comment #13)
> ...I'll have to look into whether just running dracut as part of
> our image build will generate an initramfs with the necessary modules.

Hey Ben, what is the best way to regenerate the initramfs inside of the overcloud image?  I have the kernel version present in the beta 2 image on a server of mine, and I've been running dracut with the -m flag specifying the modules + multipath, md, and iscsi.  I then copy the initramfs into the overcloud-full.qcow2 file and re-upload to Glance using the "--update-existing" switch as you've indicated.

Is there a better way to do the regeneration?

Comment 16 Ben Nemec 2016-02-12 22:17:51 UTC
That's about what I would do too.  You may not need to insert it into the qcow2 file though - I think Ironic will install the ramdisk from Glance for you at deploy time, so the one in the image itself doesn't matter.  I could be wrong about that though.

Comment 19 Ben Nemec 2016-03-28 21:40:32 UTC
Okay, I think I finally understand why the modules weren't being included in my test ramdisks, and it really is as simple as re-running dracut during the image build.  I'm linking an upstream patch to the bug that I believe should fix the problem.  At least it seems to be including the needed modules for this:


I don't have a way to test this further, so if anyone who is doing this can verify the list of modules above is sufficient I would appreciate it.  Thanks.

Comment 20 Mike Burns 2016-04-07 20:57:01 UTC
This bug did not make the OSP 8.0 release.  It is being deferred to OSP 10.

Comment 23 Ruchika K 2016-04-11 18:09:23 UTC

Comment 24 Dave Cain 2016-04-11 21:51:21 UTC
(In reply to Ben Nemec from comment #19)
> I don't have a way to test this further, so if anyone who is doing this can
> verify the list of modules above is sufficient I would appreciate it. 
> Thanks.

Ben, this list looks good to me.

Comment 29 Yossi Ovadia 2016-06-08 03:01:45 UTC
To whom it may concern - 
We have Emulex 'OneConnect' which is being configured at bios phase pointing to remote scsi drives. servers has no local disks.

We had the same issue described in https://bugzilla.redhat.com/show_bug.cgi?id=1328585

I have managed to overcome the issue (introspective part only for now...)  using the suggested patch (https://bugzilla.redhat.com/attachment.cgi?id=1158689&action=diff) 

And adding the following on top of it: 

def _udev_settle():
    """Wait for the udev event queue to settle.

    Wait for the udev event queue to settle to make sure all devices
    are detected once the machine boots up.

        utils.execute('udevadm', 'settle')
+        utils.execute('iscsistart','-b')
    except processutils.ProcessExecutionError as e:
        LOG.warning('Something went wrong when waiting for udev '
                    'to settle. Error: %s', e)

Comment 30 Dmitry Tantsur 2016-06-08 07:05:45 UTC
Hi! That's interesting, does this 'iscsistart -b' try to initialize iSCSI devices from kernel command line (the man page is a bit confusing)? Does it make sense for us to try running it every time?

Comment 31 Itamar 2016-06-08 07:59:05 UTC
That's great Yossi,
Might it make more sense to put the iscsistart before the udevadm? that way udev will have a chance to make itself aquatinted to the the newly discovered block devices.
Good work finding that one..

Comment 32 Yossi Ovadia 2016-06-08 17:41:42 UTC

I did some more digging, ( I simply grep -r isacistart -b.. ) 
this is what I've found - 

In usr/lib/dracut/modules.d/95iscsi/iscsiroot.sh theres :

 if getargbool 0 rd.iscsi.firmware -d -y iscsi_firmware ; then
     if [ "$netif" = "timeout" ] || [ "$netif" = "online" ]; then

Where handle_firmware is 
     if ! iscsistart -f; then
         warn "iscistart: Could not get list of targets from firmware."
         return 1
     for p in $(getargs rd.iscsi.param -d iscsi_param); do
         iscsi_param="$iscsi_param --param $p"
     if ! iscsistart -b $iscsi_param; then
          warn "'iscsistart -b $iscsi_param' failed with return code $?"
     echo 'started' > "/tmp/iscsistarted-iscsi:"
     echo 'started' > "/tmp/iscsistarted-firmware" 
     return 0

My /httpboot/inspector.ipxe has 'iscsi_firmware' 

I'll need to investigate as what's going on there. 

This seems like a better place for a fix.

Comment 33 Dmitry Tantsur 2016-06-09 07:23:53 UTC
Interesting, seems like rd.iscsi.firmware=1 might do the trick for you. Please let me know how it ends up.

Comment 34 Yossi Ovadia 2016-06-09 14:28:05 UTC
I have tried rd.iscsi.firmware=1 and it fails with exact same error. ( also tried iscsi_firmware )

Comment 35 Dmitry Tantsur 2016-06-10 11:32:36 UTC
Thanks Yossi!

Status update: the fix for the initramfs was merged to master and mitaka upstream. Hopefully it will merge to liberty as well.

Now we're working on making IPA aware of iBFT by trying to call iscsiboot -b on start up. Please stay tuned.

Comment 36 Yossi Ovadia 2016-06-10 20:58:11 UTC
+1 !
(In reply to Itamar from comment #31)
> That's great Yossi,
> Might it make more sense to put the iscsistart before the udevadm? that way
> udev will have a chance to make itself aquatinted to the the newly
> discovered block devices.
> Good work finding that one..

Comment 37 Yossi Ovadia 2016-06-22 17:22:12 UTC

Two things I made have improve the status - 

- I notice that running iscsistart –b several times halts the system, so, we need to  added code that make sure it will executed only once. 
- I have changed the template to RH latest templates ( it resolved 'callback exception' ) 

Now this is where I am and need assistance - 

When running the overcloud deployment I notice the following behavioural -
Two PXE boots -  
At first boot, it loads deploy_kernel and deploy_ramdisk , note that deploy_ramdisk is my modified image. Everything looks fine , then it reboots and 
In second boot , it loads – 'kernel' and 'ramdisk' ( See below. ) 
What I am seeing on seconds boot is that it dropped to dracut and unable to proceed. 

I don't know how it is possible to modify the 'ramdisk' file ( I was unable to extract it same way I as with deploy_ramdisk) 

[root@undercloud httpboot]# cd 485e57a4-eeb5-49c1-a379-ed7d4e92afe7/                                                   
[root@undercloud 485e57a4-eeb5-49c1-a379-ed7d4e92afe7]# ll                                                             
total 432632                                                                                                           
-rw-r--r--. 1 ironic ironic      1049 Jun 21 18:48 config                                                              
-rw-r--r--. 5 ironic ironic   5153536 Jun 21 18:08 deploy_kernel                                                       
-rw-r--r--. 5 ironic ironic 392371696 Jun 21 18:08 deploy_ramdisk                                                      
-rw-r--r--. 5 ironic ironic   5153408 Jun 15 17:32 kernel                                                              
-rw-r--r--. 5 ironic ironic  40324447 Jun 15 17:32 ramdisk

Screen shots attached shows the two different boots. 

Please advise !


Comment 38 Yossi Ovadia 2016-06-22 17:23:55 UTC
Created attachment 1170964 [details]
First Overcloud boot

Comment 39 Yossi Ovadia 2016-06-22 17:24:33 UTC
Created attachment 1170965 [details]
Second overcloud boot

Comment 40 Yossi Ovadia 2016-06-22 19:18:11 UTC
Moving to https://bugzilla.redhat.com/show_bug.cgi?id=1347430

Comment 41 Yossi Ovadia 2016-07-07 22:20:24 UTC
Regarding ( by Dmitry ) 
 "Status update: the fix for the initramfs was merged to master and mitaka upstream.    Hopefully it will merge to liberty as well."

How/where from can I have a that fixed initramfs ?

Can I get a description of the fix ( I assume it's DIB ? ) so I can try on current version of OSP8 ? 


Comment 42 Dmitry Tantsur 2016-07-08 09:29:33 UTC
Ben, what's the status of the initramfs fix in OSP8?

Comment 43 Ben Nemec 2016-07-08 17:23:14 UTC
I see the multipath module in the current OSP 8 ramdisk image, so I'm inclined to believe it's done.  The upstream change is attached to this bz, but here's a direct link: https://review.openstack.org/#/c/298439/

Comment 49 Dmitry Tantsur 2016-09-21 10:21:06 UTC
Thanks all for collaboration! I'm closing this bug in favor of 1347430 just to reset to clean history, as this one already contains a lot of not entirely related issues. Please feel free to open more bugs for specific issues you see.

*** This bug has been marked as a duplicate of bug 1347430 ***

Comment 50 Andreas Karis 2016-12-26 14:39:59 UTC

I am reopening this bug. It was marked as duplicate of 
 bug 1347430
which itself is marked as duplicate of private bug bug 1276147

Please note that flagging public bugs as duplicates of private bugs defies the purpose. We are an Open Source company, we should keep our customers up to date via public bugzillas. 

Please feel free to close this one as dup and set 1347430 as open, but don't trace progress in a private bug report.

Also, while this case here is generic and would IMO also include diskless boots on Cisco UCI with iBFT, 1276147 seems to particularly only address Nokia technology.


- Andreas

Comment 51 Dmitry Tantsur 2017-02-09 10:06:51 UTC
Converting to an RFE, as we never properly supported it in the first place..

Comment 52 MUHAMMAD AFZAL 2017-08-28 19:55:05 UTC
what is the status of this bug in OSP 10?

Comment 53 Irina Petrova 2018-03-16 17:22:51 UTC
What about RHOS-12?

In our downstream docs we can just see that the warning [1] disappears in the Overcloud Requirements of the Installation Guide... Does that mean it's supported?

[1] 'Booting an overcloud node from the SAN (FC-AL, FCoE, iSCSI) is not yet supported.'

Comment 54 Ben Nemec 2018-03-16 22:00:48 UTC
I have no idea what the status of this is.  Dmitry, can you comment?

Comment 55 Dmitry Tantsur 2018-03-21 11:42:00 UTC
I don't know either, redirecting to Ramon.

Comment 57 Ramon Acedo 2018-08-01 15:44:12 UTC
We are tracking the support for iSCSI booting on BZ #1509992. Closing this one as a duplicate.

*** This bug has been marked as a duplicate of bug 1509992 ***

Note You need to log in before you can comment on or make changes to this bug.