The minimum hardware requirements for the RHOCP cluster that hosts your RHOSO control plane are as follows:

• An operational, pre-provisioned 3-node bare metal RHOCP cluster.
  • If you are using a multi-node RHOCP cluster with dedicated control plane and worker nodes, you must have 3 dedicated RHOCP control plane nodes and 3 dedicated worker nodes for high availability.
• Each worker node in the cluster must have the following resources:
  • 64 GB RAM
  • 16 CPU cores
  • 120GB NVMe or SSD for the root disk plus 250 GB storage (NVMe or SSD is strongly recommended) Note

    The images, volumes and root disks for the virtual machine instances running on the deployed environment are hosted on dedicated external storage nodes. However, the service logs, databases, and metadata are stored in a RHOCP Persistent Volume Claim (PVC). A minimum of 150 GB is required for testing.

  • 2 physical NICs for basic control. Note
    In a 6-node cluster with 3 controllers and 3 workers, only the worker nodes require 2 physical NICs.
  • Optional: Additional dedicated NICs for OVN external gateways on the control plane. These are required if you plan to place OVN gateways on the control plane.
  • The RHEL system time zone and the date and time of the system firmware (UEFI/BIOS) clock for each cluster node must be UTC.
• Each control plane node in the cluster must have the resources specified in Minimum resource requirements for cluster installation in the RHOCP Installing on any platform guide.
• Persistent Volume Claim (PVC) storage on the cluster:
  • 150 GB persistent volume (PV) pool for service logs, databases, file import conversion, and metadata.
    • You must plan the size of the PV pool that you require for your RHOSO pods based on your RHOSO workload. For example, the Image service image conversion PVC should be large enough to host the largest image and that image after it is converted, and any other concurrent conversions. You must make similar considerations for the storage requirements if your RHOSO deployment uses the Object Storage service (swift).
    • The PV pool is required for the Image service, however the actual images are stored on the Image service back end, such as Red Hat Ceph Storage or SAN.
  • 5 GB of the available PVs must be backed by local SSDs for control plane services such as the Galera, OVN, and RabbitMQ databases.

• If you are using virtual media boot to provision bare-metal data plane nodes and the nodes are not connected to a provisioning network or to the RHOCP machine network, you must configure a route for the Baseboard Management Controller (BMC) and the node to reach the RHOCP machine network. The machine network is the network used by RHOCP cluster nodes to communicate with each other.
• Synchronize all nodes in your RHOCP cluster with one or more Network Time Protocol (NTP) servers. Clock synchronization between RHOCP nodes and data plane nodes ensures accurate timing across your cloud environment for reliable services, workloads, and timestamps.
• The following ports must be open between cluster nodes:

  Port	Description
  67,68	When using a provisioning network, cluster nodes access the dnsmasq DHCP server over their provisioning network interfaces using ports 67 and 68.
  69	When using a provisioning network, cluster nodes communicate with the TFTP server on port 69 using their provisioning network interfaces. The TFTP server runs on the bootstrap VM. The bootstrap VM runs on the provisioner node.
  80	When not using the image caching option or when using virtual media, the provisioner node must have port 80 open on the baremetal machine network interface to stream the Red Hat Enterprise Linux CoreOS (RHCOS) image from the provisioner node to the cluster nodes.
  123	The cluster nodes must access the NTP server on port 123 using the baremetal machine network.
  5050	The Ironic Inspector API runs on the control plane nodes and listens on port 5050. The Inspector API is responsible for hardware introspection, which collects information about the hardware characteristics of the bare-metal nodes.
  5051	Port 5050 uses port 5051 as a proxy.
  6180	When deploying with virtual media and not using TLS, the provisioner node and the control plane nodes must have port 6180 open on the baremetal machine network interface so that the baseboard management controller (BMC) of the worker nodes can access the RHCOS image. Starting with OpenShift Container Platform 4.13, the default HTTP port is 6180.
  6183	When deploying with virtual media and using TLS, the provisioner node and the control plane nodes must have port 6183 open on the baremetal machine network interface so that the BMC of the worker nodes can access the RHCOS image.
  6190-6220	The OpenStackProvisionServer custom resource (CR) is required to install RHEL. If there is a firewall between your RHOCP machine network and the RHOSO control plane, you must open ports 6190-6220. The OpenStackProvisionServer CR is automatically created by default during the installation and deployment of your Red Hat OpenStack on OpenShift (RHOSO) environment and it uses the port range 6190-6220. You can create a custom OpenStackProvisionServer CR to limit the ports that are opened.
  6385	The Ironic API server runs initially on the bootstrap VM and later on the control plane nodes and listens on port 6385. The Ironic API allows clients to interact with Ironic for bare-metal node provisioning and management, including operations such as enrolling new nodes, managing their power state, deploying images, and cleaning the hardware.
  6388	Port 6385 uses port 6388 as a proxy.
  8080	When using image caching without TLS, port 8080 must be open on the provisioner node and accessible by the BMC interfaces of the cluster nodes.
  8083	When using the image caching option with TLS, port 8083 must be open on the provisioner node and accessible by the BMC interfaces of the cluster nodes.
  9999	By default, the Ironic Python Agent (IPA) listens on TCP port 9999 for API calls from the Ironic conductor service. Communication between the bare-metal node where IPA is running and the Ironic conductor service uses this port.

