Skip to main content
Version: v1.9 (Dev)

Hardware and Network Requirements

As an HCI solution on bare metal servers, there are minimum node hardware and network requirements for installing and running Harvester.

A three-node cluster is required to fully realize the multi-node features of Harvester. The first node that is added to the cluster is by default the management node. When the cluster has three or more nodes, the two nodes added after the first are automatically promoted to management nodes to form a high availability (HA) cluster.

Certain versions of Harvester support the deployment of single-node clusters. Such clusters do not support high availability, multiple replicas, and live migration.

Hardware Requirements

Harvester nodes have the following hardware requirements and recommendations for installation and testing.

HardwareDevelopment/TestingProduction
CPUARM64 or x86_64 (with hardware-assisted virtualization); 8 cores minimumARM64 or x86_64 (with hardware-assisted virtualization); 16 cores minimum
Memory32 GB minimum64 GB minimum
Disk capacity250 GB minimum (180 GB minimum for witness nodes or when using multiple disks)500 GB minimum, 1 TB or more recommended
Disk performance5,000+ random IOPS per disk (SSD/NVMe); management node storage must meet etcd speed requirements. Only local disks and hardware RAID are supported.5,000+ random IOPS per disk (SSD/NVMe); management node storage must meet etcd speed requirements. Only local disks and hardware RAID are supported.
Network card countManagement cluster network: 1 NIC required, 2 NICs recommended; VM workload network: 1 NIC required, at least 2 NICs recommended (does not apply to the witness node)Management cluster network: 1 NIC required, 2 NICs recommended; VM workload network: 1 NIC required, at least 2 NICs recommended (does not apply to the witness node)
Network card speed1 Gbps Ethernet minimum10 Gbps Ethernet minimum
Network switchPort trunking for VLAN supportPort trunking for VLAN support
important
  • Support for legacy BIOS booting is deprecated in v1.7.0 and will be removed in a later release. Existing Harvester clusters that use this boot mode will continue to function, but upgrading to later versions may require re-installation in UEFI mode. Starting with Harvester v1.8.0, new installations are only possible on UEFI systems.
  • Mixed-architecture clusters are not supported. Deploy separate clusters to avoid unexpected system behavior.
  • For best results, use YES-certified hardware for SUSE Linux Micro 6.2. Harvester is built on SUSE Linux Enterprise technology and YES-certified hardware has additional validation of driver and system board compatibility. Laptops and nested virtualization are not supported.
  • Nested virtualization is not supported on virtual machines running on Harvester.
  • Each node must have a unique product_uuid (fetched from /sys/class/dmi/id/product_uuid) to prevent errors from occurring during VM live migration and other operations. For more information, see Issue #4025.
  • Harvester has a built-in management cluster network (mgmt). To achieve high availability and the best performance in production environments, use at least two NICs in each node to set up a bonded NIC for the management network (see step 6 in ISO Installation). You can also create custom cluster networks for VM workloads. Each custom cluster network requires at least two additional NICs to set up a bonded NIC in every involved node of the Harvester cluster. The witness node does not require additional NICs. For more information, see Cluster Network.
  • During testing, you can use only one NIC for the built-in management cluster network (mgmt), and for testing the VM network that is also carried by mgmt. High availability and optimal performance are not guaranteed.
  • If the disk only meets the minimum required capacity, you may encounter issues related to the free system partition space requirement during upgrades.

CPU Specifications

Live Migration functions correctly only if the CPUs of all physical servers in the Harvester cluster have the same specifications. This requirement applies to all operations that rely on Live Migration functionality, such as automatic VM migration when Maintenance Mode is enabled.

Newer CPUs (even those from the same vendor, generation, and family) can have varying capabilities that may be exposed to VM operating systems. To ensure VM stability, Live Migration checks if the CPU capabilities are consistent, and blocks migration attempts when the source and destination are incompatible.

When creating clusters, adding more hosts to a cluster, and replacing hosts, always use CPUs with the same specifications to prevent operational constraints.

Network Requirements

Harvester nodes have the following network requirements for installation.

Port Requirements for Harvester Nodes

Harvester nodes require the following port connections or inbound rules. Typically, all outbound traffic is allowed.

Ports that bind only to 127.0.0.1 are accessible from localhost only and do not require inbound firewall rules; they are included here for completeness.

Control-plane Node

ProtocolPortBind AddressSourceDescription
TCP220.0.0.0AllSSH
TCP800.0.0.0AllHarvester UI HTTP (nginx proxy)
TCP4430.0.0.0AllHarvester UI HTTPS (nginx proxy)
TCP21120.0.0.0Allkube-vip Prometheus metrics
TCP2379127.0.0.1, node IPHarvester management nodesetcd client port
TCP2380127.0.0.1, node IPHarvester management nodesetcd peer port
TCP2381127.0.0.1 onlylocalhostetcd metrics/health
TCP2382127.0.0.1 onlylocalhostetcd learner client (HTTP)
TCP64430.0.0.0AllKubernetes API server
TCP90910.0.0.0Allcalico-node metrics (Prometheus)
TCP9099127.0.0.1 onlylocalhostCanal/CNI health check
TCP93450.0.0.0Harvester nodesRKE2 supervisor API
TCP97960.0.0.0AllPrometheus node-exporter
TCP10010127.0.0.1 onlylocalhostcontainerd gRPC
TCP10248127.0.0.1 onlylocalhostkubelet healthz
TCP10249127.0.0.1 onlylocalhostkube-proxy metrics
TCP102500.0.0.0Kubernetes componentskubelet API
TCP10256127.0.0.1 onlylocalhostkube-proxy health
TCP10257127.0.0.1 onlylocalhostkube-controller-manager
TCP10258127.0.0.1 onlylocalhostcloud-controller-manager
TCP10259127.0.0.1 onlylocalhostkube-scheduler
TCP30000-327670.0.0.0AllNodePort services (TCP)
UDP84720.0.0.0Harvester nodesVXLAN (Flannel/Canal)
UDP30000-327670.0.0.0AllNodePort services (UDP)

