Skip to content

Infrastructure

Provision compute resources that meet or exceed the minimum requirements for each node type. Primary POC paths use bare metal, but Agent-Based and vSphere IPI installs on virtual machines are also supported — see Prerequisites.

OpenShift Terminology

A quick note on terminology. In OpenShift, the same server can be described at three layers:

  • Host (BareMetalHost, managed by the Bare Metal Operator) is the physical box and its BMC, answering how to power and provision the hardware
  • Machine (Machine, managed by the Machine API and grouped into a MachineSet) is the infrastructure instance that backs a node and is the unit you scale which can be a physical box or a virtual machine
  • Node (Node) is the Kubernetes-level member that runs a kubelet and that the scheduler places pods onto.

Required Hardware

Consider these recommended POC values — the more the better.

Official Minimums

The official OpenShift minimums are 4 vCPU / 16 GB / 100 GB (control plane) and 2 vCPU / 8 GB / 100 GB (compute), but POC workloads — especially OpenShift Virtualization — need significantly more.

For Agent-based HA installations, the recommended minimum is 8 vCPU / 16 GB / 120 GB per node.

Single Cluster Installation

Host Type Count CPU Memory Install Disk Secondary Disk
Installation 1 4 16 GB 60 GB ---
Control Plane 3 16 32 GB 120 GB ---
Worker 3 16 64 GB 120 GB 1 TB (opt)

Fleet Management (Hub + Spoke) Installation

Host Type Count CPU Memory Install Disk Secondary Disk
Installation 1 4 16 GB 60 GB ---
Hub (SNO) 1 16 64 GB 120 GB 1 TB (opt)
Spoke Control Plane 3 16 32 GB 120 GB ---
Spoke Worker 3 16 64 GB 120 GB 1 TB (opt)

Hardware Notes

Do I need an installation host?

No, as long as the computer you are working from can install the tools listed in Installation Host without opening tickets (oc, openshift-install, nmstatectl, git, podman, and related utilities). Optional day-2 tools such as helm, kustomize, or istioctl are only needed for specific workloads. We highly recommend a centralized installation host so work does not stop if a laptop is unavailable.

Machine Type

The installation and hub machine can be either a virtual machine or bare metal host. They just need network access to the other hosts. Cluster nodes are typically bare metal for production-like POCs; virtual machines (for example on vSphere) are valid when following the Agent-Based or vSphere IPI guides.

CPU Architecture

For the POC, prefer the same vendor and generation CPU architectures across all machines.

Install Disk

The etcd instances needs to run on a block device that can write at least 50 IOPS of 8 KB sequentially, including fdatasync, in under 10 ms. Heavily loaded clusters should target 500 sequential IOPS of 8 KB in 2 ms. See etcd Storage for the full disk performance requirements.

Secondary Disk

The secondary disk in the worker nodes can be used for storage if you decide to use OpenShift Data Foundation as your storage solution in the cluster. If you are using an already existing storage provider, the secondary disk is optional in the cluster.

Network Interface Requirements

Only a single NIC is required for OpenShift. To perform more advanced networking, 4 x 10 GbE is recommended for bond0/bond1. Production Virtualization setups typically use two bonds — mgmt (bond0) and a trunked data plane (bond1) with VLANs for VM, storage, and live migration — see Networking. A third physical bond for storage is optional when the network team requires a dedicated uplink instead of a storage VLAN.

Machine Information

Collect the interface names, MAC addresses for ALL NICs, and the install disk location on the machines. Below is an example table of values needed.

