Bare-Metal Provisioning
Bare-metal provisioning is the process of taking an empty physical server from power-on to a running operating system without manual intervention. It covers network booting, firmware configuration, OS installation, and the automation tooling that makes this repeatable at scale.
itInfrastructure and operations | OpenSkills.info
Intro
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
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://www.dmtf.org/standards/redfish
Supports
- Redfish release 2026.1 and specification version 1.24.0 as the current published DMTF release
- Redfish protocol, data-model, schema, registry, and interoperability documents as separate standards
- https://www.dmtf.org/sites/default/files/standards/documents/DSP0266_1.24.0.html
Supports
- Redfish as a RESTful, schema-based platform-management interface
- Remote and out-of-band management scope
- HTTPS, TLS, authentication, authorization, sessions, resources, actions, and OEM extensions
- https://uefi.org/specs/UEFI/2.11/24_Network_Protocols_SNP_PXE_BIS.html
Supports
- UEFI PXE interfaces and DHCP, discovery, and TFTP stages
- Network bootstrap program terminology and transfer
- UEFI HTTP Boot discovery and HTTP or HTTPS download path
- https://www.rfc-editor.org/rfc/rfc2131.html
Supports
- DHCP client and server state and message exchange
- Bootstrap server and boot-file fields in DHCP messages
- Client-specific and class-specific configuration parameters
- https://www.rfc-editor.org/rfc/rfc1350.html
Supports
- TFTP operation over UDP
- Lock-step data blocks, acknowledgments, retransmission, and error behavior
- TFTP's intentionally small and restrictive protocol design
- https://ipxe.org/howto/chainloading
Supports
- Chainloading iPXE from existing PXE firmware
- Second-DHCP-request loop risk and loop-breaking approaches
- Different iPXE binaries for BIOS and UEFI clients
- https://docs.openstack.org/ironic/latest/install/get_started.html
Supports
- Bare-metal use cases and the Ironic API, conductor, driver, and agent architecture
- Power control through management protocols and temporary in-band agents
- PXE, DHCP, NBP, TFTP, image, network, and deployment relationships
- https://docs.openstack.org/ironic/latest/user/states.html
Supports
- Enrollment, verification, inspection, cleaning, availability, deployment, active, deletion, rescue, service, and failure states
- Deploy-agent waits, local image writing, boot-loader work, and destructive lifecycle transitions
- State-dependent recovery and quarantine behavior
- https://docs.openstack.org/ironic/latest/user/deploy.html
Supports
- Allocation, instance information, network attachment, deployment, and ramdisk boot flow
- Config-drive metadata, user data, network data, hostname, and SSH-key delivery
- https://docs.openstack.org/ironic/latest/install/refarch/common.html
Supports
- Whole-disk and partition-image responsibilities
- Provisioning, cleaning, rescue, callback, TFTP, HTTP, and image-service network requirements
- Restricted provisioning network guidance and BMC accessibility considerations
- https://docs.openstack.org/ironic-python-agent/latest/
Supports
- Deploy agent operation from a temporary ramdisk
- REST control for provisioning servers
- Hardware inventory, image checksum, clean, rescue, and troubleshooting functions
- https://docs.openstack.org/ironic-python-agent/latest/admin/hardware_managers.html
Supports
- Default hardware inventory and deploy, clean, and service steps
- Image writing, disk-metadata erasure, secure device erasure, RAID configuration, and file injection
- Different assurance and duration for metadata erasure and full device erasure
- https://docs.openstack.org/ironic/latest/admin/cleaning.html
Supports
- Automated and manual node cleaning
- Metadata erasure, hardware-assisted secure erase, software overwrite, and express cleaning tradeoffs
- Cleaning-network use, in-band and out-of-band steps, failure states, and reuse policy
- https://docs.openstack.org/ironic/latest/admin/security.html
Supports
- Image checksum, native hardware access, firmware, tenant reuse, and BMC credential risks
- Separation of disk cleaning from firmware validation and reset
- Isolation of management, provisioning, cleaning, rescue, and deploy-agent API paths
- Unique BMC credential guidance and authorization boundaries
