Bare-Metal Provisioning

Bare-metal provisioning turns an unconfigured physical server into a machine that can run an assigned workload. The process controls hardware directly. No hypervisor creates a virtual machine first.

That difference changes the job. A virtual-machine control plane already has programmable power, disks, consoles, and virtual networks. A physical server exposes those controls through firmware, a baseboard management controller, network-boot protocols, switches, and real storage devices. Provisioning coordinates all of them.

Use one mental model throughout this course:

desired server
    -> out-of-band control
    -> network bootstrap
    -> temporary in-band agent
    -> disk and host configuration
    -> local boot
    -> verified workload handoff

Each arrow crosses a boundary. Most failures come from locating the wrong boundary, not from a mysterious installer.

Provisioning is a lifecycle

Provisioning is broader than installing an operating system. It starts when you identify and enroll hardware. It continues through inspection, preparation, deployment, verification, use, deprovisioning, and cleaning.

A production system represents that lifecycle as explicit state. OpenStack Ironic, for example, distinguishes enrolled, manageable, available, deploying, active, cleaning, and failure states. The names vary across products. The principle does not: record what the controller believes, the transition it requested, and the evidence returned by the machine.

This state model makes retries safer. A controller can tell the difference between a machine ready for allocation and one waiting for a deployment agent. It can stop scheduling a node after a failed clean. It can also resume operator work from a known state instead of repeating every destructive action.

The two control paths

Bare-metal provisioning uses out-of-band and in-band control.

Out-of-band control reaches a server through its baseboard management controller, or BMC. The BMC operates independently of the host operating system. A provisioning controller uses it to read power state, power-cycle the server, and select a boot source. It can also open a remote console, mount virtual media, or inspect supported hardware data.

Redfish defines a standard, schema-based HTTPS interface for many of these management operations. Vendor support still varies by server generation, firmware, and optional Redfish features. Your provisioning system therefore needs tested hardware profiles, not only a claim that a device “supports Redfish.”

In-band control runs code on the server's main processors. Before the target operating system exists, the controller usually boots a small service image into memory. That deploy agent can inspect CPUs, memory, network interfaces, and disks. It can erase storage, configure RAID, write an image, install a boot loader, and report progress.

Neither path replaces the other. Out-of-band control gets a powered-off or broken host to the next boot stage. In-band control handles work that needs direct access to the host's devices.

The network bootstrap chain

Network boot gives firmware enough information to fetch and start a network bootstrap program.

A common PXE path looks like this:

The controller sets a one-time network boot and powers on the server.
UEFI firmware initializes a network interface and starts PXE.
DHCP supplies network configuration and boot-service information.
Firmware downloads a network bootstrap program, often through TFTP.
That program loads a kernel and deploy ramdisk, often through HTTP.
The deploy agent starts in memory and calls back to the controller.

UEFI also defines HTTP Boot. It can discover a boot URI and download the network bootstrap program through HTTP, with TLS available for HTTPS. iPXE is another common bridge: firmware can load iPXE first, then iPXE can retrieve larger artifacts through HTTP or HTTPS.

Treat this as a chain, not one feature called “PXE.” Firmware architecture, DHCP policy, boot filename, TFTP or HTTP reachability, artifact format, and callback routing must agree. A server that receives an address but never starts the agent has crossed the DHCP boundary and failed later.

Inventory binds identity to hardware

The controller needs a durable record for each server. That record normally includes a BMC endpoint and credentials, network-interface addresses, hardware traits, selected drivers, deployment capabilities, and intended ownership.

Inspection improves that record with observed hardware data. An in-band agent can report processors, memory, network interfaces, and block devices. Out-of-band inspection may expose some of the same data, but coverage depends on the management interface.

Do not confuse discovery with identity. A MAC address seen during boot is one signal. A BMC endpoint is another. Serial numbers, system UUIDs, switch-port data, and inventory records provide more evidence. Bind them deliberately so one deployment request cannot target the wrong chassis or disk.

Inventory also drives placement. A scheduler can match a request for a hardware class or trait to an available server. That is still allocation, not provisioning. Allocation chooses and reserves the node. Provisioning changes it.

