Chapter 2. Requirements for virtualized control planes
Before deploying a virtualized control plane cluster, ensure your environment meets the following requirements.
2.1. Hosting cluster requirements
The hosting cluster runs the virtualized control plane VMs and manages their lifecycle through KubeVirt Redfish.
The hosting cluster requires the following components:
- OpenShift Container Platform installed and operational.
- OpenShift Virtualization installed and configured.
- Sufficient compute resources to host control plane VMs.
- At least three physical nodes to enable anti-affinity placement, ensuring control plane VMs are spread across different physical hosts.
2.2. Storage requirements
The hosting cluster must have a storage solution that supports VM disk images and meets the latency requirements of etcd.
Use Logical Volume Manager (LVM) Storage backed by NVMe drives for virtualized control plane storage. LVM Storage writes directly to local disks, providing the consistent low latency that etcd requires. Use dedicated NVMe drives for control plane VM disks to ensure predictable performance.
Do not use Red Hat OpenShift Data Foundation (ODF) for control plane VM disk storage. ODF replicates data across multiple storage nodes, which can cause unpredictable latency spikes during synchronization that affect etcd performance.
During installation of the virtualized control plane, KubeVirt Redfish requires a shared storage location for the installation ISO. When the installer mounts boot media through the Redfish API, KubeVirt Redfish creates a data volume, downloads the installation ISO into that volume, and attaches the volume to the VM as virtual media. Because control plane VMs can be scheduled on any worker node in the hosting cluster, the storage location for the installation ISO must be accessible from all nodes. Do not use a node-local storage class such as LVM Storage for this volume.
2.3. Network requirements
Virtualized control plane deployments require specific network connectivity between VMs, worker nodes, and external services.
Configure networking to meet the following requirements:
-
L2 network connectivity between control plane VMs. The OpenShift Container Platform installation program requires all control plane nodes to share the same L2 network segment. The
apiVIPsmust reside on this L2 segment. -
A separate L2 network segment for worker nodes. The
ingressVIPsmust reside on the same L2 segment. - L3 connectivity without network address translation (NAT) between the control plane VMs and worker nodes. Worker nodes must be able to route traffic directly to the control plane VMs. During installation, the bootstrap VM also requires L3 connectivity to the control plane.
- External access to the cluster API.
- Access to container image registries.
- DNS resolution for cluster components.
You can use either dynamic or static IP addressing for the control plane VMs:
- For deployments that use DHCP, configure static MAC addresses on the primary network interfaces of the VMs and create DHCP reservations for each MAC address. This ensures consistent IP assignment across VM restarts.
-
For deployments that use static IP addressing, define the network configuration in your
install-config.yamlor Agent-based installation manifests.
2.4. Control plane VM requirements
Each control plane VM must meet minimum resource requirements to run the OpenShift Container Platform control plane components reliably.
Each control plane VM requires the following minimum resources:
- 8 vCPUs
- 16 GiB RAM
120 GiB storage
NoteUse Logical Volume Manager (LVM) Storage backed by NVMe drives for virtualized control plane storage.
2.5. KubeVirt Redfish requirements
KubeVirt Redfish exposes VMs through the Redfish API.
You need the following to use KubeVirt Redfish:
- Network access from the installation workstation to the KubeVirt Redfish route.
- Credentials configured in KubeVirt Redfish for API authentication.
- VMs labeled to be exposed through the Redfish API.
- A shared storage location for the installation ISO. During installation of the virtualized control plane, KubeVirt Redfish uses this location to create a data volume, download the installation ISO into that volume, and attach the volume to the VM as virtual media. Because VMs can be scheduled on any worker node in the hosting cluster, this storage location must be accessible from all nodes. Do not use a node-local storage class such as LVM Storage.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}