• Some network architectures might require the following networking capabilities:
  • A dedicated NIC on RHOCP worker nodes for RHOSO isolated networks.
  • Port switches with VLANs for the required isolated networks.

  Consult with your RHOCP and network administrators about whether these are requirements in your deployment.

• RHOCP version 4.20.
  • By default, the Agent-based Installer installs the latest version of RHOCP, which might not be supported by RHOSO. Therefore, if you plan to use the Agent-based Installer to install your RHOCP cluster, ensure you install version 4.18. For information about how to override the default RHOCP version installed, see the Red Hat Knowledgebase article How to install a specific version of OpenShift Container Platform 4.x.
• The RHOCP environment supports Multus CNI.
• The following Operators are installed on the RHOCP cluster:
  • The Kubernetes NMState Operator. This Operator must be started by creating an nmstate instance. For information, see Installing the Kubernetes NMState Operator in the RHOCP Networking guide.
  • The MetalLB Operator. This Operator must be started by creating a metallb instance. For information, see Starting MetalLB on your cluster in the RHOCP Networking guide. Note

    When you start MetalLB with the MetalLB Operator, the Operator starts an instance of a speaker pod on each node in the cluster. When using an extended architecture such as 3 RHOCP masters and 3 RHOCP workers, if your RHOCP masters do not have access to the ctlplane and internalapi networks, you must limit the speaker pods to the RHOCP worker nodes. For more information about speaker pods, see Limit speaker pods to specific nodes.

  • The cert-manager Operator. For information, see cert-manager Operator for Red Hat OpenShift in the RHOCP Security and compliance guide.
  • The Cluster Observability Operator. This Operator is required only for the Telemetry service, which is enabled by default. Therefore, if your RHOSO deployment does not require the Telemetry service then you do not need the Cluster Observability Operator and you must disable the Telemetry service when creating your control plane. For information about the Cluster Observability Operator, see Installing the Cluster Observability Operator.
• The Cluster Baremetal Operator (CBO) is configured for provisioning. The CBO deploys the Bare Metal Operator (BMO) component, which is required to provision bare-metal nodes as part of the data plane deployment process. For more information on planning for bare-metal provisioning, see Planning provisioning for bare-metal data plane nodes.
• The following tools are installed on the cluster workstation:
  • The oc command line tool.
  • The podman command line tool.
• The RHOCP storage back end is configured.
• The default RHOCP storage class is defined, has access to persistent volumes (PVs) of type ReadWriteOnce, and is configured to dynamically allocate PVs. For more information about creating the storage class, see Creating a storage class. Note
  If your default storage class is not configured for dynamic allocation of PVs, then your deployment might fail if your PVs are not available for the PVCs created during your deployment. For information about planning PVs, see Minimum RHOCP hardware requirements.