Worker Node

ProtocolPortBind AddressSourceDescription
TCP220.0.0.0AllSSH
TCP800.0.0.0AllHarvester UI HTTP (nginx proxy)
TCP4430.0.0.0AllHarvester UI HTTPS (nginx proxy)
TCP6443127.0.0.1, [::1]localhostKubernetes API server (RKE2 agent proxy)
TCP6444127.0.0.1, [::1]localhostRKE2 agent API proxy
TCP90910.0.0.0Allcalico-node metrics (Prometheus)
TCP9099127.0.0.1 onlylocalhostCanal/CNI health check
TCP97960.0.0.0AllPrometheus node-exporter
TCP10010127.0.0.1 onlylocalhostcontainerd gRPC
TCP10248127.0.0.1 onlylocalhostkubelet healthz
TCP10249127.0.0.1 onlylocalhostkube-proxy metrics
TCP102500.0.0.0Kubernetes componentskubelet API
TCP10256127.0.0.1 onlylocalhostkube-proxy health
TCP30000-327670.0.0.0AllNodePort services (TCP)
UDP84720.0.0.0Harvester nodesVXLAN (Flannel/Canal)
UDP30000-327670.0.0.0AllNodePort services (UDP)

Witness Node

ProtocolPortBind AddressSourceDescription
TCP220.0.0.0AllSSH
TCP2379127.0.0.1, node IPHarvester management nodesetcd client port
TCP2380127.0.0.1, node IPHarvester management nodesetcd peer port
TCP2381127.0.0.1 onlylocalhostetcd metrics/health
TCP2382127.0.0.1 onlylocalhostetcd learner client (HTTP)
TCP6443127.0.0.1 onlylocalhostKubernetes API server (RKE2 agent proxy)
TCP6444127.0.0.1 onlylocalhostRKE2 agent API proxy
TCP90910.0.0.0Allcalico-node metrics (Prometheus)
TCP9099127.0.0.1 onlylocalhostCanal/CNI health check
TCP93450.0.0.0Harvester nodesRKE2 supervisor API
TCP97960.0.0.0AllPrometheus node-exporter
TCP10010127.0.0.1 onlylocalhostcontainerd gRPC
TCP10248127.0.0.1 onlylocalhostkubelet healthz
TCP10249127.0.0.1 onlylocalhostkube-proxy metrics
TCP102500.0.0.0Kubernetes componentskubelet API
TCP10256127.0.0.1 onlylocalhostkube-proxy health
TCP10258127.0.0.1 onlylocalhostcloud-controller-manager
UDP84720.0.0.0Harvester nodesVXLAN (Flannel/Canal)

Port Requirements for Addons

The following tables list the additional ports opened by optional Harvester addons on each node role, compared to the baseline with no addons enabled.

kubeovn-operator (Experimental)

Control-plane Node

ProtocolPortBind AddressSourceDescription
TCP6641node IPHarvester nodesOVN Northbound DB
TCP6642node IPHarvester nodesOVN Southbound DB
TCP6643node IPHarvester nodesOVN Northd
TCP6644node IPHarvester nodesOVN Raft (ovn-central)
TCP10661node IPHarvester nodeskube-ovn-monitor
TCP10665node IPHarvester nodeskube-ovn-daemon metrics/API
UDP47890.0.0.0Harvester nodesVXLAN tunnel (Kube-OVN overlay)

Worker Node

ProtocolPortBind AddressSourceDescription
TCP8080node IPHarvester nodeskube-ovn-webhook HTTP
TCP84430.0.0.0Allkube-ovn-webhook HTTPS
TCP10660node IPHarvester nodeskube-ovn-controller metrics
TCP10665node IPHarvester nodeskube-ovn-daemon metrics/API
UDP47890.0.0.0Harvester nodesVXLAN tunnel (Kube-OVN overlay)

Witness Node

ProtocolPortBind AddressSourceDescription
TCP10665node IPHarvester nodeskube-ovn-daemon metrics/API
UDP47890.0.0.0Harvester nodesVXLAN tunnel (Kube-OVN overlay)

Port Requirements for Integrating Harvester with Rancher

If you want to integrate Harvester with Rancher, you need to make sure that all Harvester nodes can connect to TCP port 443 of the Rancher load balancer.

When provisioning VMs with Kubernetes clusters from Rancher into Harvester, you need to be able to connect to TCP port 443 of the Rancher load balancer. Otherwise, the cluster won't be manageable by Rancher. For more information, refer to Rancher Architecture.

Port Requirements for K3s or RKE2 Clusters

For the port requirements for guest clusters deployed inside Harvester VMs, refer to the following links:

Time Requirements

A reliable Network Time Protocol (NTP) server is critical for maintaining the correct system time across all nodes in a Kubernetes cluster, especially when running Harvester. Kubernetes relies on etcd, a distributed key-value store, which requires precise time synchronization to ensure data consistency and prevent issues with leader election, log replication, and cluster stability.

Ensuring accurate and consistent time across the cluster is essential for reliability, security, and overall system integrity.