Hostname hl01ocpinstall Disk Hint /dev/sda
BMC IP BMC Credentials
Interface MAC Address Bond IP Address
eno1 A0:B1:C2:D3:E4:E0 - 10.0.0.5
Hostname hl01ocphub Disk Hint /dev/sda
BMC IP BMC Credentials
Interface MAC Address Bond IP Address
eno1 A0:B1:C2:D3:E4:E1 - 10.0.0.6
Hostname hl01ocpcp01 Disk Hint /dev/sda
BMC IP BMC Credentials
Interface MAC Address Bond IP Address
eno1 A0:B1:C2:D3:E4:ED bond0 10.0.0.7
eno2 A0:B1:C2:D3:E4:E2 bond0
eno3 A0:B1:C2:D3:E4:E3 bond1
eno4 A0:B1:C2:D3:E4:E4 bond1
Hostname hl01ocpcp02 Disk Hint /dev/sda
BMC IP BMC Credentials
Interface MAC Address Bond IP Address
eno1 A0:B1:C2:D3:E4:E5 bond0 10.0.0.8
eno2 A0:B1:C2:D3:E4:E6 bond0
eno3 A0:B1:C2:D3:E4:E7 bond1
eno4 A0:B1:C2:D3:E4:E8 bond1
Hostname hl01ocpcp03 Disk Hint /dev/sda
BMC IP BMC Credentials
Interface MAC Address Bond IP Address
eno1 A0:B1:C2:D3:E4:E9 bond0 10.0.0.9
eno2 A0:B1:C2:D3:E4:EA bond0
eno3 A0:B1:C2:D3:E4:EB bond1
eno4 A0:B1:C2:D3:E4:EC bond1
Hostname hl01ocpw01 Disk Hint /dev/sda
BMC IP BMC Credentials
Interface MAC Address Bond IP Address
eno1 A0:B1:C2:D3:E4:F1 bond0 10.0.0.10
eno2 A0:B1:C2:D3:E4:F2 bond0
eno3 A0:B1:C2:D3:E4:F3 bond1
eno4 A0:B1:C2:D3:E4:F4 bond1
Hostname hl01ocpw02 Disk Hint /dev/sda
BMC IP BMC Credentials
Interface MAC Address Bond IP Address
eno1 A0:B1:C2:D3:E4:F5 bond0 10.0.0.11
eno2 A0:B1:C2:D3:E4:F6 bond0
eno3 A0:B1:C2:D3:E4:F7 bond1
eno4 A0:B1:C2:D3:E4:F8 bond1
Hostname hl01ocpw03 Disk Hint /dev/sda
BMC IP BMC Credentials
Interface MAC Address Bond IP Address
eno1 A0:B1:C2:D3:E4:F9 bond0 10.0.0.12
eno2 A0:B1:C2:D3:E4:FA bond0
eno3 A0:B1:C2:D3:E4:FB bond1
eno4 A0:B1:C2:D3:E4:FC bond1

Machine Details

NIC Naming

On modern RHEL (RHEL CoreOS included), NICs use predictable network interface names generated at boot based on hardware topology and firmware information:

  • eno1, eno2 — onboard NICs (from BIOS/firmware)
  • ens1f0, ens1f1 — PCI Express slots ("s" = slot, "f" = function)
  • enp3s0 — PCI bus location (p3 = bus 3, s0 = slot 0)
  • enx — fallback to MAC address if nothing else matches

Warning

If you don't know what the values will be (disk name, NIC names), boot the boxes with a RHEL ISO Boot iso and find out. Don't guess. You don't even need to install, just start the installer and you can see the information.

BMC / Out-of-Band Management

Each bare metal server must have out-of-band management access for remote operations:

Management Type Protocol Purpose
IPMI IPMI Power control, virtual media
Redfish HTTPS Modern BMC API, virtual media
iLO / iDRAC HTTPS Vendor-specific BMC

Virtual media (mounting the discovery ISO remotely) is the recommended method for booting nodes during installation.

Testing BMC Access

Verify Redfish API connectivity from the installation host to each BMC before starting the install. This confirms credentials, network access, and helps you identify the correct system ID for each server.

List available systems:

curl -sk https://{{ bmc_ip }}/redfish/v1/Systems/ -u {{ bmc_username }}:{{ bmc_password }} | jq '.Members'

The BMC address format varies by vendor:

Vendor Address Format
HPE iLO redfish-virtualmedia://{{ bmc_ip }}/redfish/v1/Systems/1
Dell iDRAC idrac-virtualmedia://{{ bmc_ip }}/redfish/v1/Systems/System.Embedded.1
Cisco CIMC redfish-virtualmedia://{{ bmc_ip }}/redfish/v1/Systems/{{ system_id }}

Dell iDRAC Protocol

The redfish-virtualmedia:// protocol is designed for HPE iLO and does not work on Dell iDRAC. Always use idrac-virtualmedia:// for Dell servers.

Verify power state and virtual media by vendor:

curl -sk https://{{ bmc_ip }}/redfish/v1/Systems/System.Embedded.1 -u {{ bmc_username }}:{{ bmc_password }} | jq '.PowerState'
curl -sk https://{{ bmc_ip }}/redfish/v1/Managers/iDRAC.Embedded.1/VirtualMedia -u {{ bmc_username }}:{{ bmc_password }} | jq '.Members'

curl -sk https://{{ bmc_ip }}/redfish/v1/Systems/1 -u {{ bmc_username }}:{{ bmc_password }} | jq '.PowerState'
curl -sk https://{{ bmc_ip }}/redfish/v1/Managers/1/VirtualMedia -u {{ bmc_username }}:{{ bmc_password }} | jq '.Members'

Discover System IDs

List available systems first to find the correct system path for your hardware:

curl -sk https://{{ bmc_ip }}/redfish/v1/Systems -u {{ bmc_username }}:{{ bmc_password }} | jq '.Members'

