OpenStack Ironic bare metal provisioning

IPMI and PXE do different jobs in Ironic, and the team needs to know which dependency each one creates before any node is enrolled. IPMI, or the BMC interface behind it, gives Ironic remote power control and a way to set the next boot device even when the operating system is absent or broken. PXE gives the node a network path to fetch a boot loader, a kernel and a ramdisk from the Ironic provisioning network. Ironic drives both from its conductor service, so the conductor must reach every BMC address and the provisioning network must carry DHCP and TFTP or HTTP traffic for the nodes it manages.

Enrollment starts when an operator registers a node with its BMC address, credentials, and the MAC address of the NIC used for provisioning. Ironic then validates the management interface by querying power state, and runs an inspection step that collects hardware details such as CPU, memory, disks and NIC identifiers. Inspection can run through an out-of-band process that boots an inspection ramdisk over PXE, or through an in-band agent, depending on the configured inspection interface. The team should confirm which inspection method its hardware and firmware support before the first node is enrolled, because the answer determines which network and boot settings must be in place.

Deployment and cleaning both repeat the same pattern. Ironic sets the boot device to PXE through IPMI, powers the node on, serves a deploy ramdisk over the provisioning network, writes the requested image to disk, and then sets the boot device to the local disk for the final boot. Cleaning, whether automated or manual, runs the same cycle with cleaning steps such as disk erasure or firmware updates. Each step depends on BMC credentials staying valid, on DHCP and PXE responding on the right VLAN, and on the boot mode matching the firmware setting. A mismatch between legacy BIOS and UEFI is one of the most common causes of a node that powers on but never reaches the deploy ramdisk.

Credentials and network paths are the two dependencies that fail most often in practice. BMC user accounts should have only the power and boot-device rights Ironic needs, and rotation must update the node record or the next power action will fail. The provisioning network must be isolated, and its DHCP and TFTP or HTTP services must be reachable only from nodes being managed. Ask the hardware vendor which BMC protocol versions, UEFI secure boot settings and NIC firmware versions are supported with the release of Ironic you plan to run, and record those details in the enrollment checklist before any node is added to the inventory.

Choose a bare metal instance when the workload needs the whole server and a virtual machine would add cost without adding value. Performance-sensitive and hardware-dependent workloads are the clearest cases: latency-sensitive databases, packet-heavy network functions, and accelerator jobs that depend on specific drivers, firmware or NUMA layout. Each of these may need local NVMe devices, particular NIC features or predictable CPU behavior that a hypervisor layer can blur. Start by listing which hardware features the workload depends on, then check whether a VM flavor can expose them in your cloud.

Direct hardware access and isolation are the second group. Some workloads need BIOS or firmware settings, IPMI-level control, or low-level NIC configuration that a guest cannot change. Tenancy requirements matter as much. When a regulator, customer contract or internal policy asks for dedicated machines, a bare metal instance keeps one tenant on the hardware and removes co-tenancy with other projects' VMs. Ask the compliance owner to state that requirement in writing, because it decides the placement model before any performance test runs.

Hosts that run a hypervisor or Kubernetes nodes are the third group. A KVM or other hypervisor host has to run on physical hardware, and Ironic is a common way to build those hosts from the same control plane that runs your cloud. Kubernetes nodes on bare metal suit storage-heavy or network-heavy clusters, and Ceph storage nodes are typically physical servers. Confirm with your platform team whether nested virtualization is acceptable for any node role, since that choice changes which instances belong on metal.

Virtual machines remain the better choice when the workload needs fast scaling, high density or shared capacity. Nova guests can boot from Ceph-backed volumes without local hypervisor storage, so they can be started, moved and resized with little hardware involvement. A bare metal instance occupies a whole server and goes through hardware cleaning and boot steps before it is usable, so small or bursty workloads often leave expensive capacity idle. Measure your own provisioning time and utilization in your environment before assuming either model is faster to operate.

Test the decision against your own measurements rather than a general rule. Pick the candidate workload, run it on a VM and on a bare metal node with comparable hardware, and record latency percentiles, throughput, time from request to usable host, failure recovery effort and cost per unit of work. Write the decision threshold before the test starts, so the result is not shaped by preference. Repeat the test after any hardware or firmware change, because those changes can move the outcome as much as the choice of instance type.

Enrollment quality decides whether Ironic can provision anything at all, so treat the node inventory as a controlled dataset rather than a one-time import. For each server, record the baseboard management controller (BMC) address, a reference to its credentials, the Ironic driver that matches its management protocol, and the driver settings that protocol needs. Each network interface's MAC address becomes a port record that Ironic uses during PXE boot and network switching. Hardware details such as CPU, memory, disks and root device hints should come from an inspection run on the hardware, with the results checked against your asset records. Confirm which management protocols your server models support and which driver your OpenStack release provides for them before you enroll the first node.

An inventory starts to drift as soon as someone replaces a network card, updates BMC firmware, moves a host to another rack or changes a disk layout. Assign a named owner for the node dataset and decide whether Ironic or your configuration management database is the source of truth. Whichever system wins, the other should be reconciled on a schedule, and a hardware change should trigger a fresh inspection before the node is used again. Store BMC credentials in a secrets manager that your Ironic services can read, not in the node records themselves. Ask any implementation partner to state in the written scope how inventory reconciliation will run after handover, who approves changes and how stale records are retired.

Moving existing servers onto Ironic-managed hardware starts with knowing what each host runs. List the applications, data stores, owners and network dependencies on every machine, and mark the hosts that cannot be interrupted. Check firmware on the BMC, system BIOS or UEFI and network adapters against the versions your hardware and deployment support, and update them before enrollment, because a firmware change after inspection can make inspection data wrong. Migrate data off each host first: replicate or back up volumes, test restores on a separate system, drain workloads and confirm nothing else depends on the host. Only then reimage it through Ironic. Cleaning wipes the disks, so confirm that no data remains on them before the first deployment.

The OpenInfra VMware to OpenStack Migration Guide covers moving virtual machines, including a feature comparison, a migration framework, hardware recommendations and case studies. It is useful for the VM side of a consolidation project, but do not assume its process applies to physical servers. Bare metal moves have no hypervisor snapshot to fall back on, disks are physical, boot modes and partition layouts often change, and each outage window applies to a single machine. Write a separate runbook for each class of server, covering the operating system image, drivers, rollback by restoring from verified backups and the people who approve each cutover. Start with a pilot host, review what went wrong, and only then schedule the rest of the fleet. Confirm these steps with your own platform team before you commit to dates.