CNI MTU setting for concurrent VM traffic

Question

CNI MTU setting for concurrent VM traffic
In Harvester, virtual machines are deployed as KubeVirt pods and rely on the host’s CNI bridge for networking. When multiple VMs generate concurrent traffic, packet fragmentation can occur if the MTU on the bridge does not match the VM interfaces. This mismatch manifests as increased latency and packet loss during high‑throughput tests.
The goal is to identify the optimal MTU configuration that keeps latency low across concurrent requests while remaining compatible with the underlying physical NIC and the Longhorn storage network stack. The main uncertainty lies in whether the MTU should be set globally on the host bridge, overridden per-VM, or managed by the CNI plugin’s default.
Specific questions to resolve:

Does Harvester expose a per‑VM MTU configuration option, or is the MTU only adjustable at the host bridge level?
What are the documented performance implications of setting the host bridge MTU to 9000 in a Harvester cluster?
Is there a recommended MTU value for the CNI plugin used by Harvester that balances fragmentation risk with throughput under concurrent VM workloads?

Tasadduq Burney · Answer

Direct answerHarvester does not expose a per-VM MTU control in its UI. You can set a per-VM MTU by editing the KubeVirt VM manifest and adding mtu under spec.domain.devices.interfaces[], but the host bridge remains the cluster-wide default. For concurrent VM traffic, keep the bridge MTU at the physical NIC default (usually 1500) unless jumbo frames are verified end-to-end. If your NICs, switches, and Longhorn storage network all support 9000-byte frames, use 9000 consistently across the bridge, VM interfaces, and storage network.Confirmed facts and likely explanationConfirmed: The Harvester CNI uses a plain Linux bridge without an overlay, so its default MTU mirrors the physical NIC. KubeVirt supports an mtu field on VM interfaces.Likely explanation: Latency and packet loss under concurrent load usually stem from an MTU mismatch between the VM interface, the host bridge, or the storage network. Jumbo frames improve throughput only when every hop supports them; otherwise they cause silent drops and fragmentation.Recommended configurationDefault to the physical NIC MTU (typically 1500) on the host bridge unless you have confirmed 9000-byte support on all switches, NICs, and the Longhorn storage network.If jumbo frames are supported, set 9000 on the bridge, the VM interface, and the storage network. Do not mix MTU values across the path.Use per-VM overrides only for workloads that must differ from the bridge default; otherwise let the CNI default apply to avoid drift.VerificationCheck the bridge MTU on each node:ip link show Confirm the Harvester network configuration matches:kubectl -n harvester-system get configmap harvester-network -o yamlFrom inside a VM, verify the interface MTU:ip link show eth0Run an iperf3 test between two VMs at 1500 and, if supported, 9000. Compare latency and retransmissions.Version note and open questionThese steps assume a recent Harvester release using the default bridge CNI; customized or older CNI configurations may behave differently. Do your physical NICs, switches, and Longhorn storage network all support 9000-byte jumbo frames end-to-end? If yes, adopt 9000 consistently. If not—or if you are unsure—stay at 1500.

CNI MTU setting for concurrent VM traffic

CNI MTU setting for concurrent VM traffic

1 answer

Direct answer

Confirmed facts and likely explanation

Recommended configuration

Verification

Version note and open question

Your perspective belongs here.

0 question comments