Layer 3 or DHCP-less ramdisk booting

Booting nodes via PXE, while universally supported, suffers from one disadvantage: it requires a direct L2 connectivity between the node and the control plane for DHCP. Using virtual media it is possible to avoid not only the unreliable TFTP protocol, but DHCP altogether.

When network data is provided for a node as explained below, the generated virtual media ISO will also serve as a configdrive, and the network data will be stored in the standard OpenStack location.

The simple-init element needs to be used when creating the deployment ramdisk. The Glean tool will look for a media labeled as config-2. If found, the network information from it will be read, and the node’s networking stack will be configured accordingly.

ironic-python-agent-builder -o /output/ramdisk \
     debian-minimal -e simple-init


The simple-init element is found to conflict to NetworkManager, which makes this feature not operational with ramdisks based on CentOS, RHEL and Fedora. The debian-minimal element seems to work correctly.


If desired, some interfaces can still be configured to use DHCP.

Hardware type support

This feature is known to work with the following hardware types:

  • Redfish with redfish-virtual-media boot

  • iLO with ilo-virtual-media boot

Configuring network data

When the Bare Metal service is running within OpenStack, no additional configuration is required - the network configuration will be fetched from the Network service.

Alternatively, the user can build and pass network configuration in form of a network_data JSON to a node via the network_data field. Node-based configuration takes precedence over the configuration generated by the Network service and also works in standalone mode.

baremetal node set --network-data ~/network_data.json <node>

An example network data:

    "links": [
            "id": "port-92750f6c-60a9-4897-9cd1-090c5f361e18",
            "type": "phy",
            "ethernet_mac_address": "52:54:00:d3:6a:71"
    "networks": [
            "id": "network0",
            "type": "ipv4",
            "link": "port-92750f6c-60a9-4897-9cd1-090c5f361e18",
            "ip_address": "",
            "netmask": "",
            "network_id": "network0",
            "routes": []
    "services": []


Some fields are redundant with the port information. We’re looking into simplifying the format, but currently all these fields are mandatory.