Tip

If any of these commands fail, check that the BMC IP is reachable from the installation host, the credentials are correct, and HTTPS (port 443) is open between the installation host and the BMC network.

BIOS/Firmware Settings

Ensure the following on all nodes:

  • Boot mode set to UEFI
  • Secure Boot supported (optional but recommended)
  • Boot order set to local disk (the ISO is mounted via virtual media)
  • Before mounting the discovery/agent ISO, clear stale OS UEFI boot table entries (leftover entries from previous installations can cause the node to boot the wrong target). Use a one-time virtual-media/CD boot override for the first boot, then set boot order back to local disk after installation completes.
  • Hardware clock set to UTC

Firmware versions

The list above is how the firmware is configured. Flashing a new BIOS, BMC, NIC, or HBA image is a separate procedure. Bring those versions to a vendor-validated baseline before imaging, and update one node at a time after installation. See Hardware Firmware Updates.

Disable POST Memory Test

Servers with large amounts of RAM (512 GB+) can spend 5–10 minutes running full memory diagnostics during every boot. For a POC where clusters are built and torn down frequently, disabling the POST memory test cuts each reboot cycle significantly with no reliability trade-off.

For a detailed runbook covering Dell, HPE, Cisco, and Lenovo — including when to disable, automation with Ansible, and a handback checklist — see Faster Bare-Metal Boots in OpenShift PoCs.

Dell iDRAC

racadm set BIOS.MemSettings.MemTest Disabled
racadm jobqueue create BIOS.Setup.1-1
racadm serveraction powercycle

Redfish equivalent:

curl -sk -X PATCH \
  https://{{ bmc_ip }}/redfish/v1/Systems/System.Embedded.1/Bios/Settings \
  -u {{ bmc_username }}:{{ bmc_password }} \
  -H "Content-Type: application/json" \
  -d '{"Attributes":{"MemTest":"Disabled"}}'

HPE iLO

Enable Memory Fast Training (skips full initialization after first good boot):

ilorest set MemFastTraining=Enabled --selector=Bios.
ilorest commit

Redfish equivalent:

curl -sk -X PATCH \
  https://{{ bmc_ip }}/redfish/v1/Systems/1/Bios/Settings \
  -u {{ bmc_username }}:{{ bmc_password }} \
  -H "Content-Type: application/json" \
  -d '{"Attributes":{"MemFastTraining":"Enabled"}}'

Cisco CIMC

Redfish:

curl -sk -X PATCH \
  https://{{ bmc_ip }}/redfish/v1/Systems/{{ system_id }}/Bios/Settings \
  -u {{ bmc_username }}:{{ bmc_password }} \
  -H "Content-Type: application/json" \
  -d '{"Attributes":{"<memory-test-attribute>":"Disabled"}}'

Note

The exact attribute name varies between C-series generations and firmware versions (often POSTErrorPause or a toggle under the memory RAS group). Query /redfish/v1/Systems/{{ system_id }}/Bios to find the correct attribute name for your hardware.

Declarative via HostFirmwareSettings (Metal³ / Ironic)

If the bare metal nodes are managed by Metal³/Ironic (BareMetalHost operator), skip per-BMC scripting and drive it declaratively through HostFirmwareSettings:

Assisted/Agent-Based Installs

Nodes provisioned via the Assisted Installer or Agent-based method are typically registered as ExternallyProvisioned in Metal³. In this state, HostFirmwareSettings edits will not be applied because Ironic does not manage the firmware lifecycle for externally provisioned hosts. Apply BIOS changes via racadm (Dell) or Redfish API before imaging the nodes.

Reading Allowed Firmware Values

For IPI-provisioned hosts, read allowed attribute values from the FirmwareSchema CR referenced by status.schema.name and status.schema.namespace on the HostFirmwareSettings resource — not from status.schema itself, which only contains the reference.

apiVersion: metal3.io/v1alpha1
kind: HostFirmwareSettings
metadata:
  name: {{ baremetalhost_name }}
  namespace: openshift-machine-api
spec:
  settings:
    MemTest: "Disabled"          # Dell
    # MemFastTraining: "Enabled" # HPE

Look up the correct attribute names from the node's firmware schema:

oc get hostfirmwaresettings {{ baremetalhost_name }} -n openshift-machine-api -o yaml

The status.settings field shows current values and status.schema shows allowed values per attribute. This keeps the change in your GitOps repo and reapplies on reprovision.

Schedulable Control Plane

There is an ability to run the control plane nodes as schedulable, making them effectively worker nodes as well. This is discouraged unless required by the environment constraints, such as testing to run edge systems.