The deploy agent prepares the machine

After the deploy agent calls back, the controller can perform hardware-specific steps in a controlled order. Typical work includes:

Confirming the observed inventory matches policy
Selecting the root device
Applying firmware, BIOS, or RAID settings when supported
Erasing stale disk metadata or previous workload data
Downloading and verifying the deployment image
Writing partitions, filesystems, or a complete disk image
Installing or preserving the correct boot loader
Adding instance-specific metadata, user data, or network data
Switching the next boot from the network to local storage

Image choice affects the boundary of responsibility. A whole-disk image contains its partition table, required partitions, and boot loader. A partition image contains the root partition; the provisioning service creates the surrounding disk layout and boot setup. The second approach gives the controller more responsibility and more platform constraints.

A config drive or equivalent metadata source carries values unique to one server. Keep the base image generic when possible. Put hostname, initial keys, network data, and workload bootstrap data into a controlled instance-specific channel.

Handoff separates provisioning from configuration

Provisioning ends when the server boots the intended image and passes defined health checks. Configuration management or an application bootstrap process can continue from there.

Keep this handoff explicit. The provisioning system owns hardware state, boot path, base image, and initial identity. A configuration system owns later operating-system and application convergence. The exact boundary is yours to define, but two controllers should not silently fight over firmware, network configuration, or storage layout.

Successful image writing is not enough. Verify that the server booted from the intended local device, joined the correct network, presented the expected identity, and reached the expected service state. Only then mark it ready for use.

Networks define trust boundaries

A practical design separates at least three traffic classes:

Management traffic between the controller and BMCs
Provisioning traffic used by firmware, deploy agents, image services, and callbacks
Workload traffic used after handoff

You may combine some physical infrastructure, but preserve policy boundaries. Management access can power machines and change boot behavior. Provisioning services distribute executable code and disk images. Neither belongs on an unrestricted user network.

OpenStack Ironic recommends keeping provisioning networks inaccessible to end users and, where the architecture allows, disconnected from the internet. Its security guidance also calls for restricting management, provisioning, cleaning, and rescue networks from outside access.

Protect the artifact path as well. Use authenticated control APIs. Use TLS where firmware and agents support it. Verify image hashes through a trusted metadata path. Control who can replace boot files, images, or DHCP policy. A valid hash proves that bytes match a declared value; your release process must establish that the declared value is trustworthy.

Cleaning closes the lifecycle

Deprovisioning removes workload-specific resources. Cleaning prepares the hardware for another owner or workload.

Disk metadata erasure and full data erasure provide different assurance. Removing partition tables is fast, but specialized recovery may still find data. Hardware-assisted secure erase or a full overwrite provides stronger protection and may take much longer.

Disk cleaning also does not prove firmware integrity. A workload with host administrator privileges runs directly on the hardware and may change device or firmware settings. Ironic's security documentation explicitly separates disk cleaning from firmware validation and reset. Your threat model must cover both.

Treat cleaning as a schedulable state with evidence. If it fails, quarantine the node. Do not return it to the available pool because a timeout expired or an operator cleared an alert.

Where bare metal fits

Bare metal fits workloads that need direct device access, dedicated tenancy, predictable hardware boundaries, or performance without a virtualization layer. It also fits building the infrastructure that later hosts hypervisors, container platforms, storage systems, and private clouds.

It carries physical constraints. You cannot live-migrate a physical server like a virtual machine. Firmware and BMC behavior vary. Image transfer and disk erasure take time. A failed power supply or disk remains a hardware repair problem. Capacity arrives in whole machines, not arbitrary virtual sizes.

Use bare-metal provisioning when those tradeoffs match the workload. Use virtual machines when fast cloning, snapshots, live migration, and fine-grained resource sharing matter more than direct hardware ownership.

The durable mental model is a controlled relay. The BMC starts the machine. Firmware finds the bootstrap path. A temporary agent prepares storage and identity. The installed system boots locally. Verification hands the server to its workload. Cleaning makes the next handoff safe.